By default several types of splash locations are supported and the
user can select one of them through environment var (splashsource).
However the devpart is still hardcoded and we cannot change it from
the environment.
This patch add the support of "splashdevpart" which allow the user to
set the devpart though this environment variable.
Example: image located in splashscreen partition (MMC as raw)
```
splashsource=mmc_raw
splashdevpart=0#splashscreen
```
Signed-off-by: Julien Masson <jmasson@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The user has now the choice to specify the splash location in the MMC
as a raw storage.
Signed-off-by: Julien Masson <jmasson@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Introduce CONFIG_SPL_MEMORY to allow Memory drivers to
be built for SPL.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
OMAP3 BeagleBoard NAND boot hangs when spl_load_legacy_img() tries
to read the header into 'struct hdr' which is allocated on the
stack.
As the header has already been read once before by spl_nand.c,
we can avoid the extra header allocation and read here by
simply passing around the pointer to the header.
This fixes NAND boot on OMAP3 BeagleBoard.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-By: Michael Trimarchi <michael@amarulasolutions.com>
- nuvoton: add expire function for generic reset (Jim)
- handle watchdogs during keyed autoboot (Rasmus)
- cyclic: Don't disable cylic function upon exceeding CPU time (Stefan)
- ulp wdog: Updates to support iMX93 and DM (Alice)
With the migration of the watchdog infrastructure to cyclic functions
it's been noticed, that at least one watchdog driver is broken now. As
the execution time of it's watchdog reset function is quite long.
In general it's not really necessary (right now) to disable the cyclic
function upon exceeding CPU time usage. So instead of disabling the
cylic function in this case, let's just print a warning once to show
this potential problem to the user.
Signed-off-by: Stefan Roese <sr@denx.de>
Suggested-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Cc: Tom Rini <trini@konsulko.com>
Cc: Pali Rohár <pali@kernel.org>
Boards can have multiple sysresets, iterate all when printing sysreset
info.
Fixes: 23471aed5c ("board_f: Add reset status printing")
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
There are no platforms that have not migrated to using DM_KEYBOARD,
remove the legacy option.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Beside some rather unexciting sync of the DTs from the kernel tree, and
some Kconfig cleanup, there are some improvements for the ARMv5 Allwinner
family, to support boards with the F1C200s (64MB DRAM) better. We will
get actual board support as soon as the DTs have passed the Linux review
process.
There is also support for the X96 Mate TV Box, featuring the H616 SoC and
a full 4GB of DRAM.
Also we found the secret to enable SPI booting on the H616 (pin PC5 must
be pulled to GND), so the SPI boot support patch is now good to go.
Passed the gitlab CI, plus briefly tested on Pine64-LTS, LicheePi Nano,
X96 Mate and OrangePi Zero.
Some configuration symbols formerly defined in header files were
recently converted to Kconfig symbols. This moved their value definition
into *every* defconfig file, even though those values are hardly board
choices.
Use the new Kconfig option to define per-SoC default values, in just one
place, which makes the definition in each defconfig file redundant.
We refrain from setting a sunxi specific value for CONFIG_SYS_BOOTM_LEN,
so this defaults to a much better 64MB for uncompressed arm64 kernels.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
There is a complaint in the code that iterates keyboards that we don't
have the _check variant of class iterator but we in fact do, use it.
In the code that iterates video devices there is an attempt to print
errors but the simple iterator does not return a device when there is an
error. Use the _check variant of the iterator as well.
Also format error messages consistently.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
common/spl/spl_atf.c:187:51: warning: value size does not match register
size specified by the constraint and modifier [-Wasm-operand-widths]
__asm__ __volatile__("msr DAIF, %0\n\t" : : "r" (daif) : "memory");
^
common/spl/spl_atf.c:187:34: note: use constraint modifier "w"
__asm__ __volatile__("msr DAIF, %0\n\t" : : "r" (daif) : "memory");
^~
%w0
Use %x0 to match what Linux does in <asm/sysreg.h> write_sysreg().
Signed-off-by: Alistair Delva <adelva@google.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Michael Walle <michael@walle.cc>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
The env_get() might be undefined in case ENV_SUPPORT is disabled,
which may happen e.g. in SPL. Add missing ifdef guard around the
env_get() to prevent build failure.
Signed-off-by: Marek Vasut <marex@denx.de>
Tested-by: Fabio Estevam <festevam@denx.de>
In order to move ppc-specific code out of setup_dest_addr(), provide an
arch-specific variant arch_setup_dest_addr(), that can be used by
architecture code to fix up the initial reloc address.
It is called at the end of setup_dest_addr() initcall and the default
implementation is a nop stub.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
asm/mach_type.h header and CONFIG_MACH_TYPE macro are arm-specific, so move
related bdinfo logic to arch_setup_bdinfo() in arch/arm/lib/bdinfo.c.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
The XTRN_DECLARE_GLOBAL_DATA_PTR declarations in ppc code are permanently
commented out, so there are no users for this macro:
#if 1
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r2")
#else /* We could use plain global data, but the resulting code is bigger */
#define XTRN_DECLARE_GLOBAL_DATA_PTR extern
#define DECLARE_GLOBAL_DATA_PTR XTRN_DECLARE_GLOBAL_DATA_PTR \
gd_t *gd
#endif
Remove all references to this macro, but add a documentation note regarding
the possibility of using plain global data for the GD pointer.
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
At present there is only one device tree used by the ofnode functions,
except for some esoteric use of live tree. In preparation for supporting
more than one, add a way to reset the list of device trees.
For now this does nothing.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is helpful to test that out-of-memory checks work correctly in code
that calls malloc().
Add a simple way to force failure after a given number of malloc() calls.
Fix a header guard to avoid a build error on sandbox_vpl.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
This is not needed and we should avoid typedefs. Use the struct instead
and rename it to indicate that it really is a legacy struct.
Signed-off-by: Simon Glass <sjg@chromium.org>
When the embedded device tree is pointed to by the __dtb_dt_*begin
symbols, it seems to be covered by the early relocation code and doesn't
need to be manually patched.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
Currently, AUTOBOOT_KEYED and its variant AUTOBOOT_ENCRYPTION are
broken when one has an external always-running watchdog device with a
timeout shorter than the configured boot delay (in my case, I have a
gpio-wdt one with a timeout of 1 second), because we fail to call
WATCHDOG_RESET() in the loops where we wait for the bootdelay to
elapse.
This is done implicitly in the !AUTOBOOT_KEYED case,
i.e. abortboot_single_key(), because that loop contains a
udelay(10000), and udelay() does a WATCHDOG_RESET().
To fix this, simply add similar udelay() calls in the other loops.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Stefan Roese <sr@denx.de>
Like in all other console functions, implement also serial_flush() function
as a fallback int console flush() function.
Flush support is available only when config option CONSOLE_FLUSH_SUPPORT is
enabled. So when it is disabled then provides just empty static inline
function serial_flush().
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
On certain places it is required to flush output print buffers to ensure
that text strings were sent to console or serial devices. For example when
printing message that U-Boot is going to boot kernel or when U-Boot is
going to change baudrate of terminal device.
Therefore introduce a new flush() and fflush() functions into console code.
These functions will call .flush callback of associated stdio_dev device.
As this function may increase U-Boot side, allow to compile U-Boot without
this function. For this purpose there is a new config CONSOLE_FLUSH_SUPPORT
which is enabled by default and can be disabled. It is a good idea to have
this option enabled for all boards which have enough space for it.
When option is disabled when U-Boot defines just empty static inline
function fflush() to avoid ifdefs in other code.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
32-bit U-Boot builds cannot use more than around 2 GB of DDR memory. But on
some platforms/boards it is possible to connect also 4 GB SODIMM DDR memory.
U-Boot currently prints only effective size of RAM which can use, which may
be misleading as somebody would expect that this line prints total size of
connected DDR modules. So change show_dram_config code to prints both real
and effective DRAM size if they are different. If they are same then print
just one number like before. It is possible that effective size is just few
bytes smaller than the real size, so print both numbers only in case
function print_size() prints formats them differently.
Signed-off-by: Pali Rohár <pali@kernel.org>
Members gd->ram_size and gd->ram_top are of type phys_addr_t which does not
have to fit into ulong type. So cast them into unsigned long long.
Fixes: 37dc958947 ("global_data.h: Change ram_top type to phys_addr_t")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit 37dc958947 ("global_data.h: Change ram_top type to phys_addr_t")
changed type of ram_top member from ulong to phys_addr_t but did not
changed types in board_get_usable_ram_top() function which returns value
for ram_top.
So change ulong to phys_addr_t type also in board_get_usable_ram_top()
signature and implementations.
Fixes: 37dc958947 ("global_data.h: Change ram_top type to phys_addr_t")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Ensure that top of RAM can be represented by phys_size_t type. If RAM is
too large or RAM base address is too upper then limit RAM size to prevent
address space overflow.
Signed-off-by: Pali Rohár <pali@kernel.org>
CONFIG_MAX_MEM_MAPPED when defined specifies upper memory mapped limit.
So check for it always, and not only when CONFIG_VERY_BIG_RAM is defined.
Signed-off-by: Pali Rohár <pali@kernel.org>
32-bit Marvell Armada BootROMs limit maximal size of SPL image to 192 kB.
So define 192 kB (= 0x30000) limit as default value for SPL_SIZE_LIMIT.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Globally replace all occurances of WATCHDOG_RESET() with schedule(),
which handles the HW_WATCHDOG functionality and the cyclic
infrastructure.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Tom Rini <trini@konsulko.com> [am335x_evm, mx6cuboxi, rpi_3,dra7xx_evm, pine64_plus, am65x_evm, j721e_evm]
This patch introduces a schedule() function, which shall be used instead
of the old WATCHDOG_RESET. Follow-up patches will make sure, that this
new function is used.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Tom Rini <trini@konsulko.com> [am335x_evm, mx6cuboxi, rpi_3,dra7xx_evm, pine64_plus, am65x_evm, j721e_evm]
We currently have an if_type (interface type) and a uclass id. These are
closely related and we don't need to have both.
Drop the if_type values and use the uclass ones instead.
Maintain the existing, subtle, one-way conversion between UCLASS_USB and
UCLASS_MASS_STORAGE for now, and add a comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
Selecting this option can be handled in the Kconfig option itself, as it
is with BLK. Update this an drop the various 'select' clauses.
Signed-off-by: Simon Glass <sjg@chromium.org>
This option is fact really related to SPL. For U-Boot proper we always use
driver model for block devices, so CONFIG_BLK is enabled if block devices
are in use.
It is only for SPL that we have two cases:
- SPL_BLK is enabled, in which case we use driver model and blk-uclass.c
- SPL_BLK is not enabled, in which case (if we need block devices) we must
use blk_legacy.c
Rename the symbol to SPL_LEGACY_BLOCK to make this clear. This is
different enough from BLK and SPL_BLK that there should be no confusion.
Signed-off-by: Simon Glass <sjg@chromium.org>
Normally, readline is not used int SPL. However, it may be useful to
enable the Freescale DDR interactive mode in SPL, while U-Boot is still
executing from SRAM. The default settings for readline result in a large
buffer being allocated. Reduce the size of the maximum input line, and
the number of lines of scrollback when building for SPL.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now when loadx and loady commands could be aborted / cancelled by CTRL+C,
allow to configure timeout for initial x/y-modem packet via env variable
$loadxy_timeout and by default use value from new compile-time config
option CONFIG_CMD_LOADXY_TIMEOUT. Value is in seconds and zero value means
infinite timeout. Default value is 90s which is the value used before this
change for loadx command.
Other load commands loadb and loads already waits infinitely. Same behavior
for loadx and loady commands can be achieved by setting $loadxy_timeout or
CONFIG_CMD_LOADXY_TIMEOUT to 0.
Signed-off-by: Pali Rohár <pali@kernel.org>
Allocate memory for buffers at a cache-line boundary to avoid
misaligned buffer address for subsequent reads. This avoids an
additional sector-based memory copy in the fat file system driver:
FAT: Misaligned buffer address (...)
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
This is required for architectures which do not support compressed kernel images (i.e. ARM64). This is only used while not booting via FIT image.
Signed-off-by: Nathan Barrett-Morrison <nathan.morrison@timesys.com>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
UEFI:
Implement a command eficonfig to maintain Load Options and boot order via
menus.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmMh/kQACgkQxIHbvCwF
GsSYVhAAlhyCiAQudBJtrOyAA0HDPMio/Fx9F3YV1Laay//6+xHhEh5H94fMr7jP
BHOrpE+IDKQTiQ8X3FpJpm3FzgQBzu0s4gQ+8fCKwkXCkaPTtWhs3s5SdHN0TWmv
qGlNbuPdoU+4i7PeBWw87EvOCzh4+snn+l3t+npMxUlZJInGy+6xj0irnSEXTvXV
lpDRw2UDq3/smAS8tAcR+zriTH5o1Lx+0qPIO9Hw8BSDHOcvZD+S9d6cd6j+M+Wz
rWk1Bshol6anIZWS5Gnx14ddKF8SQcSiPsDXg2Uj2DvFg7lWepKxAbDJD5CVF9R9
aEu6THCurc+769A/IHAS9M0EDNnWoUGFSxe0JuEHdYVuGj30RRfzSaciKkNxsxUZ
UGvDnQ+zdRoj6bTVi4Zf8SeZUTm/04lWMoIF05uhZFDiwxidbMowoNsk9FeKria/
4vXybfj/IhRwbiAhOUqyDjGuoLj8iVeOAyzin4FnDvBwdshIkSsB+4y1sX1aQv02
HQbP6WXkiYoYNkw5i9E9ZChioxkzMrn2za3GxWhkTBMJArDw6xSuHMdQsgwWWoqU
fCKjwe+D96lHq5cKt3DmGTvGxQtx9ckSJGK5r+US5y1udzotjOKc1jqMkMvS3Jyg
ureTj0wvLYSx+/UirVAZ4IDviDMBVEar79VS2xi+SYBMLeQPy3I=
=P89S
-----END PGP SIGNATURE-----
Merge tag 'efi-next-2022-09-14' of https://source.denx.de/u-boot/custodians/u-boot-efi into next
Pull request for efi next
UEFI:
Implement a command eficonfig to maintain Load Options and boot order via
menus.
This is preparation to support menu-driven UEFI BootOrder
variable updated by KEY_PLUS, KEY_MINUS and KEY_SPACE.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This patch adds a call to cyclic_init() to board_f/r.c, enabling the
common cyclic infrastructure. After this it's possible to add cyclic
functions via cyclic_register().
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add the basic infrastructure to periodically execute code, e.g. all
100ms. Examples for such functions might be LED blinking etc. The
functions that are hooked into this cyclic list should be small timewise
as otherwise the execution of the other code that relies on a high
frequent polling (e.g. UART rx char ready check) might be delayed too
much. This patch also adds the Kconfig option
CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time
for such a cyclic function. If it's execution time exceeds this time,
this cyclic function will get removed from the cyclic list.
How is this cyclic functionality executed?
The following patch integrates the main function responsible for
calling all registered cyclic functions cyclic_run() into the
common WATCHDOG_RESET macro. This guarantees that cyclic_run() is
executed very often, which is necessary for the cyclic functions to
get scheduled and executed at their configured periods.
This cyclic infrastructure will be used by a board specific function on
the NIC23 MIPS Octeon board, which needs to check periodically, if a
PCIe FLR has occurred.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
A recurring theme on LKML is the boot process deadlocking due to some
process blocking waiting for random numbers, while the kernel's
Cryptographic Random Number Generator (crng) is not initalized yet,
but that very blocking means no activity happens that would generate
the entropy necessary to finalize seeding the crng.
This is not a problem on boards that have a good hwrng (when the
kernel is configured to trust it), whether in the CPU or in a TPM or
elsewhere. However, that's far from all boards out there. Moreover,
there are consumers in the kernel that try to obtain random numbers
very early, before the kernel has had any chance to initialize any
hwrng or other peripherals.
Allow a board to provide a board_rng_seed() function, which is
responsible for providing a value to be put into the rng-seed property
under the /chosen node.
The board code is responsible for how to actually obtain those
bytes.
- One possibility is for the board to load a seed "file" from
somewhere (it need not be a file in a filesystem of course), and
then ensure that that the same seed file does not get used on
subsequent boots.
* One way to do that is to delete the file, or otherwise mark it as
invalid, then rely on userspace to create a new one, and living
with the possibility of not finding a seed file during some boots.
* Another is to use the scheme used by systemd-boot and create a new
seed file immediately, but in a way that the seed passed to the
kernel and the new (i.e. next) seed cannot be deduced from each
other, see the explanation at
https://lore.kernel.org/lkml/20190929090512.GB13049@gardel-login/
and the current code at
https://github.com/systemd/systemd/blob/main/src/boot/efi/random-seed.c
- The board may have an hwrng from which some bytes can be read; while
the kernel can also do that, doing it in U-Boot and providing a seed
ensures that even very early users in the kernel get good random
numbers.
- If the board has a sensor of some sort (temperature, humidity, GPS,
RTC, whatever), mixing in a reading of that doesn't hurt.
- etc. etc.
These can of course be combined.
The rng-seed property is mixed into the pool used by the linux
kernel's CRNG very early during boot. Whether it then actually
contributes towards the kernel considering the CRNG initialized
depends on whether the kernel has been configured with
CONFIG_RANDOM_TRUST_BOOTLOADER (nowadays overridable via the
random.trust_bootloader command line option). But that's for the BSP
developer to ultimately decide.
So, if the board needs to have all that logic, why not also just have
it do the actual population of /chosen/rng-seed in ft_board_setup(),
which is not that many extra lines of code?
I considered that, but decided handling this logically belongs in
fdt_chosen(). Also, apart from saving the board code from the few
lines of boilerplate, doing it in ft_board_setup() is too late for at
least some use cases. For example, I want to allow the board logic to
decide
ok, let's pass back this buffer and use that as seed, but also let's
set random.trust_bootloader=n so no entropy is credited.
This requires the rng-seed handling to happen before bootargs
handling. For example, during the very first boot, the board might not
have a proper seed file, but the board could still return (a hash of)
some CPU serial# or whatnot, so that at least no two boards ever get
the same seed - the kernel always mixes in the value passed in
rng-seed, but if it is not "trusted", the kernel would still go
through the same motions as it would if no rng-seed was passed before
considering its CRNG initialized. I.e., by returning that
unique-to-this-board value and setting random.trust_bootloader=n, the
board would be no worse off than if board_rng_seed() returned nothing
at all.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
This converts the following to Kconfig:
CONFIG_SYS_I2C_EEPROM_CCID
CONFIG_SYS_I2C_EEPROM_NXID
CONFIG_SYS_EEPROM_BUS_NUM
Signed-off-by: Tom Rini <trini@konsulko.com>
I do not have any non-serial output devices, so a
print_pre_console_buffer(PRE_CONSOLE_FLUSHPOINT2_EVERYTHING_BUT_SERIAL)
does nothing for me.
However, I was manually inspected the pre-console buffer using md.b,
and I noticed that the early part of it was repeated. The reason is
that the first call of print_pre_console_buffer(), from
console_init_f(), ends up invoking puts() with the contents of the
buffer at that point, and puts() at that point ends up in the else
branch of
if (gd->flags & GD_FLG_DEVINIT) {
/* Send to the standard output */
fputs(stdout, s);
} else {
/* Send directly to the handler */
pre_console_puts(s);
serial_puts(s);
}
so indeed the contents is added again.
That can be somewhat confusing (both when reading the buffer manually,
but also if it did actually come out on some device). So disable all
use of the pre-console buffer while print_pre_console_buffer() is
emitting it.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
bootstage_mark() and bootstate_error() are not recording any name and in
report it is showing as id=<value>. That's not useful and it is better to
show function name which calls it.
That's why use macros with passing __func__ as recorded name for bootstage.
Origin report looks like this:
ZynqMP> bootstage report
Timer summary in microseconds (10 records):
Mark Elapsed Stage
0 0 reset
2,482,383 2,482,383 board_init_f
4,278,821 1,796,438 board_init_r
4,825,331 546,510 id=64
4,858,409 33,078 id=65
4,862,382 3,973 main_loop
4,921,713 59,331 usb_start
9,345,345 4,423,632 id=175
When this patch is applied.
ZynqMP> bootstage report
Timer summary in microseconds (31 records):
Mark Elapsed Stage
0 0 reset
2,465,624 2,465,624 board_init_f
4,278,628 1,813,004 board_init_r
4,825,139 546,511 eth_common_init
4,858,228 33,089 eth_initialize
4,862,201 3,973 main_loop
4,921,530 59,329 usb_start
8,885,334 3,963,804 cli_loop
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
During early boot phase GD_FLG_ENV_READY is not set but env_get() may work
when env is ready in restricted mode. Do not fail with error message
"WARNING: Calling __hwconfig without a buffer and before environment is ready"
when env is already working by checking for ENV_VALID flag.
Signed-off-by: Pali Rohár <pali@kernel.org>
At present there is a confusing array of functions that handle the
device tree fix-ups needed for booting an OS. We should be able to switch
to using events to clean this up.
As a first step, create a new event type and call it from the standard
place.
Note that this event uses the ofnode interface only, since this can
support live tree which is more efficient when making lots of updates.
Signed-off-by: Simon Glass <sjg@chromium.org>
A large number of files include <flash.h> as it used to be how various
SPI flash related functions were found, or for other reasons entirely.
In order to migrate some further CONFIG symbols to Kconfig we need to
not include flash.h in cases where we don't have a NOR flash of some
sort enabled. Furthermore, in cases where we are in common code and it
doesn't make sense to try and further refactor the code itself in to new
files we need to guard this inclusion.
Signed-off-by: Tom Rini <trini@konsulko.com>
Since commit 2a73606668 ("serial: Rename SERIAL_SUPPORT to SERIAL")
SPL_SERIAL_SUPPORT is named SPL_SERIAL. So let's update the comment to
point to the correct Kconfig option in the comment of VPL_SERIAL.
Fixes: 747093dd40 ("vpl: Add Kconfig options for VPL")
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When attempting to load images from multiple MMC devices in sequence,
spl_mmc_load() chooses the wrong device from the second attempt onwards.
The reason is that MMC initialization is only done on its first call and
spl_mmc_load() will then continue using this same device for all future
calls.
Fix this by checking the devnum of the "cached" device struct against
the one which is requested. If they match, use the cached one but if
they do not match, initialize the new device.
This fixes specifying multiple MMC devices in the SPL's boot order to
fall back when U-Boot Proper is corrupted or missing on the first
attempted MMC device.
Fixes: e1eb6ada4e ("spl: Make image loader infrastructure more universal")
Signed-off-by: Harald Seiler <hws@denx.de>
start of test for fdt command
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAmLgRtERHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreYXFwgAlALOMj3bwwsIAXNa5j/hPb3j/ecIqXgn
ocyxN+U5eSb2Ju5Jc9QmSeUMnGrii9+PW9j0JApdHrbUgBI2Sx+zwqMTIfA+BS05
4xXZgk5jOT+we2489FjgFcplv+dIuVlsB/Zo6zTbZyjkobfilYsZEGYHJ/CYNaIH
n7EmZeby1cXL7DMCxT39d3hD43XSX8cqQ1IIiF9DgtHQYs2Ff8dFcbWArSdgLX3o
Eob2Qj/GjScg87zjZcsgZajWJMHUfMeD5ZiKN2fR0T/wOdO1WtzFoF2Mt8KZcW1j
BD1shgBCMSSl5EgRG1BQZw4Sa92W2IBlbJ9tfIh8qnWOzEBzOs/M6w==
=lsO4
-----END PGP SIGNATURE-----
Merge tag 'dm-pull-26jul22' of https://gitlab.denx.de/u-boot/custodians/u-boot-dm.git
minor dm- and fdt-related fixes
start of test for fdt command
The CONFIG_SPL_MAX_SIZE could be 0x27000 for i.MX8MM when SPL_TEXT_BASE
set to 0x7E1000.
The DDR firmware max uses 96KB, there is a 4KB padding header before
SPL_TEXT_BASE, so the SPL MAX SIZE is `256KB - 96KB - 4KB`.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Add a basic test of the 'fdt addr' command, to kick things off.
This includes a new convenience function to run a command from a printf()
string.
Signed-off-by: Simon Glass <sjg@chromium.org>
Convert taken FPGA image "compatible" string to a binary compatible
flag and pass it to an FPGA driver.
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
Tested-by: Ricardo Salveti <ricardo@foundries.io>
Tested-by: Adrian Fiergolski <adrian.fiergolski@fastree3d.com>
Link: https://lore.kernel.org/r/20220722141614.297383-9-oleksandr.suvorov@foundries.io
Signed-off-by: Michal Simek <michal.simek@amd.com>
These flags may be used to check whether an FPGA driver is able to
load a particular FPGA bitstream image.
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
Tested-by: Ricardo Salveti <ricardo@foundries.io>
Tested-by: Adrian Fiergolski <adrian.fiergolski@fastree3d.com>
Link: https://lore.kernel.org/r/20220722141614.297383-7-oleksandr.suvorov@foundries.io
Signed-off-by: Michal Simek <michal.simek@amd.com>
Do not use 0 as address for memory because of the special meaning for
pointers (null pointer). Change the spl bss start address to the second
page.
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Link: https://lore.kernel.org/r/20220714134733.7487-1-stefan.herbrechtsmeier-oss@weidmueller.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
The ISW_ENTRY_ADDR symbol was used for OMAP devices in place of
SPL_TEXT_BASE. Keystone2 HS devices were not using it right either.
Remove ISW_ENTRY_ADDR and use SPL_TEXT_BASE directly.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
SPL on mvebu loads proper U-Boot from custom Marvell kwbimage format and
therefore support for other binary formats is not required to be present in
SPL. Boot source of proper U-Boot is defined by compile time options and
therefore it is not required to enable all possible and unused peripherals
in SPL by default.
This change decrease size of SPL binaries.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Some consoles use CSI 200~ and CSI 201~ to bracket inserts. This leads
U-Boot to misinterpret the inserted string. Ignore these escape sequences.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
On probe, the SPI NOR core will put a flash in 8D mode if it
supports it. But Linux as of now expects to get the flash in
1S mode. Handing the flash to Linux in Octal DTR mode means
the kernel will fail to detect the flash.
This commit adds an option to soft reset the flash after
spl_spi_load_image() so that the flash can be reset to 1S mode
and subsequent spi-nor probe in Linux does not fail, since
spl_spi_load_image() performs spi_flash_probe() the remove is
added after completion loading images in spi_flash_probe() itself.
Tested on J721E EVM with 5.10 Linux kernel.
Linux spi-nor probe without the fix:
root@j7-evm:~# dmesg | grep spi-nor
[ 4.928023] spi-nor spi0.0: unrecognized JEDEC id bytes: ff ff ff ff ff ff
[ 4.934938] spi-nor: probe of spi0.0 failed with error -2
Linux spi-nor probe with the fix:
root@j7-evm:~# dmesg | grep spi-nor
[ 4.904484] spi-nor spi0.0: mt35xu512aba (65536 Kbytes)
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
board_usb_init() should receive the controller_index as its
first parameter instead of having it hardcoded as 0.
All in-tree users have CONFIG_SPL_SDP_USB_DEV as 0, so this error
should not affect any board.
Fix it by passing controller_index as the parameter of board_usb_init().
Signed-off-by: Fabio Estevam <festevam@denx.de>
Acked-by: Peng Fan <peng.fan@nxp.com>
Add support to load legacy image with payload compressed. This redirects
the boot flow for all legacy images. If the payload is not compressed, the
actual behavior will remain unchanged.
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
If the payload is compressed, SPL_COPY_PAYLOAD_ONLY should always be set
since the payload will not be directly read to its load address. The
payload will first be read to a temporary buffer, and then be decompressed
to its load address, without image header.
If the payload is not compressed, and SPL_COPY_PAYLOAD_ONLY is set, image
header should be skipped on loading. Otherwise image header should also be
read to its load address.
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
This patch removes the dependency to SPL_NAND_DRIVERS for SPL_NAND_BASE to
allow minimal spl nand driver to use nand base for probing NAND chips.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Introduce define for connection timeout, named HUB_DEBOUNCE_TIMEOUT
as in linux kernel drivers/usb/core/hub.c
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
For now the driver does not probe if usbkbd was not present in stdin.
This presents two issues, we can not probe the driver before setting stdin
and we can not use this driver in other manner than stdin console.
This patch fixes this by adding an else statement. It simply probes the
driver without console management in the case "usbkbd" is not in stdin.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
In case the MALLOC_F_ADDR is set to non-zero value, the early malloc area is
not going to be placed just below stack top, but elsewhere. Do not reserve
MALLOC_F bytes in this case, as that wastes stack space and may even cause
insufficient stack space in SPL.
This functionality is particularly useful on i.MX8M, where the insufficient
stack space can be triggered.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Thomas Chou <thomas@wytron.com.tw>
Cc: Tom Rini <trini@konsulko.com>
Tighten up symbol dependencies in a number of places. Ensure that a SPL
specific option has at least a direct dependency on SPL. In places
where it's clear that we depend on something more specific, use that
dependency instead. This means in a very small number of places we can
drop redundant dependencies.
Reported-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
The AST2600 bootrom has a max size of 64KB. This can be overridden if the
system is running the SPL from SPI NOR and not using secure boot.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Currently the SPI flash to load from is defined through the compile
time config CONFIG_SF_DEFAULT_BUS and CONFIG_SF_DEFAULT_CS, this
prevents the loading of binaries from different SPI flash using the
same build.E.g. supporting QSPI flash boot and OSPI flash boot
on J721E platform is not possible due to this limitation.
This commit adds lookup functions spl_spi_boot_bus()
and spl_spi_boot_cs for identifying the flash device based on the
selected boot device, when not overridden the lookup functions are
weakly defined in common/spl/spl_spi.c.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
