summaryrefslogtreecommitdiff
path: root/cmd
Commit message (Collapse)AuthorAgeLines
...
* i2c: spd: Extend SPD memory typesMichal Simek2016-02-22-1/+13
| | | | | | Decode DDR, DDR3 and DDR4 memories. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* gpio: Correct handling of 'gpio status'Simon Glass2016-02-15-1/+1
| | | | | | | | | | | | This is broken - we need to look at the first two characters to distinguish 'gpio status' from 'gpio set'. Fixes: 0ffe6ab5 (gpio: Allow 's' as an abbreviation for 'status') Reported-by: Soeren Moch <smoch@web.de> Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Soeren Moch <smoch@web.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Hannes Schmelzer <oe5hpm@oevsv.at>
* itest: allow map_physmem to return 0 in limited casesStephen Warren2016-02-09-1/+1
| | | | | | | | | | | | | | | | | | | | | | On some systems, RAM starts at address 0. If the user executes itest against address 0 on such a system, it will call map_physmem(0, ...) which will return 0 back; mapping only changes the address on sandbox. This causes itest to believe map_physmem() has failed, and hence fails the comparison. Fix itest so that it allows map_physmem() to return 0 /if/ the orignal address passed to it was also 0. This fixes "tegra-uboot-flasher flash" on Tegra20. This has the disadvantage that on sandbox, failed mapping attempts for address 0 are not detected. Instead, should the code only call map_physmem() on sandbox? Or, should map_physmem() return its error status some other way. Or, should the special case only be allowed on systems where the base of RAM is 0 somehow? Fixes: 7861204c9af7 ("itest: make memory access work under sandbox") Signed-off-by: Stephen Warren <swarren@nvidia.com>
* Remove unused CONFIG_CMD_HWFLOW option and associated dead code.David Müller (ELSOFT AG)2016-02-08-30/+0
| | | | Signed-off-by: David Müller <d.mueller@elsoft.ch>
* cmd: Fix control bmp_display()Simon Glass2016-02-06-2/+1
| | | | | | | | | All paths should share the same return. Reported-by: Coverity (CID:134903) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
* Use correct spelling of "U-Boot"Bin Meng2016-02-06-8/+8
| | | | | | | | | | Correct spelling of "U-Boot" shall be used in all written text (documentation, comments in source files etc.). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>
* Merge git://git.denx.de/u-boot-dmTom Rini2016-01-29-14/+6
|\
| * Implement "pci enum" command for CONFIG_DM_PCIStephen Warren2016-01-28-13/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With CONFIG_DM_PCI enabled, PCI buses are not enumerated at boot, as they are without that config option enabled. No command exists to enumerate the PCI buses. Hence, unless some board-specific code causes PCI enumeration, PCI-based Ethernet devices are not detected, and network access is not available. This patch implements "pci enum" in the CONFIG_DM_PCI case, thus giving a mechanism whereby PCI can be enumerated. do_pci()'s handling of case 'e' is moved into a single location before the dev variable is assigned, in order to skip calculation of dev. The enum sub-command doesn't need the dev value, and skipping its calculation avoids an irrelevant error being printed. Using a command to initialize PCI like this has a disadvantage relative to enumerating PCI at boot. In particular, Ethernet devices are not probed during PCI enumeration, but only when used. This defers setting variables such as ethact, ethaddr, etc. until the first network-related command is executed. Hopefully this will not cause further issues. Perhaps in the long term, we need a "net start/enum" command too? Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * tpm: Fix fault in case CONFIG_DM_TPM is set without any TPMChristophe Ricard2016-01-28-1/+1
| | | | | | | | | | | | | | | | In case CONFIG_DM_TPM was set without any TPM chipset configured a fault was generated (NULL pointer access). Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
* | Merge branch 'master' of git://git.denx.de/u-boot-netTom Rini2016-01-28-2/+76
|/
* fpga: Fix compilation warningsMichal Simek2016-01-27-4/+4
| | | | Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* microblaze: Do not print eth device when DM_ETH is enabledMichal Simek2016-01-27-1/+1
| | | | | | | | | Doing the same fix as is done for ARM by: "Avoid calling print_eths() with driver model" (sha1: ff97380015b6b5d7d6267417a1cd6fc0e67b81bc) Signed-off-by: Michal Simek <michal.simek@xilinx.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
* bug.h: move BUILD_BUG_* defines to include/linux/bug.hMasahiro Yamada2016-01-25-0/+1
| | | | | | | | | | | | | | | | BUILD_BUG_* macros have been defined in several headers. It would be nice to collect them in include/linux/bug.h like Linux. This commit is cherry-picking useful macros from include/linux/bug.h of Linux 4.4. I did not import BUILD_BUG_ON_MSG() because it would not work if it is used with include/common.h in U-Boot. I'd like to postpone it until the root cause (the "error()" macro in include/common.h causes the name conflict with "__attribute__((error()))") is fixed. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* Remove the cmd_ prefix from command filesSimon Glass2016-01-25-129/+129
| | | | | | | | | | | | 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>
* Move all command code into its own directorySimon Glass2016-01-25-0/+43205
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>
generated by cgit v1.1 at 2024-11-09 22:56:34 +0000