| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Francois Bedard <fbedard@synopsys.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Heiko Schocher <hs@denx.de>
|
|
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
|
|
|
|
People who write (or scripts that auto-generate) extlinux.conf don't
want to know about HW-specific information such as FDT filenames. Create
a new extlinux.conf tag "fdtdir" that specifies only the directory where
FDT files are located, and defer all knowledge of the filename to U-Boot.
The algorithm implemented is:
==========
if $fdt_addr_r is set:
if "fdt" tag was specified in extlinux.conf:
load the FDT from the filename in the tag
else if "fdtdir" tag was specified in extlinux.conf:
if "fdtfile" is set in the environment:
load the FDT from filename in "$fdtfile"
else:
load the FDT from some automatically generated filename
if no FDT file was loaded, and $fdtaddr is set:
# This indicates an FDT packaged with firmware
use the FDT at $fdtaddr
==========
A small part of an example /boot/extlinux.conf might be:
==========
LABEL primary
LINUX zImage
FDTDIR ./
LABEL failsafe
LINUX bkp/zImage
FDTDIR bkp/
==========
... with /boot/tegra20-seaboard.dtb or /boot/bkp/tegra20-seaboard.dtb
being loaded by the sysboot/pxe code.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
|
|
The specification for extlinux.conf[1] states that "fdt" is an alias for
"devicetree". To date, U-Boot only implements "fdt". Rectify that.
[1] http://freedesktop.org/wiki/Specifications/BootLoaderSpec/
Signed-off-by: Stephen Warren <swarren@nvidia.com>
|
|
Command provides just dump subcommand for showing clock
frequencies in a soc.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Stefano Babic <sbabic@denx.de>
|
|
This is only required for "PIC" relocation and doesn't apply to modern
"PIE" relocation which does data relocation as well as code.
"init_sequence_r" is just an array that consists of compile-time
adresses of init functions. Since this is basically an array of integers
(pointers to "void" to be more precise) it won't be modified during
relocation - it will be just copied to new location as it is.
As a consequence on execution after relocation "initcall_run_list" will
be jumping to pre-relocation addresses. As long as we don't overwrite
pre-relocation memory area init calls are executed correctly. But still
it is dangerous because after relocation we don't expect initially used
memory to stay untouched.
Cc: Tom Rini <trini@ti.com>
Cc: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Thomas Langer <thomas.langer@lantiq.com>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
|
Add SPL support to be able to detect a USB Mass Storage device
connected to a USB host. Once a USB Mass storage device is detected
the SPL will load the u-boot.img from a FAT partition to target address.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
|
|
Move the FAT functions to a common location for reuse.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
|
|
The change to add 64bit initrd support broke 32bit initrd support as it
always set 64bits worth of data into the properties, even on 32bit
systems. The fix is to use addr_cell_len (which already says how much
data is in 'tmp') to set the property, rather than always setting 8.
Thanks to Stephen Warren for pointing out the fix here.
Reported-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Tom Rini <trini@ti.com>
|
|
|
|
when creating the hashtable, for each environmentvariable
getenv(ENV_CALLBACK_VAR) and getenv(ENV_FLAGS_VAR) is called,
which costs at this point a lot of time. So call this two
getenv() calls only once.
Boottime on the ids8313 board without this patch:
2013-12-19 13:38:22,894: NAND: 128 MiB
2013-12-19 13:38:27,659: In: serial
(~4.8 sec)
Bootime with this patch on the ids8313 board:
2013-12-19 13:40:25,332: NAND: 128 MiB
2013-12-19 13:40:25,546: In: serial
(~0.2 sec)
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Wolfgang Denk <wd@denx.de>
|
|
For standalone images, bootm had a special case where the OS boot function
was NULL but did actually exist. It was just called manually.
This was removed by commit 35fc84fa which checks for the non-existence of
this function before the special case is examined.
There is no obvious reason why standalone is handled with a special case.
Adjust the code so that standalone has a normal OS boot function. We still
need a special case for when the function returns, but at least we can
avoid the main problem.
This is intended to fix the reported:
ERROR: booting os 'U-Boot' (17) is not supported
but needs testing.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Otherwise, when booting VxWorks kernel, the incorrect message will
be seen:
ARM Unknown OS Kernel Image (uncompressed)
Signed-off-by: Miao Yan <miao.yan@windriver.com>
|
|
Compiling of full list of commands does not advance the counter,
so it always results in an empty list.
This seems to be (inadvertently?) introduced by commit
6c7c946cadfafdea80eb930e3181085b907a0362.
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
|
|
|
|
Before this change ums mode can not be entered when device
was using the same usb port for usb/uart communication.
Switching USB cable from UART to USB always causes ums exit.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
|
|
"env_eeprom_bus" is no longer in use (it was introduced in commit
548738b4d43af841ff58c787bce297ac6a8bf7d1 "cmd_eeprom: I2C updates").
As in "eeprom_bus_write" we just reset I2C bus with the one we saved in
"old_bus".
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Heiko Schocher <hs@denx.de>
|
|
Add map_sysmem() calls so that this test works correctly on sandbox.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Hung-ying Tyan <tyanh@chromium.org>
Reviewed-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
|
|
Bringing in the MMC tree means that CONFIG_BOUNCE_BUFFER needed to be
added to include/configs/exynos5-dt.h now.
Conflicts:
include/configs/exynos5250-dt.h
Signed-off-by: Tom Rini <trini@ti.com>
|
|
|
|
Signed-off-by: David Feng <fenghua@phytium.com.cn>
|
|
Relocation code based on a patch by Scott Wood, which is:
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: David Feng <fenghua@phytium.com.cn>
|
|
Signed-off-by: David Feng <fenghua@phytium.com.cn>
|
|
Signed-off-by: David Feng <fenghua@phytium.com.cn>
|
|
The eMMC and the SD-Card specifications describe the optional SET_DSR command.
During measurements at our lab we found that some cards implementing this feature
having really strong driver strengts per default. This can lead to voltage peaks
above the specification of the host on signal edges for data sent from a card to
the host.
Since availability of a given card type may be shorter than the time a certain
hardware will be produced it is useful to have support for this command (Alternative
would be changing termination resistors and adapting the driver strength of the
host to the used card.)
Following proposal for an implementation:
- new field that reflects CSD field DSR_IMP in struct mmc
- new field for design specific DSR value in struct mmc
- board code can set DSR value in mmc struct just after registering an controller
- mmc_startup sends the the stored DSR value before selecting a card, if DSR_IMP is set
Additionally the mmc command is extended to make is possible to play around with different
DSR values.
The concept was tested on a i.MX53 based platform using a Micron eMMC card where the default
DSR is 0x0400 (12mA) but in our design 0x0100 (0x0100) were enough. To use this feature for
instance on a mx53loco one have to add a call to mmc_set_dsr() in board_mmc_init() after
calling fsl_esdhc_initialize() for the eMMC.
Signed-off-by: Markus Niebel <Markus.Niebel@tqs.de>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
|
|
It is useful to be able to save and restore the RAM contents of sandbox
U-Boot either for setting up tests, for later analysys, or for chaining
together multiple tests which need to keep the same memory contents.
Add a function to provide a memory file for U-Boot. This is read on
start-up and written when shutting down. If the file does not exist
on start-up, it will be created when shutting down.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
With sandbox, errors and problems may be reported before console_init_f()
is executed. For example, an argument may not parse correctly or U-Boot may
panic(). At present this output is swallowed so there is no indication what
is going wrong.
Adjust the console to deal with a very early sandbox setup, by detecting that
there is no global_data yet, and calling os functions in that case.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The execution flow becomes easier if we can return from board_init_f()
as ARM does. We can control things from start.c instead of having to
call back into that file from other places.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Provide a way to use any host file or device as a block device in U-Boot.
This can be used to provide filesystem access within U-Boot to an ext2
image file on the host, for example.
The support is plumbed into the filesystem and partition interfaces.
We don't want to print a message in the driver every time we find a missing
device. Pass the information back to the caller where a message can be printed
if desired.
Signed-off-by: Henrik Nordström <henrik@henriknordstrom.net>
Signed-off-by: Simon Glass <sjg@chromium.org>
- Removed change to part.c get_device_and_partition()
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
fdt_fixup_memory_banks() will add and update /memory node in
device tree blob. In the case that /memory node doesn't exist,
after adding a new one, this function returns error.
The correct behavior should be continuing to update its properties.
Signed-off-by: Miao Yan <miao.yan@windriver.com>
|
|
interface.
The next version VxWorks adopts device tree (for PowerPC and ARM) as its hardware
description mechanism. For PowerPC, the boot interface conforms to
the ePAPR standard, which is:
void (*kernel_entry)(ulong fdt_addr,
ulong r4 /* 0 */,
ulong r5 /* 0 */,
ulong r6 /* EPAPR_MAGIC */, ulong r7 /* IMA size */,
ulong r8 /* 0 */, ulong r9 /* 0 */)
For ARM, the boot interface is:
void (*kernel_entry)(void *fdt_addr)
Signed-off-by: Miao Yan <miao.yan@windriver.com>
[trini: Fix build error when !CONFIG_OF_FDT is set, typo on PowerPC,
missing extern ft_fixup_num_cores]
Signed-off-by: Tom Rini <trini@ti.com>
|
|
do_bootm_vxworks now is available under the configuration option
CONFIG_BOOTM_VXWORKS, thus aligned with other operating systems
that supported by bootm command. The bootvx command still depneds
on CONFIG_CMD_ELF.
Signed-off-by: Miao Yan <miao.yan@windriver.com>
|
|
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
|
|
If U-Boot build with DEBUG enabled/defined the first call of "debug"
function (that dumps data to any available console) will happen before
zeroing of initial "gd" in init call "zero_global_data" in
"init_sequence_f".
And if stack was not filled with zeros chances are high that
"gd->have_console" won't be 0. In its turn it will cause attempt to
output things to non-initialized yet serial console.
So for safety and predictability we set "gd->have_console = 0".
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Mischa Jonker <mjonker@synopsys.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
argv[0] contains bootvx (command name) not the load address, if called with
argv < 2 use load_addr, else use address argument given to the command.
Signed-off-by: Stany MARCEL <smarcel@novasys-ingenierie.com>
|
|
The documentation suggested the arguments where passed over r3-r6
while the code below simply does that over r0-r3.
Cc: Kumar Gala <galak@kernel.crashing.org>
|
|
The local pointer of address (i.e., addr) only gets
referenced under SPI mode, and it won't be appropriate
to pass only 1-byte addr[1] to i2c_read/i2c_write while
CONFIG_SYS_I2C_EEPROM_ADDR_LEN > 1.
1. In U-boot's I2C model, the address would be re-assembled
to a byte string in MSB order inside I2C controller drivers.
2. The 'CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW' option which could
be found at soft_i2c.c is always turned on in cmd_eeprom.c,
the addr[0] always contains the device address with overflowed
MSB address bits.
Signed-off-by: Kuo-Jung Su <dantesu@faraday-tech.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
cc: Peter Tyser <ptyser@xes-inc.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Stefan Roese <sr@denx.de>
Cc: Mischa Jonker <mjonker@synopsys.com>
|
|
|
|
The directory tools/ is always built before common/.
So when envcrc tool is necessary in common/Makefile,
it already exists.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
|
|
In the case of not having CONFIG_CMD_HASH but having CONFIG_CMD_CRC32
enabled (and not CONFIG_CRC32_VERIFY), we end up in this part of the
code path on hash_command(). However, we will only have exactly 3 args
here, and 3 > 3 is false, and we will not try and store the hash at the
address given as arg #3. The next problem however is that we've been
moving argv around so the third value is now in argv[0] not argv[3].
Confirmed on AM335x Beaglebone White.
Signed-off-by: Tom Rini <trini@ti.com>
|
|
Some phys (Micrel) have additional registers that can
be accessed using a special sequence. This patch allows
to use standard "mdio" command to accesss these registers.
Signed-off-by: Stefano Babic <sbabic@denx.de>
|
|
Signed-off-by: Stephan Bauroth <stephan.bauroth@iav.de>
Patch: 265707
|
|
Data "offset" is not used directly in case of I2C EEPROM. Istead it is
split into "block number" and "offset within mentioned block". Which are
"addr[0]" and "addr[1]" respectively.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
cc: Peter Tyser <ptyser@xes-inc.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Stefan Roese <sr@denx.de>
Cc: Mischa Jonker <mjonker@synopsys.com>
|
|
Remove the redundant lcd_line_length initialisation which
sneaked in when an earlier version of the patch of commit
6d330719 has been rebased.
Some lcd drivers need to setup lcd_line_length not from the
panel_info parameters but by different means. Make the
lcd_get_size() weak to allow setting lcd_line_length in
a driver specific way.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Stephen Warren <swarren@wwwdotorg.org>
|
|
|
|
The env export command doesn't export the first variable of the list
since commit 5a31ea04c9ee5544fbb70ad7597ea4b294840eab
"env grep" - reimplement command using hexport_r()
Signed-off-by: Pierre Aubert <p.aubert@staubli.com>
|
|
As originally implemented, setting the AUTOBOOT_KEYED config option will
prevent users from breaking into the autoboot script with ctrl-c. Restore
that option with a new config symbol.
Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
|
|
Signed-off-by: Luka Perkov <luka@openwrt.org>
|
|
Signed-off-by: Luka Perkov <luka@openwrt.org>
|
