Currently when booting dhcp_run() may be executed multiple times:
once in eth_bootdev_hunt() and once in the network booting bootmeth.
We need to call eth_bootdev_hunt() when setting up the EFI sub-system to
supply the simple network protocol. We don't need an IP address set up.
We can reduce the bootime by not executing dhcp_run() in
eth_bootdev_hunt().
Furthermore eth_bootdev_hunt() with autostart=yes leads on the legacy
network stack leads to downloading a file via TFTP and to booting the
downloaded file.
Instead of running dchp_run() just check that there is a network device
in eth_bootdev_hunt().
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
(cherry picked from commit 1f68057e03)
The CI uses the following command to launch xilinx_versal_virt_defconfig:
qemu-system-aarch64 -M xlnx-versal-virt \
-display none -m 4G -serial mon:stdio \
-device loader,file=u-boot,cpu-num=0
'usb start' or invoking eth_bootdev_hunt leads to a crash when function
dwc3_core_init() tries to access a register at offset 0xc704 (DWC3_DCTL)
relative to the register start address 0xfe20c100.
Disable CONFIG_USB_DWC3 in the CI until the driver problem is fixed.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
(cherry picked from commit 37e0cf42cb)
We do not actually test the code.
Scanning for Amiga partitions of the sandbox is extremely slow,
especially on the partially implemented USB device.
For build testing the other sandbox defconfigs are good enough.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
(cherry picked from commit 9cb53b5ffd)
extension_bootdev_hunt may have already run.
Without reboot we cannot make any assumption here.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
(cherry picked from commit d01720a8305a1e12b61bb40ff76c3a8a0d52d2f6)
[Resolved conflict: used ubman instead of u_boot_console per ci/master rename]
We should not write messages in UEFI API functions. This may lead to
incorrect screen layout in UEFI application.
For single statements after if clause we don't need braces.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
(cherry picked from commit f99b549fc2)
On some RISC-V including QEMU $loadaddr is 0x80200000.
For bootelf to work choose a different LOAD_ADDR to which the demo ELF
binary is relocated.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
(cherry picked from commit 8e5b57eea0)
To build the API examples on RISC-V we need to
implement _start and syscall for RISC-V.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
(cherry picked from commit 9eb59201ab)
ARM, MIPS, and RISCV can use the same implementation of
platform_sys_info(). PPC provides some extra information.
So keep it separate.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
(cherry picked from commit 6f7f47e8c0)
[Resolved conflicts due to api/ -> legacy_api/ directory rename in ci/master]
Pull request doc-2025-01-rc6
Fix a number of typos
* cmd: bootmenu typo 'read'
* cmd/rng: fix long help text
* crypto: typo volatge
* board: freescale: typo volatge
* scripts: add volatge to spelling.txt
* doc: fit: Format image tree source example
(cherry picked from commit cb7410257a)
The example in kernel_fdt.rst is inconsistently indented, making it
difficult to read.
Indent the example with the same standard as the other examples:
Four spaces for the ReST code block and for every nesting level.
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
(cherry picked from commit 12876f8cd8)
The number of bytes may only be specified if a device number id provided.
Correct the formatting.
Acked-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
(cherry picked from commit 528b6b817e)
Signed-off-by: Tom Rini <trini@konsulko.com>
(cherry picked from commit 3391587e3f)
Note: Makefile version changes dropped (base is already at v2025.12).
In case an rswitch port is described as disabled in DT, do not
register it as ethernet device in U-Boot. This way, such ports
cannot be accessed from U-Boot command line.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 70da4f2859)
Move CONFIG_ENV_OVERWRITE=y into commont renesas_rcar.config to make sure
this configuration option is consistently enabled on all of Renesas R-Car
Gen2, Gen3, Gen4. Currently this option is not enabled on Gen4, this fix
corrects that omission.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 118a10e1dd)
The GRUB menu editing approach is fragile because:
1. GRUB can auto-boot before the test interacts with the menu
2. The command line content varies (e.g. '$vt_handoff' vs 'quiet splash')
3. Character-by-character navigation depends on exact screen layout
Simplify to just verify that EFI boot through GRUB reaches Linux
userspace, without trying to edit the kernel command line.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
These boards are no longer available in the lab, so drop them from the
CI configuration.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
When restarting U-Boot in lab mode, ensure_spawned() sets the timeout
to TIMEOUT_MS (30 seconds) before calling _wait_for_boot_prompt(). In
lab mode, _wait_for_banner() is skipped, so TIMEOUT_PREPARE_MS is never
restored.
This causes tests that boot into Linux and then restart U-Boot (like
test_distro_script) to fail with a timeout if the board takes more than
30 seconds to reset and boot.
Fix this by setting the timeout to TIMEOUT_PREPARE_MS (3 minutes) at
the start of _wait_for_boot_prompt() when in lab mode.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
The Firefly-RK3399 board does not boot reliably in the SJG lab due
to signal-integrity issues with SD-wire adapters at higher speeds.
Reduce the SDMMC max-frequency to 25MHz and disable high-speed modes
to improve compatibility.
Co-developed-by: Claude Opus 4.5 <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
TFTP transfers of large files, for example 128 MiB, can sporadically
get stuck and the transfer slows down considerably.
This happens because the TX DMA descriptor in DRAM becomes out of sync
with the view of the TX DMA descriptor content from the CPU side, which
is viewed through the CPU caches. In order to guarantee these two views
are consistent, the cache over TX DMA descriptor that has possibly been
written by the rswitch hardware must first be invalidated, only then can
the descriptor be cleared and updated by the CPU, and finally the cache
over that area must be flushed back into DRAM to make sure the rswitch
hardware has consistent view of the updated descriptor content.
The very first invalidation operation was missing, which led to sporadic
corruption of the TX DMA descriptor. Fix it, add the missing invalidation
operation.
Reported-by: Enric Balletbo i Serra <eballetb@redhat.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
(cherry picked from commit fa0f9e83a0)
TFTP transfer size can be used to re-size the TFTP progress bar on
single line based on the server reported file size. Enable it by
default for Renesas hardware to avoid long scrolling walls of '#'
character during long TFTP transfers.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 9899a6a750)
Early revisions of the R-Car V4M Series Hardware User’s Manual
contained an incorrect formula for the CPU core clocks:
ZCnφ = (PLL2VCO x 1/2) x mult/32
Dang-san fixed this by using CLK_PLL2_DIV2 instead of CLK_PLL2 as the
parent clock.
In Rev.0.70 of the documentation, the formula was corrected to:
ZCnφ = (PLL2VCO x 1/4) x mult/32
As the CPG Block Diagram now shows a separate 1/4 post-divider for PLL2,
the use of CLK_PLL2_DIV2 is a recurring source of confusion. Hence get
rid of CLK_PLL2_DIV2, and include the proper 1/4 post-divider in the
invocation of the DEF_GEN4_Z() macro, like is done on other R-Car Gen4
(and Gen3) SoCs.
Ported from Linux commit
92850bed9d4d ("clk: renesas: r8a779h0: Drop CLK_PLL2_DIV2 to clarify ZCn clocks")
Reported-by: Vinh Nguyen <vinh.nguyen.xz@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/0d2789cac2bf306145fe0bbf269c2da5942bb68f.1728377724.git.geert+renesas@glider.be
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
(cherry picked from commit 08806a6e52)
AMD/Xilinx changes for v2025.01-rc5 - second
- Fix find_ram_top() return to support configs > 4GB
(cherry picked from commit 5c8ef70f08)
[Fixup: Merge commit already present in branch]
One can use ccache by keeping ccache in PATH or by providing the full
path to ccache as well. Providing the full path to ccache fails as the
current regex tries to look for ccache being the initial token during
filtering.
Do a greedy search to remove anything before ccache for regex matching.
Fixes: 04b1d84221 ("Makefile: fix empty MK_ARCH when using ccache")
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
(cherry picked from commit c06705a9a1)
[Fixup: Commit already present in branch]
commit e27bddff4b ("imx8m: Restrict usable memory to space below 4G boundary")
tried to adjust the usable memory limits on a 4GB boundary.
ram_top is described as 'top address of RAM used by U-Boot' and we want
to preserve that. This is defined as a phys_addr_t and unfortunately
its size differs across architectures. This has lead us to a weird
state where 32bit boards define it 'SZ_4GB - 1' and 64bit boards as
'SZ_4GB' unless it was otherwise defined.
With some recent LMB changes and specifically
commit 1a48b0be93 ("lmb: prohibit allocations above ram_top even from same bank")
the board fails to boot properly although the commit above is correct
since it's making sure that no memory above ram_top is usable -- but
added to our memory map so EFI can hand it over to the booted OS.
The reason for that is that during the LMB init we add all usable memory
in lmb_add_memory(). In that function any memory above ram_top gets added
as 'reserved' for LMB. With the current values tha's set to 0xFFFF_FFFF
for this board. Later LMB is trying to protect the memory area U-Boot lives
in with lmb_reserve_common(). The latter fails though since it tries to
add U-Boot top (which is 0xFFFF_FFFF as well) to U-Boot 'bottom'. This call
will fail since 1 byte of that memory range is already marked as 'reserved'.
Since we are close to the release, LMB seems to assume that the address
is rounded up and is the 'next address' and so does parsing and adding
memory ranges from DT files, bump the ram_top of the board by 1byte.
In the long run we should change all of the above and have 32b and 64b
platforms define ram_top identically.
Add a Fixes tag although the commit is correct, so people can figure out
the broken scenarios in the future.
Suggested-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Fixes: commit 1a48b0be93 ("lmb: prohibit allocations above ram_top even from same bank")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reported-by: João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.com>
Closes: https://lore.kernel.org/all/20241216114231.qpfwug3zfqkxn3d5@joaog-nb.corp.toradex.com/
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Fixes: 74f88b7221 ("ARM: imx: imx8m: Fix board_get_usable_ram_top()")
(cherry picked from commit 0b7f4c7cf3)
[Fixup: Commit already present in branch]
("Enable EFI_LOADER_BOUNCE_BUFFER") is not the correct fix for the
problem it describes.
The change of memory addressing leading to side-effects in commit
22f2c9ed9f ("efi: memory: use the lmb API's for allocating and
freeing memory") is remedied by commit 1a48b0be93 ("lmb: prohibit
allocations above ram_top even from same bank").
This reverts commit 9c792ab336.
(cherry picked from commit ff1d5d87d0)
[Fixup: Commit already present in branch]
eth_get_dev() returns NULL if no network device is available.
Not checking the return value leads to a crash when the device
pointer is dereferenced.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
(cherry picked from commit d701c6ab42)
[Fixup: Commit already present in branch]
If the dns command cannot find a network interface, we should return
CMD_RETFAIURE and not -1 (CMD_RET_USAGE).
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
(cherry picked from commit b6691d0add)
[Fixup: Commit already present in branch]
There have been a few changes to the areas that this file documents
without having regenerated the file. Do so now.
Signed-off-by: Tom Rini <trini@konsulko.com>
(cherry picked from commit 9378307136)
[Fixup: Resolved conflict by keeping current version as changes were already present]
One can use ccache by keeping ccache in PATH or by providing the full
path to ccache as well. Providing the full path to ccache fails as the
current regex tries to look for ccache being the initial token during
filtering.
Do a greedy search to remove anything before ccache for regex matching.
Fixes: 04b1d84221 ("Makefile: fix empty MK_ARCH when using ccache")
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
(cherry picked from commit c06705a9a1)
commit e27bddff4b ("imx8m: Restrict usable memory to space below 4G boundary")
tried to adjust the usable memory limits on a 4GB boundary.
ram_top is described as 'top address of RAM used by U-Boot' and we want
to preserve that. This is defined as a phys_addr_t and unfortunately
its size differs across architectures. This has lead us to a weird
state where 32bit boards define it 'SZ_4GB - 1' and 64bit boards as
'SZ_4GB' unless it was otherwise defined.
With some recent LMB changes and specifically
commit 1a48b0be93 ("lmb: prohibit allocations above ram_top even from same bank")
the board fails to boot properly although the commit above is correct
since it's making sure that no memory above ram_top is usable -- but
added to our memory map so EFI can hand it over to the booted OS.
The reason for that is that during the LMB init we add all usable memory
in lmb_add_memory(). In that function any memory above ram_top gets added
as 'reserved' for LMB. With the current values tha's set to 0xFFFF_FFFF
for this board. Later LMB is trying to protect the memory area U-Boot lives
in with lmb_reserve_common(). The latter fails though since it tries to
add U-Boot top (which is 0xFFFF_FFFF as well) to U-Boot 'bottom'. This call
will fail since 1 byte of that memory range is already marked as 'reserved'.
Since we are close to the release, LMB seems to assume that the address
is rounded up and is the 'next address' and so does parsing and adding
memory ranges from DT files, bump the ram_top of the board by 1byte.
In the long run we should change all of the above and have 32b and 64b
platforms define ram_top identically.
Add a Fixes tag although the commit is correct, so people can figure out
the broken scenarios in the future.
Suggested-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Fixes: commit 1a48b0be93 ("lmb: prohibit allocations above ram_top even from same bank")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reported-by: João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.com>
Closes: https://lore.kernel.org/all/20241216114231.qpfwug3zfqkxn3d5@joaog-nb.corp.toradex.com/
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Fixes: 74f88b7221 ("ARM: imx: imx8m: Fix board_get_usable_ram_top()")
(cherry picked from commit 0b7f4c7cf3)
("Enable EFI_LOADER_BOUNCE_BUFFER") is not the correct fix for the
problem it describes.
The change of memory addressing leading to side-effects in commit
22f2c9ed9f ("efi: memory: use the lmb API's for allocating and
freeing memory") is remedied by commit 1a48b0be93 ("lmb: prohibit
allocations above ram_top even from same bank").
This reverts commit 9c792ab336.
(cherry picked from commit ff1d5d87d0)
eth_get_dev() returns NULL if no network device is available.
Not checking the return value leads to a crash when the device
pointer is dereferenced.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
(cherry picked from commit d701c6ab42)
