- Sep 04, 2017
-
-
Hannes Schmelzer authored
This commit brings things back to the well known working state of the command. - With commit 9620d872 (cmd/fdt: support single value replacement within an array) there was an error introduced modifying (inserting) a property to a device-tree node. fdt_getprop(...) returnes a len with -1 for a non-existing property, but a memcpy with len -1 isn't a good idea and things went wrong (crash). - Some times later Tom did repair this with commit 99bb38e2 (fdt: Check for NULL return from fdt_getprop in 'fdt set') This repairs the crash but the behaviour of the command isn't like before, it makes it impossible to insert a property. - Signed-off-by:
Hannes Schmelzer <oe5hpm@oevsv.at> Acked-by:
Simon Glass <sjg@chromium.org>
-
- Aug 16, 2017
-
-
Simon Glass authored
We are now using an env_ prefix for environment functions. Rename these for consistency. Also add function comments in common.h. Suggested-by:
Wolfgang Denk <wd@denx.de> Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
We are now using an env_ prefix for environment functions. Rename these commonly used functions, for consistency. Also add function comments in common.h. Suggested-by:
Wolfgang Denk <wd@denx.de> Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
We are now using an env_ prefix for environment functions. Rename setenv() for consistency. Also add function comments in common.h. Suggested-by:
Wolfgang Denk <wd@denx.de> Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- Jul 11, 2017
-
-
Tom Rini authored
While the previous pass through fixed one place where we knew that fdt_getprop would be given a positive len, in the case of 'fdt set' we do not, so check that we did no get NULL from fdt_getprop(). Cc: Simon Glass <sjg@chromium.org> Reported-by: Coverity (CID: 163249) Fixes 72c98ed1 ("fdt: Add a check to do_fdt() for coverity") Signed-off-by:
Tom Rini <trini@konsulko.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
- Jun 12, 2017
-
-
Simon Glass authored
We know that fdt_getprop() does not return NULL when len is > 0 but coverity does not. Add an extra check to keep it happy. Signed-off-by:
Simon Glass <sjg@chromium.org> Reported-by: Coverity (CID: 163248)
-
Simon Glass authored
We know that fdt_getprop() does not return NULL when len is > 0 but coverity does not. Add an extra check to keep it happy. Signed-off-by:
Simon Glass <sjg@chromium.org> Reported-by: Coverity (CID: 163249) Fixes: bc80295b (fdt: Add get commands to fdt)
-
- Jun 09, 2017
-
-
Hannes Schmelzer authored
With this commit we can modify single values within an array of a dts property. This is useful if we have for example a pwm-backlight where we want to modifiy the pwm frequency per u-boot script. The pwm is described in dts like this: backlight { pwms = <0x0000002b 0x00000000 0x004c4b40>; }; For changing the frequency, here the 3rd parameter, we simply type: fdt set /backlight pwms <? ? 0x1E8480>; For doing all this we: - backup the property content into our 'SCRATCHPAD' - only modify the array-cell if the new content doesn't start with '?' Signed-off-by:
Hannes Schmelzer <hannes.schmelzer@br-automation.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
- May 22, 2017
-
-
Simon Glass authored
This option is not used by any board. Drop it. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- Jan 14, 2017
-
-
Andreas Färber authored
On a Raspberry Pi 2 disagreements on cell endianness can be observed: U-Boot> fdt print /soc/gpio@7e200000 phandle phandle = <0x0000000d> U-Boot> fdt get value myvar /soc/gpio@7e200000 phandle; printenv myvar myvar=0x0D000000 Fix this by always treating the pointer as BE and converting it in fdt_value_setenv(), like its counterpart fdt_parse_prop() already does. Consistently use fdt32_t, fdt32_to_cpu() and cpu_to_fdt32(). Fixes: bc80295b ("fdt: Add get commands to fdt") Cc: Joe Hershberger <joe.hershberger@ni.com> Cc: Gerald Van Baren <gvb@unssw.com> Signed-off-by:
Andreas Färber <afaerber@suse.de> Acked-by:
Simon Glass <sjg@chromium.org>
-
Stefan Agner authored
There are lots of reason why a FDT application might fail, the error code might give an indication. Let the error code translate in a error string so users can try to understand what went wrong. Signed-off-by:
Stefan Agner <stefan.agner@toradex.com> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
- Dec 03, 2016
-
-
Fabien Parent authored
The function that is processing the 'fdt' parameters is one big if-else if. In order to be able to type command faster only the first few letter are checked to know which block of code to execute. For systemsetup, the block of code that was executed was always the wrong one and ended up in a failure. } else if (argv[1][0] == 's') { process "fdt set" command } else if (strncmp(argv[1], "sys", 3) == 0) { process "fdt systemsetup" command. } When typing "fdt systemsetup", the code that was executed was the code for "fdt set". This commit fix this issue by moving the "else if" for systemsetup before the else if for "fdt set". This allow us to keep compatibility with any script that make use of "fdt s" to set node values. Signed-off-by:
Fabien Parent <fparent@baylibre.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
- Oct 13, 2016
-
-
Hannes Schmelzer authored
Sometimes devicetree nodes and or properties are added out of the u-boot console, maybe through some script or manual interaction. The devicetree as loaded or embedded is quite small, so the devicetree has to be resized to take up those new nodes/properties. In original the devicetree was only extended by effective 4 * add_mem_rsv. With this commit we can add an argument to the "fdt resize" command, which takes the extrasize to be added. Signed-off-by:
Hannes Schmelzer <hannes.schmelzer@br-automation.com> Signed-off-by:
Hannes Schmelzer <oe5hpm@oevsv.at> Acked-by:
Simon Glass <sjg@chromium.org>
-
- Aug 20, 2016
-
-
Maxime Ripard authored
The device tree overlays are a good way to deal with user-modifyable boards or boards with some kind of an expansion mechanism where we can easily plug new board in (like the BBB or the raspberry pi). However, so far, the usual mechanism to deal with it was to have in Linux some driver detecting the expansion boards plugged in and then request these overlays using the firmware interface. That works in most cases, but in some cases, you might want to have the overlays applied before the userspace comes in. Either because the new board requires some kind of an early initialization, or because your root filesystem is accessed through that expansion board. The easiest solution in such a case is to simply have the component before Linux applying that overlay, removing all these drawbacks. Reviewed-by:
Stefan Agner <stefan@agner.ch> Acked-by:
Pantelis Antoniou <pantelis.antoniou@konsulko.com> Acked-by:
Simon Glass <sjg@chromium.org> Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com>
-
Maxime Ripard authored
The current code only checks if the fdt subcommand is fdt addr by checking whether it starts with 'a'. Since this is a pretty widely used letter, narrow down that check a bit. Acked-by:
Simon Glass <sjg@chromium.org> Acked-by:
Pantelis Antoniou <pantelis.antoniou@konsulko.com> Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com>
-
- May 06, 2016
-
-
Robert P. J. Day authored
Spelling corrections for (among other things): * environment * override * variable * ftd (should be "fdt", for flattened device tree) * embedded * FTDI * emulation * controller
-
- 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 20, 2015
-
-
Sudeep Holla authored
Commit 90fbee3e ("cmd_fdt: Actually fix fdt command in sandbox") changed the format(from hex address to unsigned long) in which "fdtaddr" is saved . However do_fdt continues reads the "fdtaddr" assuming it to be in hex format. This may lead to fdt being either loaded or attempted to load at erroneous address generating fault if the address is out of memory. This patch changes back the format to hex while saving the "fdtaddr" as it was done before. Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Tom Rini <trini@konsulko.com> Cc: Simon Glass <sjg@chromium.org> Cc: Hua Yanghao <huayanghao@gmail.com> Cc: Heiko Schocher <hs@denx.de> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
Simon Glass <sjg@chromium.org>
-
- Apr 18, 2015
-
-
Joe Hershberger authored
In the case where the arch defines a custom map_sysmem(), make sure that including just mapmem.h is sufficient to have these functions as they are when the arch does not override it. Also split the non-arch specific functions out of common.h Signed-off-by:
Joe Hershberger <joe.hershberger@ni.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
- Feb 18, 2015
-
-
Joe Hershberger authored
If you want to inspect the control device tree using the fdt command, the "fdt address -c" command previously unhelpfully printed the phys memory address of the device tree. That address could not then be used to set the fdt address for inspection. Changed the resulting print to one that can be copied directly to the 'fdt address <addr>' command. Signed-off-by:
Joe Hershberger <joe.hershberger@ni.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
Joe Hershberger authored
Commit 90bac29a claims to fix this bug that was introduced in commit a92fd657 but doesn't actually make the change that the commit message describes. Actually fix the bug this time. Signed-off-by:
Joe Hershberger <joe.hershberger@ni.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
- Jan 05, 2015
-
-
Hua Yanghao authored
Instead of setting working_fdt to map_sysmem(addr) (e.g. blob), it should be set to addr directly as inside set_working_fdt_addr it uses map_sysmem(addr) again. To test: ./u-boot -d dts/dt.bin , then issue: fdt addr 0x100, fdt print will then cause an segmentation fault. After this fix fdt print is functional.
-
- Nov 21, 2014
-
-
Simon Glass authored
Add an additional function for adding information to the device tree before booting. This permits additions which are not board-specific. Signed-off-by:
Simon Glass <sjg@chromium.org> Acked-by:
Anatolij Gustschin <agust@denx.de> Reviewed-by:
Tom Rini <trini@ti.com>
-
Simon Glass authored
Since this function can fail, print a message when it does. Signed-off-by:
Simon Glass <sjg@chromium.org> Acked-by:
Anatolij Gustschin <agust@denx.de> Reviewed-by:
Tom Rini <trini@ti.com>
-
- Aug 09, 2014
-
-
Simon Glass authored
Since libfdt now has an fdt_resize() function, we need to rename the U-Boot one. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- Jun 19, 2014
-
-
Simon Glass authored
It is more common to have 0 mean OK, and -ve mean error. Change this function to work the same way to avoid confusion. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Masahiro Yamada authored
After all, we have realized "force" argument is completely useless. fdt_chosen() was always called with force = 1. We should always want to do the same thing (set appropriate value to the property) even if the property already exists. Signed-off-by:
Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
Masahiro Yamada authored
After all, we have realized "force" argument is completely useless. fdt_initrd() was always called with force = 1. We should always want to do the same thing (set appropriate value to the property) even if the property already exists. Signed-off-by:
Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
- Mar 21, 2014
-
-
Heiko Schocher authored
check if a fdt is correct signed pass an optional addr value. Contains the addr of the key blob Signed-off-by:
Heiko Schocher <hs@denx.de> Acked-by:
Simon Glass <sjg@chromium.org>
-
- 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>
-
- May 01, 2013
-
-
Simon Glass authored
By using map_sysmem() we can get the fdt command to work correctly with sandbox. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
There is an existing fdt command to deal with the working FDT. Enhance this to support the control FDT also (CONFIG_OF_CONTROL). Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
At present this only checks working_fdt, but we want to check other FDTs also. So add the FDT to check as a parameter to fdt_valid(). Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- Mar 01, 2013
-
-
Simon Glass authored
We might as well use this common function instead of repeating the same code. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- Feb 08, 2013
-
-
Kim Phillips authored
and, if including libfdt.h which includes libfdt_env.h in the correct order, don't include fdt.h before libfdt.h. this is needed to get the fdt type definitions set from the project environment before fdt.h uses them. Signed-off-by:
Kim Phillips <kim.phillips@freescale.com> Cc: Jerry Van Baren <gvb.uboot@gmail.com>
-
- Nov 04, 2012
-
-
Kim Phillips authored
cmd_boot.c:40:5: warning: symbol 'do_go' was not declared. Should it be static? cmd_bootm.c:164:6: warning: symbol '__arch_preboot_os' was not declared. Should it be static? cmd_bootm.c:477:5: warning: symbol 'do_bootm_subcommand' was not declared. Should it be static? cmd_bootm.c:1022:1: error: directive in argument list cmd_bootm.c:1028:1: error: directive in argument list cmd_bootm.c:1029:1: error: directive in argument list cmd_bootm.c:1036:1: error: directive in argument list cmd_bootm.c:1042:1: error: directive in argument list cmd_bootm.c:1044:1: error: directive in argument list cmd_bootm.c:1045:1: error: directive in argument list cmd_bootm.c:1047:1: error: directive in argument list cmd_bootm.c:1089:5: warning: symbol 'do_iminfo' was not declared. Should it be static? cmd_bootm.c:1176:5: warning: symbol 'do_imls' was not declared. Should it be static? cmd_bootm.c:1654:1: error: directive in argument list cmd_bootm.c:1660:1: error: directive in argument list cmd_console.c:32:5: warning: symbol 'do_coninfo' was not declared. Should it be s cmd_date.c:46:5: warning: symbol 'do_date' was not declared. Should it be static? cmd_echo.c:27:5: warning: symbol 'do_echo' was not declared. Should it be static? cmd_exit.c:27:5: warning: symbol 'do_exit' was not declared. Should it be static? cmd_fat.c:97:5: warning: symbol 'do_fat_ls' was not declared. Should it be static? cmd_fat.c:136:5: warning: symbol 'do_fat_fsinfo' was not declared. Should it be s cmd_fdt.c:66:5: warning: symbol 'do_fdt' was not declared. Should it be static? cmd_fdt.c:542:43: warning: incorrect type in assignment (different base types) cmd_fdt.c:542:43: expected unsigned int [unsigned] [usertype] <noident> cmd_fdt.c:542:43: got restricted __be32 [usertype] <noident> cmd_fdt.c:679:42: warning: cast to restricted __be32 cmd_fdt.c:820:1: error: directive in argument list cmd_fdt.c:822:1: error: directive in argument list cmd_flash.c:292:5: warning: symbol 'do_flinfo' was not declared. Should it be static? cmd_flash.c:324:5: warning: symbol 'do_flerase' was not declared. Should it be static? cmd_flash.c:457:5: warning: symbol 'do_protect' was not declared. Should it be st cmd_help.c:27:5: warning: symbol 'do_help' was not declared. Should it be static? cmd_i2c.c:136:6: warning: symbol '__def_i2c_init_board' was not declared. Should it be static? cmd_i2c.c:144:14: warning: symbol '__def_i2c_get_bus_speed' was not declared. Should it be static? cmd_i2c.c:151:5: warning: symbol '__def_i2c_set_bus_speed' was not declared. Should it be static? cmd_i2c.c:1322:1: error: directive in argument list cmd_i2c.c:1324:1: error: directive in argument list cmd_i2c.c:1326:1: error: directive in argument list cmd_i2c.c:1328:1: error: directive in argument list cmd_i2c.c:1337:1: error: directive in argument list cmd_i2c.c:1339:1: error: directive in argument list cmd_irq.c:27:5: warning: symbol 'do_interrupts' was not declared. Should it be static? cmd_itest.c:133:5: warning: symbol 'binary_test' was not declared. Should it be static? cmd_itest.c:158:5: warning: symbol 'do_itest' was not declared. Should it be stat cmd_load.c:54:5: warning: symbol 'do_load_serial' was not declared. Should it be static? cmd_load.c:431:6: warning: symbol 'his_eol' was not declared. Should it be static? cmd_load.c:432:6: warning: symbol 'his_pad_count' was not declared. Should it be static? cmd_load.c:433:6: warning: symbol 'his_pad_char' was not declared. Should it be static? cmd_load.c:434:6: warning: symbol 'his_quote' was not declared. Should it be static? cmd_load.c:436:5: warning: symbol 'do_load_serial_bin' was not declared. Should it be static? cmd_load.c:549:6: warning: symbol 'send_pad' was not declared. Should it be static? cmd_load.c:558:6: warning: symbol 'ktrans' was not declared. Should it be static? cmd_load.c:568:5: warning: symbol 'chk1' was not declared. Should it be static? cmd_load.c:578:6: warning: symbol 's1_sendpacket' was not declared. Should it be static? cmd_load.c:587:6: warning: symbol 'send_ack' was not declared. Should it be static? cmd_load.c:600:6: warning: symbol 'send_nack' was not declared. Should it be static? cmd_load.c:614:6: warning: symbol 'os_data_init' was not declared. Should it be static? cmd_load.c:615:6: warning: symbol 'os_data_char' was not declared. Should it be static? cmd_load.c:657:6: warning: symbol 'k_data_init' was not declared. Should it be static? cmd_load.c:663:6: warning: symbol 'k_data_save' was not declared. Should it be static? cmd_load.c:669:6: warning: symbol 'k_data_restore' was not declared. Should it be static? cmd_load.c:675:6: warning: symbol 'k_data_char' was not declared. Should it be static? cmd_load.c:693:6: warning: symbol 'send_parms' was not declared. Should it be static? cmd_load.c:694:6: warning: symbol 'send_ptr' was not declared. Should it be static? cmd_load.c:698:6: warning: symbol 'handle_send_packet' was not declared. Should i cmd_mdio.c:60:5: warning: symbol 'mdio_write_ranges' was not declared. Should it be static? cmd_mdio.c:82:5: warning: symbol 'mdio_read_ranges' was not declared. Should it be static? cmd_mdio.c:115:5: warning: symbol 'extract_reg_range' was not declared. Should it be static? cmd_mdio.c:144:5: warning: symbol 'extract_phy_range' was not declared. Should it cmd_mem.c:54:5: warning: symbol 'do_mem_md' was not declared. Should it be static? cmd_mem.c:150:5: warning: symbol 'do_mem_mm' was not declared. Should it be static? cmd_mem.c:154:5: warning: symbol 'do_mem_nm' was not declared. Should it be static? cmd_mem.c:159:5: warning: symbol 'do_mem_mw' was not declared. Should it be static? cmd_mem.c:256:5: warning: symbol 'do_mem_cmp' was not declared. Should it be static? cmd_mem.c:326:5: warning: symbol 'do_mem_cp' was not declared. Should it be static? cmd_mem.c:436:5: warning: symbol 'do_mem_base' was not declared. Should it be static? cmd_mem.c:449:5: warning: symbol 'do_mem_loop' was not declared. Should it be static? cmd_mem.c:595:5: warning: symbol 'do_mem_mtest' was not declared. Should it be static? cmd_mem.c:618:26: warning: Using plain integer as NULL pointer cmd_mem.c:1057:5: warning: symbol 'do_mem_crc' was not declared. Should it be static? cmd_misc.c:30:5: warning: symbol 'do_sleep' was not declared. Should it be static cmd_mmc.c:118:5: warning: symbol 'do_mmcinfo' was not declared. Should it be static? cmd_mmc.c:272:32: warning: Using plain integer as NULL pointer cmd_mmc.c:150:5: warning: symbol 'do_mmcops' was not declared. Should it be stati cmd_mp.c:27:1: warning: symbol 'cpu_cmd' was not declared. Should it be static? cmd_mp.c:85:1: error: directive in argument list cmd_mp.c:88:1: error: directive in argument list cmd_mtdparts.c:150:18: warning: symbol 'mtdids' was not declared. Should it be static? cmd_mtdparts.c:153:18: warning: symbol 'devices' was not declared. Should it be static? cmd_mtdparts.c:713:5: warning: symbol 'mtd_device_validate' was not declared. Should it be static? cmd_mtdparts.c:1887:5: warning: symbol 'do_chpart' was not declared. Should it be static? cmd_mtdparts.c:1925:5: warning: symbol 'do_mtdparts' was not declared. Should it be static? cmd_mtdparts.c:2060:1: error: directive in argument list cmd_mtdparts.c:2063:1: error: directive in argument list cmd_mtdparts.c:2066:1: error: directive in argument list cmd_mtdparts.c:2071:1: error: directive in argument list cmd_mtdparts.c:2073:1: error: directive in argument list cmd_nand.c:377:18: error: bad constant expression cmd_nand.c:431:5: warning: symbol 'do_nand' was not declared. Should it be static? cmd_nand.c:796:1: error: directive in argument list cmd_nand.c:801:1: error: directive in argument list cmd_nand.c:802:1: error: directive in argument list cmd_nand.c:806:1: error: directive in argument list cmd_nand.c:819:1: error: directive in argument list cmd_nand.c:824:1: error: directive in argument list cmd_nand.c:825:1: error: directive in argument list cmd_nand.c:831:1: error: directive in argument list cmd_nand.c:918:5: warning: symbol 'do_nandboot' was not declared. Should it be static? cmd_net.c:33:5: warning: symbol 'do_bootp' was not declared. Should it be static? cmd_net.c:107:5: warning: symbol 'do_dhcp' was not declared. Should it be static? cmd_net.c:120:5: warning: symbol 'do_nfs' was not declared. Should it be static? cmd_nvedit.c:138:5: warning: symbol 'do_env_print' was not declared. Should it be static? cmd_nvedit.c:323:5: warning: symbol '_do_env_set' was not declared. Should it be static? cmd_nvedit.c:435:5: warning: symbol 'do_env_set' was not declared. Should it be static? cmd_nvedit.c:514:5: warning: symbol 'do_env_edit' was not declared. Should it be static? cmd_nvedit.c:620:5: warning: symbol 'do_env_save' was not declared. Should it be static? cmd_nvedit.c:1016:1: error: directive in argument list cmd_nvedit.c:1018:1: error: directive in argument list cmd_nvedit.c:1021:1: error: directive in argument list cmd_nvedit.c:1023:1: error: directive in argument list cmd_nvedit.c:1024:1: error: directive in argument list cmd_nvedit.c:1026:1: error: directive in argument list cmd_nvedit.c:1027:1: error: directive in argument list cmd_nvedit.c:1029:1: error: directive in argument list cmd_nvedit.c:1030:1: error: directive in argument list cmd_nvedit.c:1032:1: error: directive in argument list cmd_nvedit.c:1034:1: error: directive in argument list cmd_nvedit.c:1036:1: error: directive in argument list cmd_nvedit.c:1037:1: error: directive in argument list cmd_nvedit.c:1039:1: error: directive in argument list cmd_pci.c:38:17: warning: symbol 'ShortPCIListing' was not declared. Should it be static? cmd_pci.c:38:22: warning: 'ShortPCIListing' defined but not used [-Wunused-variable] cmd_pci.c:411:5: warning: symbol 'do_pci' was not declared. Should it be static? cmd_pci.c:494:1: error: directive in argument list cmd_pci.c:497:1: error: directive in argument list cmd_reginfo.c:40:5: warning: symbol 'do_reginfo' was not declared. Should it be static? cmd_sata.c:31:5: warning: symbol 'sata_curr_device' was not declared. Should it be static? note -> ata_piix.c doesn't seem to use 'sata_curr_device'; deleted. cmd_sata.c:32:18: warning: symbol 'sata_dev_desc' was not declared. Should it be static? cmd_sata.c:70:5: warning: symbol 'do_sata' was not declared. Should it be static? cmd_setexpr.c:53:5: warning: symbol 'do_setexpr' was not declared. Should it be static? cmd_source.c:186:1: error: directive in argument list cmd_source.c:190:1: error: directive in argument list cmd_test.c:27:5: warning: symbol 'do_test' was not declared. Should it be static? cmd_test.c:153:5: warning: symbol 'do_false' was not declared. Should it be static? cmd_test.c:164:5: warning: symbol 'do_true' was not declared. Should it be static cmd_usb.c:43:6: warning: symbol 'usb_get_class_desc' was not declared. Should it be static? cmd_usb.c:69:6: warning: symbol 'usb_display_class_sub' was not declared. Should it be static? cmd_usb.c:151:6: warning: symbol 'usb_display_string' was not declared. Should it be static? cmd_usb.c:161:6: warning: symbol 'usb_display_desc' was not declared. Should it be static? cmd_usb.c:195:6: warning: symbol 'usb_display_conf_desc' was not declared. Should it be static? cmd_usb.c:210:6: warning: symbol 'usb_display_if_desc' was not declared. Should it be static? cmd_usb.c:227:6: warning: symbol 'usb_display_ep_desc' was not declared. Should it be static? cmd_usb.c:252:6: warning: symbol 'usb_display_config' was not declared. Should it be static? cmd_usb.c:283:6: warning: symbol 'usb_show_tree_graph' was not declared. Should it be static? cmd_usb.c:343:6: warning: symbol 'usb_show_tree' was not declared. Should it be static? cmd_usb.c:356:5: warning: symbol 'do_usbboot' was not declared. Should it be static? cmd_usb.c:366:5: warning: symbol 'do_usb' was not declared. Should it be static? cmd_version.c:31:5: warning: symbol 'do_version' was not declared. Should it be s cmd_ximg.c:46:1: warning: symbol 'do_imgextract' was not declared. Should it be static? cmd_ximg.c:272:1: error: directive in argument list cmd_ximg.c:276:1: error: directive in argument list Signed-off-by:
Kim Phillips <kim.phillips@freescale.com>
-
- Nov 02, 2012
-
-
Tom Rini authored
When putting pointers into a format string use %p to ensure that they are printed correctly regardless of bitsize. This fixes warnings on sandbox on 64bit systems. Cc: Joe Hershberger <joe.hershberger@ni.com> Cc: Gerald Van Baren <vanbaren@cideas.com> Signed-off-by:
Tom Rini <trini@ti.com> Acked-by:
Joe Hershberger <joe.hershberger@ni.com>
-
- Oct 15, 2012
-
-
Joe Hershberger authored
Scripts in the ITB format will have spaces in them and will end in a newline charachter. Make sure that these are considered printable. Signed-off-by:
Joe Hershberger <joe.hershberger@ni.com>
-
Joe Hershberger authored
Add commands to access data in the fdt. This allows data from a dtb or itb to be accessed from the shell scripts. Signed-off-by:
Joe Hershberger <joe.hershberger@ni.com>
-