It seems to be in the case of a string op against a raw address, the
compiler decides the destination object is 0 bytes long and throws a
particular warning. Work around it by not using memcpy in one case and
by disabling the warning in the other.
Both are fairly benign code that basically operates in a hard coded way
that knows the destination buffer is valid.
Some of the structures, notably 'cmd', in the lib console stuff are a
little too generically named and have collided with some other code
so prefix the names a bit more cleanly with console_
The change is largely mechanical, and folks with out of tree code can
easily switch by renaming:
cmd -> console_cmd
cmd_args -> console_cmd_args
cmd_block -> console_cmd_block
console_cmd -> console_cmd_func
Apologies if this breaks you but it should be pretty easy to fix.
TL;DR most uses of lib/console.h -> lk/console_cmd.h
Move the part that lets a piece of code somewhere in the system to
define a console command from the actual lib/console api to start an
instance of the console. Move in almost every place the user of the
console command definition to the new header, lk/console_cmd.h which is
always in the include path.
Also remove most uses of testing for WITH_LIB_CONSOLE since you can
almost always just safely define it and then let the linker remove it.
Almost nothing changes here except moving braces to the same line as the
function declaration. Everything else is largely whitespace changes and
a few dangling files with tab indents.
See scripts/codestyle
Ran everything through scripts/codestyle.space, which uses astyle
to generally follow K&R style.
Biggest non whitespace change is pulling brackets down on function
declarations, which I'm pretty ambivalent about, but astyle insists
on taking a stance
- Fix a bug when doing bounds checking
- Don't run elf if the entrypoint is out of bounds
- Allow to specify the memory slot to download (slot is 512K)
- Default slot for elf is 1, 3 and for data is 0, 2
Introduces two commands:
load any <filename>
load elf <filename>
Then from another system in the network you can:
tftp -i <ip-addr> put <filename>
Which for the 'any' case just loads the file into DRAM and for the 'elf'
case it parses the file and if correct it spawns a thread to run the
entrypoint.
