Add generic logic to determine the ram_top value for boards. Earlier,
this was achieved in an indirect manner through a set of LMB API's.
That has since changed so that the LMB code is available only after
relocation. Replace those LMB calls with a single call to
get_mem_top() to determine the value of ram_top.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20241025172724.195093-2-sughosh.ganu@linaro.org
Signed-off-by: Michal Simek <michal.simek@amd.com>
Falltroughs in switch statements should be explicit.
Addresses-Coverity-ID: 131162 Missing break in switch
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This patch adds a new callback named need_reprint for menu.
The need_reprint will be called before printing the menu. If the
callback exists and returns FALSE, menu printing will be canceled.
This is very useful if the menu was not changed. It can save time
for serial-based menu to handle more input data.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
Tested-by: Daniel Golle <daniel@makrotopia.org>
It's observed that the bootmenu on a serial console sometimes
incorrectly quitted with superfluous characters filled to command
line input:
> *** U-Boot Boot Menu ***
>
> 1. Startup system (Default)
> 2. Upgrade firmware
> 3. Upgrade ATF BL2
> 4. Upgrade ATF FIP
> 5. Load image
> 0. U-Boot console
>
>
> Press UP/DOWN to move, ENTER to select, ESC to quit
>MT7988> [B
Analysis shows it was caused by the wrong logic of bootmenu_loop:
At first the bootmenu_loop received the first ESC char correctly.
However, during the second call to bootmenu_loop, there's no data
in the UART Rx FIFO. Due to the low baudrate, the second char of
the down array key sequence hasn't be fully received.
But bootmenu_loop just did a mdelay(10), and then treated it as a
single ESC key press event. It didn't even try tstc() again after
the 10ms timeout.
This patch fixes this issue by letting bootmenu_loop check tstc()
twice.
Tested-By: E Shattow <lucent@gmail.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
Tested-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The timer counter on Rockchip SoCs may be reset in TF-A, this may cause
the bootstage records to be printed out of order and with an incorrect
elapsed time.
Fix this by not sorting the bootstage records.
Before on a Radxa ZERO 3W (RK3566) board:
=> bootstage report
Timer summary in microseconds (12 records):
Mark Elapsed Stage
0 0 reset
7,436 7,436 board_init_f
164,826 157,390 SPL
375,392 210,566 end phase
423,909 48,517 board_init_r
472,973 49,064 eth_common_init
476,848 3,875 main_loop
477,003 155 cli_loop
Accumulated time:
7,181 of_live
14,739 dm_spl
15,029 dm_r
315,150 dm_f
With this the records can be printed in chronological order when the
counter is reset and SPL and board_init_r records show correct elapsed
time.
=> bootstage report
Timer summary in microseconds (12 records):
Mark Elapsed Stage
0 0 reset
164,437 164,437 SPL
375,023 210,586 end phase
7,437 7,437 board_init_f
424,390 416,953 board_init_r
473,515 49,125 eth_common_init
477,402 3,887 main_loop
477,571 169 cli_loop
Accumulated time:
14,734 dm_spl
315,646 dm_f
7,339 of_live
14,977 dm_r
For the tested board external TPL and BROM take ~164 ms to initialize
DRAM and load SPL, SPL take ~210ms to load images from FIT and U-Boot
proper take ~477ms to reach cli prompt.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
efi_loader.h is included twice. Remove one and move the other in
alphabetical order
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Patrick Rudolph <patrick.rudolph@9elements.com> says:
Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.
The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.
The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.
The changes were tested on real hardware as well on QEMU v9.0:
qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
-pflash secure-world.rom \
-pflash unsecure-world.rom
qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
-smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
-dtb bcm2711-rpi-4-b.dtb -nographic
Tested against FWTS V24.03.00.
Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
Linux kernel module doesn't support ACPI yet.
Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com
Initialize addr to zero which allows to build on the CI
which is more strict.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Allow to use BLOBLIST_TABLES on arm to store ACPI or other tables.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Increase rng-seed size to make Linux happy and initialize rng pool instantly.
Linux 5.19+ requires 32 bytes of entropy to initialize random pool, but u-boot
currently provides only 8 bytes.
Linux 5.18 and probably some versions before it used to require 64 bytes.
Bump min value to 64 bytes to be on a safe side.
Boot with 8 byte rng-seed (Linux 6.11):
# dmesg | grep crng
[ 12.089286] random: crng init done
Boot with 32 byte rng-seed (Linux 6.11):
# dmesg | grep crng
[ 0.000000] random: crng init done
Linux source references:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?h=v5.19#n551https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?h=v5.18#n236
Signed-off-by: Alex Shumsky <alexthreed@gmail.com>
Fixes: d2048bafae ("rockchip: board: Add board_rng_seed() for all Rockchip devices")
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/22989
- Remove unneeded USB board code and fix reset on mx6ul_14x14_evk.
- Update fastboot buffer size/address for verdin-imx8m{m|p}.
- Fix imxrt1050-evk boot and convert it to standard boot.
- Fix imx8qxp-mek and imx8qm-mek boot.
- Add support for the i.MX93 9X9 QSB board.
- Make livetree API to work on i.MX.
- Set sane default value for i.MX8M SPL_LOAD_FIT_ADDRESS.
- Deduplicate DH i.MX8MP/i.MX6 DHSOM defconfigs.
- Select default TEXT_BASE for i.MX6/i.MX7.
- Several updates for DH i.MX8MP DRC02.
Move i.MX7 TEXT_BASE/SPL_TEXT_BASE to Kconfig and common/spl/Kconfig
which is the best practice.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Select default U-Boot and SPL text base for the i.MX6 SoC. The U-Boot
and SPL text base is picked as the one used by various i.MX6 boards.
Update all the boards.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The bootstage array includes pointers to strings but not the strings
themselves. The strings are added when stashing, but including them in
the size calculation gives an inflated view of the amount of space used
by the array.
Update this function so it can return the amount of memory used by the
bootstage structures themselves, without the strings which they point
to.
Signed-off-by: Simon Glass <sjg@chromium.org>
The call to malloc() is a bit strange. The naming of the arguments
suggests that an address is passed, but in fact it is a pointer, at
least in the board_init_r() function and SPL equivalent.
Update it to work as described. Add a function comment as well.
Note that this does adjustment does not extend into the malloc()
implementation itself, apart from changing mem_malloc_init(), since
there are lots of casts and pointers and integers are used
interchangeably.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The only caller left is schedule(); everybody outside cyclic.c now
calls or references schedule().
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
I noticed an "unnecessary" include of <cyclic.h> in
global_data.h, in the sense that nothing in cyclic.h is needed in
order to define 'struct global_data'.
Well, it's not unnecessary, as it implicitly ensures that everybody
gets a declaration of schedule(), and schedule() is (obviously) called
all over the tree. Almost none of those places directly include
<cyclic.h>, but for historical reasons, many do include
<watchdog.h> (most schedule() instances are replacements of
WATCHDOG_RESET()).
However, very few TUs actually need the declarations of the
cyclic_register() and struct cyclic_info, and they also don't really
need anything from the watchdog.h header.
So introduce a new header which just contains a declaration of
schedule(), which can then be included from all the places that do
call schedule(). I removed the direct reference to cyclic_run(),
because we shouldn't have two public functions for doing roughly the
same without being very explicit about when one should call one or the
other.
Testing of later patches that explicitly include <schedule.h> when
schedule() is used revealed a problem with host tool build on win32,
which apparently picked up a host <schedule.h>. To avoid that problem,
put the new header in include/u-boot/ and hence make the include
statements say <u-boot/schedule.h>.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Add what it takes to enable NETDEVICES with NET_LWIP and enable DHCP as
well as the dhcp command. CMD_TFTPBOOT is selected by BOOTMETH_EFI due
to this code having an implicit dependency on do_tftpb().
Note that PXE is likely non-fonctional with NET_LWIP (or at least not
100% functional) because DHCP option 209 is not supported by the lwIP
library. Therefore, BOOTP_PXE_DHCP_OPTION cannot be enabled.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Prepare the introduction of the lwIP (lightweight IP) TCP/IP stack by
adding a new net/lwip/ directory and the NET_LWIP symbol. Network
support is either NO_NET, NET (legacy stack) or NET_LWIP. Subsequent
commits will introduce the lwIP code, re-work the NETDEVICE integration
and port some of the NET commands and features to lwIP.
SPL_NET cannot be enabled when NET_LWIP=y. SPL_NET pulls some symbols
that are part of NET (such as arp_init(), arp_timeout_check(),
arp_receive(), net_arp_wait_packet_ip()). lwIP support in SPL may be
added later.
Similarly, DFU_TFTP and FASTBOOT are not compatible with NET_LWIP
because of dependencies on net_loop(), tftp_timeout_ms,
tftp_timeout_count_max and other NET things. Let's add a dependency on
!NET_LWIP for now.
SANDBOX can select NET_LWIP but doing so will currently disable the eth
dm tests as well as the wget tests which have strong dependencies on the
NET code.
Other adjustments to Kconfig files are made to fix "unmet direct
dependencies detected" for USB_FUNCTION_SDP and CMD_FASTBOOT when
the default networking stack is set to NET_LWIP ("default NET_LWIP"
instead of "default NET" in Kconfig).
The networking stack is now a choice between NO_NET,
NET and NET_LWIP. Therefore '# CONFIG_NET is not set' should be
'CONFIG_NO_NET=y'. Adjust the defconfigs accordingly.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Simon Glass <sjg@chromium.org> says:
When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL
Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.
For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:
#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.
This series starts a change in terminology and usage to resolve the
above issues:
- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_
It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.
This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.
The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
Use PHASE_ as the symbol to select a particular XPL build. This means
that SPL_TPL_ is no-longer set.
Update the comment in bootstage to refer to this symbol, instead of
SPL_
Signed-off-by: Simon Glass <sjg@chromium.org>
Complete this rename for all directories outside arch/ board/ drivers/
and include/
Use the new symbol to refer to any 'SPL' build, including TPL and VPL
Signed-off-by: Simon Glass <sjg@chromium.org>
AVB_BUF_ADDR, which is under "if AVB_VERIFY", defaults to
FASTBOOT_BUF_ADDR. Therefore AVB_VERIFY should depend on FASTBOOT.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Tom Rini <trini@konsulko.com> # Raspberry Pi 3 (32b, 64b,
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20241002144845.1439316-1-jerome.forissier@linaro.org
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Christian Marangi <ansuelsmth@gmail.com> says:
This series is a reworked version of the previous seried:
misc: introduce STATUS LED activity function
This series port and expand the legacy concept of LED boot from
the legacy Status LED API to new LED API.
One thing that many device need is a way to communicate to the
user that the device is actually doing something.
This is especially useful for recovery steps where an
user (for example) insert an USB drive, keep a button pressed
and the device autorecover.
There is currently no way to signal the user externally that
the bootloader is processing/recoverying aside from setting
a LED on.
A solid LED on is not enough and won't actually signal any
kind of progress.
Solution is the good old blinking LED but uboot doesn't
suggest (and support) interrupts and almost all the LED
are usually GPIO LED that doesn't support HW blink.
Additional Kconfg are also introduced to set the LED boot and
activity. Those are referenced by label.
A documentation for old and these new LED API is created.
Rework BOOT LED handling. There is currently one legacy implementation
for BOOT LED from Status Led API.
This work on ancient implementation used by BOOTP by setting the LED
to Blink on boot and to turn it OFF when the firmware was correctly
received by network.
Now that we new LED implementation have support for LED boot, rework
this by also set the new BOOT LED to blink and also set it to ON before
entering main loop to confirm successful boot.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When MMC booting fails it is sometimes hard to figure out what went
wrong as there is no error code. It isn't even clear which MMC device
was chosen, since SPL can have its own numbering.
Add some debugging to help with this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Oliver Gaskell <Oliver.Gaskell@analog.com> says:
ADSP-SC5xx is a series of ARM-based DSPs.
This comprises the armv7 based SC57x, SC58x and SC594 series, and the
armv8 based SC598.
This patch series includes configurations, init code, and minimal DTs
to enable Analog Devices' evaluation boards for these SoCs to boot
through SPL and into U-Boot Proper, as well as devicetree schemas for
the added DTs.
This patch series depends on ("arm: Add Analog Devices SC5xx Machine
Type") (https://lists.denx.de/pipermail/u-boot/2024-April/552043.html)
Adds support for Analog Devices' SC594-SOM-EZLITE board. Includes:
- Board specific configs in mach-sc5xx/Kconfig
- Board-specific Kconfig and environment in board/adi/
Signed-off-by: Oliver Gaskell <Oliver.Gaskell@analog.com>
The primary upstream URL for tf-a has moved, in some cases
things like tags are not always pushed to the old URL so
update the URLs to the primary upstream project URL.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Jerome Forissier <jerome.forissier@linaro.org> says:
Miscellaneous fixes made when developing the lwIP series [1]. They are
posted separately since they make sense on their own. Subsequent
versions of the lwIP series will contain a squashed version of this one.
[1] http://patchwork.ozlabs.org/project/uboot/list/?series=420712&state=%2A&archive=both
common/update.c (UPDATE_COMMON) depends on tftp_timeout_ms which is
defined in cmd/tftp.c (CMD_TFTPBOOT). Therefore add the appropriate
imply statement to Kconfig.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Prefix the flash status codes (ERR_*) with FL_ in order to avoid clashes
with third-party libraries. Case in point: including the lwIP library
header file <lwip/err.h> which defines err_enum_t as an enum with values
being ERR_*.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
