summaryrefslogtreecommitdiff
path: root/cmd
Commit message (Collapse)AuthorAgeLines
* trace: Fix compiler warnings in traceSimon Glass2016-02-26-2/+2
| | | | | | | | With min() we must use the same type for each parameter. Fix two problems in trace.c which produce compiler warnings. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* Merge branch 'master' of git://git.denx.de/u-boot-usbTom Rini2016-02-24-0/+20
|\
| * dfu: usb: f_dfu: Set deferred call for dfu_flush() functionLukasz Majewski2016-02-24-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes situation when one would like to write large file into medium with the file system (fat, ext4, etc). This change sets file size limitation to the DFU internal buffer size. Since u-boot is not supporting interrupts and seek on file systems, it becomes challenging to store large file appropriately. To reproduce this error - create large file (around 26 MiB) and sent it to the target board. Lets examine the flow of USB transactions: 0. DFU uses EP0 with 64B MPS [Max Packet Size] 1. Send file - OUT (PC->target) - dat_26MiB.img is sent with 4096 B transactions 2. Get status - OUT (PC->target) - wait for DFU_STATE_dfuDNLOAD_IDLE (0x05) sent from target board - IN transaction (target->PC) 3. The whole file content is sent to target - OUT (PC->target) with ZLP [Zero Length Packet] Now the interesting part starts: 4. OUT (PC->target) Setup transaction (request to share DFU state) 5. IN (target->PC) - reply the current DFU state - In the UDC driver the req->completion (with dfu_flush) is called after successful IN transfer. - The dfu_flush() (called from req->completion callback) saves the whole file at once (u-boot doesn't support seek on fs). Such operation takes considerable time. When the file is large - e.g. 26MiB - this time may be more than 5 seconds. 6. OUT (PC->target) - ZLP, is send in the same time when dfu_flush() writes data to eMMC memory. The dfu-util application has hard coded timeout on USB transaction completion set to 5 seconds (it uses libusb calls). When the file to store is large (e.g. 26 MiB) the time needed to write it may excess the dfu-util timeout and following error message will be displayed: "unable to read DFU status" on the HOST PC console. This change is supposed to leverage DFU's part responsible for storing files on file systems. Other DFU operations - i.e. raw/partition write to NAND and eMMC should work as before. The only functional change is the error reporting. When dfu_flush() fails the u-boot prompt will exit with error information and dfu-util application exits afterwards as well. Test HW: - Odroid XU3 (Exynos5433) - test with large file - Trats (Exynos4210) - test for regression - eMMC, raw, Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Reported-by: Alex Gdalevich <agdalevich@axion-biosystems.com> Tested-by: Stephen Warren <swarren@nvidia.com> Tested-by: Heiko Schocher <hs@denx.de>
* | cmd: mem: Show 64bit addresses which are testedMichal Simek2016-02-24-1/+1
| | | | | | | | | | | | Fix print message to show full 64bit addresses. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* | booti: Help text rework.Karsten Merker2016-02-24-7/+7
|/ | | | | | | Fix spelling errors in the "booti" help text and bring it more in line with the bootm/bootz help texts. Signed-off-by: Karsten Merker <merker@debian.org>
* 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 19:24:37 +0000