- Jan 25, 2016
-
-
Simon Glass authored
Now that they are in their own directory, we can remove this prefix. This makes it easier to find a file since the prefix does not get in the way. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com> Reviewed-by:
Heiko Schocher <hs@denx.de> Acked-by:
Stefan Roese <sr@denx.de> Acked-by:
Przemyslaw Marczak <p.marczak@samsung.com>
-
Simon Glass authored
There are a lot of unrelated files in common, including all of the commands. Moving them into their own directory makes them easier to find and is more logical. Some commands include non-command code, such as cmd_scsi.c. This should be sorted out at some point so that the function can be enabled with or without the associated command. Unfortunately, with m68k I get this error: m68k: + M5329AFEE +arch/m68k/cpu/mcf532x/start.o: In function `_start': +arch/m68k/cpu/mcf532x/start.S:159:(.text+0x452): relocation truncated to fit: R_68K_PC16 against symbol `board_init_f' defined in .text.board_init_f section in common/built-in.o I hope someone can shed some light on what this means. I hope it isn't depending on the position of code in the image. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com> Reviewed-by:
Heiko Schocher <hs@denx.de> Acked-by:
Stefan Roese <sr@denx.de> Acked-by:
Przemyslaw Marczak <p.marczak@samsung.com>
-
- Jul 24, 2013
-
-
Wolfgang Denk authored
Signed-off-by:
Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by:
Tom Rini <trini@ti.com>
-
- Mar 01, 2013
-
-
Simon Glass authored
Use setenv_ulong(), setenv_hex() and setenv_addr() in common/ Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- May 10, 2011
-
-
Heiko Schocher authored
cc: Wolfgang Denk <wd@denx.de> cc: Detlev Zundel <dzu@denx.de> cc: Valentin Longchamp <valentin.longchamp@keymile.com> cc: Holger Brunck <holger.brunck@keymile.com> Signed-off-by:
Valentin Longchamp <valentin.longchamp@keymile.com>
-
Heiko Schocher authored
do not define own flash_info variable, instead use the flash_info variable defined in your flash driver. Signed-off-by:
Heiko Schocher <hs@denx.de> cc: Wolfgang Denk <wd@denx.de> cc: Detlev Zundel <dzu@denx.de> cc: Valentin Longchamp <valentin.longchamp@keymile.com> cc: Holger Brunck <holger.brunck@keymile.com> Signed-off-by:
Valentin Longchamp <valentin.longchamp@keymile.com>
-
- Aug 08, 2010
-
-
Frans Meulenbroeks authored
removed the command name from the help message as it is already printed. for cmd_mmc also rewrote the message a little bit Signed-off-by:
Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
-
- Jul 04, 2010
-
-
Wolfgang Denk authored
The hush shell dynamically allocates (and re-allocates) memory for the argument strings in the "char *argv[]" argument vector passed to commands. Any code that modifies these pointers will cause serious corruption of the malloc data structures and crash U-Boot, so make sure the compiler can check that no such modifications are being done by changing the code into "char * const argv[]". This modification is the result of debugging a strange crash caused after adding a new command, which used the following argument processing code which has been working perfectly fine in all Unix systems since version 6 - but not so in U-Boot: int main (int argc, char **argv) { while (--argc > 0 && **++argv == '-') { /* ====> */ while (*++*argv) { switch (**argv) { case 'd': debug++; break; ... default: usage (); } } } ... } The line marked "====>" will corrupt the malloc data structures and usually cause U-Boot to crash when the next command gets executed by the shell. With the modification, the compiler will prevent this with an error: increment of read-only location '*argv' N.B.: The code above can be trivially rewritten like this: while (--argc > 0 && **++argv == '-') { char *arg = *argv; while (*++arg) { switch (*arg) { ... Signed-off-by:
Wolfgang Denk <wd@denx.de> Acked-by:
Mike Frysinger <vapier@gentoo.org>
-
- Jan 17, 2010
-
-
Heiko Schocher authored
cramfsls and cramfsload are added to the command list. A cramfs placed at 'cramfs_addr' can the be listed with 'cramfsls' and files can be loaded with 'cramfsload'. 'cramfs_addr' is an environment variable specifying the address the cramfs is located. This works for powerpc and for ARM. Use CONFIG_CMD_CRAMFS. Signed-off-by:
Andreas Huber <andreas.huber@keymile.com> Signed-off-by:
Heiko Schocher <hs@denx.de>
-