- 17 9月, 2014 1 次提交
-
-
由 Peng Fan 提交于
There are two ways to run into handle_exception, run command 'kgdb' and encounter a breakpoint which triggers exception handling. The origin source code only saves regs when first run command 'kgdb'. Take the following for example, When run 'kgdb', regs is saved to entry_regs. When run 'bootz', regs is not saved. However, if we set a breakpoint, then continue. When breakpoint is reached, run `quit`, and Now return to the instruction which follows kgdb, but not bootz.This may cause errors. So, save regs for each handle_exception call to return to the correct place. Example: Target | Host =>kgdb | (gdb)b bootz | (gdb)c =>bootz | | (gdb)Here stop because of breakpoint | (gdb)q Signed-off-by: NPeng Fan <van.freenix@gmail.com>
-
- 16 9月, 2014 1 次提交
-
-
由 Vasili Galka 提交于
The parameters of size_t type shall be formatted using "%zu" and not using "%d". Precision argument for the "%.*s" parameters shall be of int type. Signed-off-by: NVasili Galka <vvv444@gmail.com>
-
- 11 9月, 2014 3 次提交
-
-
由 Simon Glass 提交于
For some boards board_init() will change GPIOs, so we need to have driver model available before then. Adjust the board init to arrange this, but enable it for driver model only, just to be safe. This does create additional #ifdef logic, but it is safer than trying to make a pervasive change which may cause some boards to break. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Since driver model registers itself with the stdio subsystem, and we want to avoid delayed registration and other complexity associated with the current serial console, move the stdio subsystem init earlier when driver model is used for serial. This simplifies the implementation. Should there be any problems with this approach they can be dealt with as boards are converted over to use driver model for serial. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
In order to support GPIO access in board_early_init_f() we must set up driver model before this function is called. In any case, earlier is better since driver model is (or will become) a key function for most init. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 09 9月, 2014 1 次提交
-
-
由 Jeroen Hofstee 提交于
For ARM / ARM64 the relocation routines already updated gd to the new value. Don't set it again. This allows compilation with clang as it cannot update gd directly. cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Signed-off-by: NJeroen Hofstee <jeroen@myspectrum.nl>
-
- 02 9月, 2014 1 次提交
-
-
由 Lukasz Majewski 提交于
This commit provides distinction between DFU device detach and reset. The -R behavior is preserved with proper handling of the dfu-util's -e switch, which detach the DFU device. By running dfu-util -e; one can force device to finish the execution of dfu command on target and execute some other scripted commands. Moreover, some naming has been changed - the dfu_reset() method now is known as dfu_detach(). New name better reflects the purpose of the code. It was also necessary to increase the number of usb_gadget_handle_interrupts() calls since we also must wait for detection of the USB reset event. Example usage: 1. -e (detach) switch dfu-util -a0 -D file1.bin;dfu-util -a3 -D uImage;dfu-util -e access to u-boot prompt. 2. -R (reset) switch dfu-util -a0 -D file1.bin;dfu-util -R -a3 -D uImage target board reset Signed-off-by: NLukasz Majewski <l.majewski@samsung.com> Reviewed-by: NStephen Warren <swarren@nvidia.com> Tested-by: NStephen Warren <swarren@nvidia.com>
-
- 01 9月, 2014 2 次提交
-
-
由 Simon Glass 提交于
The gpio command mostly relies on gpio_request() and gpio_free() being nops, in that you can request a GPIO twice. With driver model this is now implemented correctly, so it fails. Change the command to deal with a failure to claim the GPIO. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
The GPIO list is very long in many cases and most of them are not used. By default, show only the GPIOs that are in use, and provide a flag to show all of them. This makes the 'gpio status' command much more pleasant. In order to do this, driver model now exposes a method for obtaining the 'function' of a GPIO, which describes whether it is an input or output, for example. Implementation of this method is optional. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 30 8月, 2014 1 次提交
-
-
由 Tom Rini 提交于
The default format for arm64 Linux kernels is the "Image" format, described in Documentation/arm64/booting.txt. This, along with an optional gzip compression on top is all that is generated by default. The Image format has a magic number within the header for verification, a text_offset where the Image must be run from, an image_size that includes the BSS and reserved fields. This does not support automatic detection of a gzip compressed image. Signed-off-by: NTom Rini <trini@ti.com>
-
- 29 8月, 2014 3 次提交
-
-
由 Stephen Warren 提交于
One specific USB 3.0 device behaves strangely when reset by usb_new_device()'s call to hub_port_reset(). For some reason, the device appears to briefly drop off the bus when this second bus reset is executed, yet if we retry this loop, it'll eventually come back after another two resets. If USB bus reset is executed over and over within usb_new_device()'s call to hub_port_reset(), I see the following sequence of results, which repeats as long as you want: 1) STAT_C_CONNECTION = 1 STAT_CONNECTION = 0 USB_PORT_STAT_ENABLE 0 2) STAT_C_CONNECTION = 1 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 0 3) STAT_C_CONNECTION = 1 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 1 The device in question is a SanDisk Ultra USB 3.0 16GB memory stick with USB VID/PID 0x0781/0x5581. In order to allow this device to work with U-Boot, ignore the {C_,}CONNECTION bits in the status/change registers, and only use the ENABLE bit to determine if the reset was successful. To be honest, extensive investigation has failed to determine why this problem occurs. I'd love to know! I don't know if it's caused by: * A HW bug in the device * A HW bug in the Tegra USB controller * A SW bug in the U-Boot Tegra USB driver * A SW bug in the U-Boot USB core This issue only occurs when the device's USB3 pins are attached to the host; if only the USB2 pins are connected the issue does not occur. The USB3 controller on Tegra is in reset, so is not actively communicating with the device at all - a USB3 analyzer confirms this. Slightly unplugging the device (so the USB3 pins don't contact) or using a USB2 cable or hub as an intermediary avoids the problem. For some reason, the Linux kernel (either on the same Tegra board, or on an x86 host) has no issue with the device, and I observe no disconnections during reset. This change won't affect any USB device that already works, since such devices could not currently be triggering the error return this patch removes, or they wouldn't be working currently. However, this patch is quite reliable in practice, hence I hope it's acceptable to solve the problem. The only potential fallout I can see from this patch is: * A broken device that triggers C_CONNECTION/!CONNECTION now causes the loop in hub_port_reset() to run multiple times. If it never succeeds, this will cause "usb start" to take roughly 1s extra to execute. * If the user unplugs a device while hub_port_reset() is executing, and very quickly swaps in a new device, hub_port_reset() might succeed on the new device. This would mean that any information cached about the original device (from the descriptor read in usb_new_device(), which simply caches the max packet size) might be invalid, which would cause problems talking to the new device. However, without this change, the new device wouldn't work anyway, so this is probably not much of a loss. Signed-off-by: NStephen Warren <swarren@nvidia.com>
-
由 Marek Vasut 提交于
As we support both Host and Device mode operation, an OTG controller can return -ENODEV on a port which it found to be in Device mode during Host mode scan for devices. In case -ENODEV is returned, print that the port is not available and continue instead of screaming a bloody error message. Signed-off-by: NMarek Vasut <marex@denx.de>
-
由 Simon Glass 提交于
Commit e3a5bbce broke the FIT image tests by not loading a ramdisk even if a load address is provided in the FIT. The rationale was that a load address of 0 should be considered to mean 'do not load'. Add a new load operation which supports this feature, so that the ramdisk will be loaded if a non-zero load address is provided. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 26 8月, 2014 1 次提交
-
-
由 Heiko Schocher 提交于
resync ubi subsystem with linux: commit 455c6fdbd219161bd09b1165f11699d6d73de11c Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Sun Mar 30 20:40:15 2014 -0700 Linux 3.14 A nice side effect of this, is we introduce UBI Fastmap support to U-Boot. Signed-off-by: NHeiko Schocher <hs@denx.de> Signed-off-by: NTom Rini <trini@ti.com> Cc: Marek Vasut <marex@denx.de> Cc: Sergey Lapin <slapin@ossfans.org> Cc: Scott Wood <scottwood@freescale.com> Cc: Joerg Krause <jkrause@posteo.de>
-
- 25 8月, 2014 1 次提交
-
-
由 Tom Rini 提交于
CONFIG_SPL_NET_SUPPORT is not the only time we want SPL to ahve environment, CONFIG_SPL_ENV_SUPPORT is when we want it. Signed-off-by: NTom Rini <trini@ti.com>
-
- 24 8月, 2014 1 次提交
-
-
由 Thomas Chou 提交于
This patch implements the generic board init as described in doc/README.generic-board. Signed-off-by: NThomas Chou <thomas@wytron.com.tw> Signed-off-by: NScott McNutt <smcnutt@psyent.com> Reviewed-by: NStefan Roese <sr@denx.de>
-
- 22 8月, 2014 4 次提交
-
-
由 Bryan Wu 提交于
arg[0] might not be NULL even if argc < 1, so fix this as before. Signed-off-by: NBryan Wu <pengw@nvidia.com>
-
由 Bryan Wu 提交于
Commit b3dd64f5 "bootm: use genimg_get_kernel_addr()" introduced a bug for booting FIT image. It's because calling fit_parse_config() twice will give us wrong value in img_addr. Add a new function genimg_get_kernel_addr_fit() whichl will always return fit_uname_config and fit_uname_kernel for CONFIG_FIT. genimg_get_kernel_addr() will ignore those to parameters. Reported-by: NYork Sun <yorksun@freescale.com> Signed-off-by: NBryan Wu <pengw@nvidia.com>
-
由 Hans de Goede 提交于
Use cli_simple_process_macros, so that environment variables (e.g. ${console}) can be used in append strings. Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Hans de Goede 提交于
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
- 20 8月, 2014 1 次提交
-
-
由 Gabriel Huau 提交于
This allows u-boot to load different OS or Bare Metal application on different cores of the i.MX6 SoC. For example: running Android on cpu0 and a RT OS like QNX/FreeRTOS on cpu1. Signed-off-by: NGabriel Huau <contact@huau-gabriel.fr> Acked-by: NStefano Babic <sbabic@denx.de>
-
- 14 8月, 2014 1 次提交
-
-
由 Heiko Schocher 提交于
add missing put_mtd_device, so mtd->usecount gets correct decremented in get_mtd_info(). Signed-off-by: NHeiko Schocher <hs@denx.de> Cc: Scott Wood <scottwood@freescale.com> Cc: Tom Rini <trini@ti.com>
-
- 12 8月, 2014 1 次提交
-
-
由 Hannes Petermaier 提交于
most todays LCDs support 32bpp e.g. the framebuffer memory is 32bpp organized. To support 24bpp BMPs we need to take only 3 byte from the bpp and set one byte from the FB to 0. Signed-off-by: NHannes Petermaier <oe5hpm@oevsv.at>
-
- 11 8月, 2014 1 次提交
-
-
由 Jeroen Hofstee 提交于
prevents a clang warning that the function is never used. cc: agust@denx.de Signed-off-by: NJeroen Hofstee <jeroen@myspectrum.nl>
-
- 10 8月, 2014 2 次提交
-
-
由 Hannes Petermaier 提交于
This patch removes following two functions: - lcd_getbgcolor(...) not used somewhere outside lcd.c, internally we use now the global variable lcd_color_bg (was return value of function before) - lcd_getfgcolor(...) not used in any place of u-boot Signed-off-by: NHannes Petermaier <oe5hpm@oevsv.at> [agust: rebased] Signed-off-by: NAnatolij Gustschin <agust@denx.de>
-
由 Hannes Petermaier 提交于
- Adds support for 32-bit organized framebuffers to the LCD-framework. Signed-off-by: NHannes Petermaier <oe5hpm@oevsv.at> Cc: agust@denx.de
-
- 09 8月, 2014 11 次提交
-
-
由 Tom Rini 提交于
We must ensure the buffer we read the env into is aligned or we may get warnings later on. Signed-off-by: NTom Rini <trini@ti.com>
-
由 Bryan Wu 提交于
Use the new API which is originally taken out from boot_get_kernel of bootm.c Signed-off-by: NBryan Wu <pengw@nvidia.com> Tested-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NStephen Warren <swarren@nvidia.com> [trini: Fix warnings with CONFIG_FIT] Signed-off-by: NTom Rini <trini@ti.com>
-
由 Bryan Wu 提交于
Trying bootm for zImage will print out several error message which is not necessary for this case. So detect image format firstly, only try bootm for legacy and FIT format image then try bootz for others. This patch needs new function genimg_get_kernel_addr(). Signed-off-by: NBryan Wu <pengw@nvidia.com>
-
由 Bryan Wu 提交于
Kernel address is normally stored as a string argument of bootm or bootz. This function is taken out from boot_get_kernel() of bootm.c, which can be reused by others. Signed-off-by: NBryan Wu <pengw@nvidia.com> [trini: Fix warnings with CONFIG_FIT] Signed-off-by: NTom Rini <trini@ti.com>
-
由 Simon Glass 提交于
Since libfdt now has an fdt_resize() function, we need to rename the U-Boot one. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Pavel Machek 提交于
Fix ext4load help text. Signed-off-by: NPavel Machek <pavel@denx.de>
-
由 Ian Campbell 提交于
I happened to spot this while working in the area. Signed-off-by: NIan Campbell <ijc@hellion.org.uk> Acked-by: NSimon Glass <sjg@chromium.org> Cc: Simon Glass <sjg@chromium.org>
-
由 Stephen Warren 提交于
When "pxe boot" downloads the initrd/kernel/DTB, netboot_common() saves the downloaded filename to global variable BootFile. If the boot operation is aborted, this global state is not cleared. If "dhcp" is executed later without any arguments, BootFile is not cleared, and when the DHCP response is received, BootpCopyNetParams() writes the value into environment variable bootfile. This causes the following scenario: * Boot script executes dhcp; pxe get; pxe boot * User CTRL-C's the PXE menu, which causes the first menu item to be booted, which causes some file to be downloaded. (This boot-on-CTRL-C behaviour is arguably a bug too, but it's a separate bug and the bug this patch fixes would still exist if the user simply waited to press CTRL-C until "pxe boot" started downloading files) * User CTRL-C's the file downloads, but the filename is still written to the bootfile environment variable. * User re-runs the boot command, which in my case executes "dhcp; pxe get; pxe boot" again, and "dhcp" picks up the saved bootfile environment variable and proceeds to download a file that it shouldn't. To solve this, modify the implementation of "pxe get" to clear BootFile if the whole boot operation fails, which avoids this whole mess. An alternative would be to modify netboot_common() such that the no- arguments case explicitly clears the global variable BootFile. However, that would prevent the following command sequences from working: $ dhcp filename # downloads "filename" $ dhcp # downloads $bootfile, i.e. "filename" or: $ setenv bootfile filename $ dhcp # downloads $bootfile, i.e. "filename" ... and I assume someone relies on U-Boot working that way. Signed-off-by: NStephen Warren <swarren@nvidia.com> Acked-by: NJoe Hershberger <joe.hershberger@ni.com>
-
由 Lukasz Majewski 提交于
Commit d4f5ef59cc7 "dfu: defer parsing of device string to IO backend" changed the function signature of dfu_init_env_entities(). Adjust cmd_thordown.c to match that change. Also, apply the same change as commit d6d37d737b58e "dfu: free entities when parsing fails" to cmd_thordown.c. Fixes: d4f5ef59cc7 ("dfu: defer parsing of device string to IO backend") Signed-off-by: NLukasz Majewski <l.majewski@samsung.com> Reviewed-by: NStephen Warren <swarren@nvidia.com>
-
由 Stephen Warren 提交于
Devices are not all identified by a single integer. To support this, defer the parsing of the device string to the IO backed, so that it can apply the appropriate rules. SPI devices are specified as controller:chip_select. SPI/SF support will be added soon. MMC devices can also be specified as controller[.hwpart][:partition] in many commands, although we don't support that syntax in DFU. Signed-off-by: NStephen Warren <swarren@nvidia.com>
-
由 Stephen Warren 提交于
These commands may be used to determine the size of a file without actually reading the whole file content into memory. This may be used to determine if the file will fit into the memory buffer that will contain it. In particular, the DFU code will use it for this purpose in the next commit. Signed-off-by: NStephen Warren <swarren@nvidia.com>
-
- 07 8月, 2014 1 次提交
-
-
由 Sonic Zhang 提交于
- init hardware watchdog if applicable - use CONFIG_SYS_MONITOR_LEN as the gd monitor len for Blackfin - reserve u-boot memory at the top field of the RAM for Blackfin - avoid refer to CONFIG_SYS_MONITOR_LEN, which is not defined by Blackfin Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
-
- 02 8月, 2014 1 次提交
-
-
由 Dmitry Lifshitz 提交于
Add callback with __weak annotation to allow setup of environment partition number in runtime from a board file. Propagate mmc_switch_part() return value into init_mmc_for_env() instead of -1 in case of failure. Signed-off-by: NDmitry Lifshitz <lifshitz@compulab.co.il> Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il> Acked-by: NPantelis Antoniou <panto@antoniou-consulting.com>
-
- 28 7月, 2014 1 次提交
-
-
由 Ma Haijun 提交于
Some architecture needs extra device tree setup. Instead of adding yet another hook, convert arch_fixup_memory_node to be a generic FDT fixup function. [maz: collapsed 3 patches into one, rewrote commit message] Signed-off-by: NMa Haijun <mahaijuns@gmail.com> Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com> Acked-by: NIan Campbell <ijc@hellion.org.uk>
-