jcs.org
commits
spl_perform_fixups is redundant in the current implementation. SPLs call
dram_init during spl_enable_cache in arch/arm/mach-k3/common.c. In
U-Boot, dram_init and dram_init_banksize are automatically called in
init_sequence_f. Therefore, SPLs and U-Boot always determine the correct
RAM size. During Linux boot, fdt_fixup_memory_banks adjusts the RAM size
in the Linux device tree, ensuring correct RAM usage.
dram_init() calls get_ram_size() for the Verdin AM62, which determines
the correct RAM size through read/write operations. However, due to the
K3 bootflow placing ATF in RAM and requiring cache coherence, calling
get_ram_size() with caches enabled prevents ATF boot. Removing this call
restores ATF boot functionality.
This fixes a regression introduced in commit 4164289db882 ("board:
verdin-am62: fix missing memory fixup call") which prevents some of our
Verdin AM62 modules from booting.
Fixes: 4164289db882 ("board: verdin-am62: fix missing memory fixup call")
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
The defines for the different build phases shouldn't be used in device
trees, currently they aren't even defined for device tree pre processing,
resulting in build errors.
Link: https://lists.denx.de/pipermail/u-boot/2025-March/582787.html
Signed-off-by: Hendrik Donner <hd@os-cillation.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
The header of the StarFive U-Boot SPL file u-boot-spl.normal.out has a
field indicating the payload size. When copying U-Boot SPL from a
partition the copied file might be too long.
Currently in this situation a misleading error message 'Incorrect CRC32' is
written.
We must use the payload size and not the file size when calculating the
CRC32.
Write a warning if the file is too long indicating the correct size. This
enables the user to truncate the file accordingly.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This gives an error with newer Python version, so fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
%s/even spies/event spies/
%s/EFL/ELF/
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
U-Boot version command is no longer showing information about GCC and LD.
The reason is that version.h has been removed that's why CC_VERSION_STRING
and LD_VERSION_STRING are not pass.
Values are generated to generated/version_autogenerated.h which is sourced
in version.h.
Fixes: 54ecce2cbf90 ("version: Separate our version string from the version command")
Signed-off-by: Michal Simek <michal.simek@amd.com>
Pull request efi-2025-04-rc5
CI:
* https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/25196
UEFI:
* Export _start symbol from crt0_*_efi stubs
* Move .dynamic out of .text in EFI
* scripts/Makefile.lib: Preserve the .dynstr section as well
Documentation:
* net: miiphybb: Convert documentation to rst
These are mainly DBSC5 DRAM controller specific fixes and updates for
current release. There is the long overdue BL31 start V4H board code as
well, that should be in the current release to make the V4H White Hawk
board usable with SPL, and a fallback U-Boot PSCI implementation
enablement to make sure the board always boots. And finally, there are
two comment fixes.
This section is required by .dynamic and llvm-objcopy will exit with a
fatal error if it is not also preserved in the output.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
EFI applications need to be relocatable. Ordinarily, this is achieved
through a PE-format .reloc section, but since that requires toolchain
tricks to achieve, U-Boot's EFI applications instead embed ELF-flavored
relocation information and use it for self-relocation; thus, the
.dynamic section needs to be preserved.
Before this patch, it was tacked on to the end of .text, but this was
not proper: A .text section is SHT_PROGBITS, while the .dynamic section
is SHT_DYNAMIC. Attempting to combine them like this creates a section
type mismatch. While GNU ld doesn't seem to complain, LLVM's lld
considers this a fatal linking error.
This patch moves .dynamic out to its own section, so that the output ELF
has the correct types. (They're all mashed together when converting to
binary anyway, so this patch causes no change in the final .efi output.)
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
While the _start label is only intended for use locally to populate the
(hand-written) PE header, the linker script includes ENTRY(_start) which
designates it as the entry point in the output ELF, resulting in linker
warnings under some linkers (e.g. LLVM's lld) due to _start not being a
globally-visible symbol. Since ELF is only an intermediary build
format, and the aforementioned PE header correctly points to _start, the
ENTRY(_start) directive could easily be removed to silence this warning.
However, since some developers who are debugging EFI by analyzing the
intermediary ELF may appreciate having correct entry-point information,
this patch instead promotes the _start labels to global symbols,
silencing the linker warning and making the intermediary ELF reflect the
true entry point.
This patch doesn't affect the final output binaries in any way.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Convert the current miiphybb documentation to rst. Rename
the README.bitbangMII to bitbangmii.rst in the process.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Make struct renesas_dbsc5_board_config {} definition public via
include/dbsc5.h, so this structure can be defined in board files
and passed into the DBSC5 DRAM driver by overriding weak function
dbsc5_get_board_data() on board level.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add auto-detection and handling of Renesas R-Car V4H-3 and V4H-5
in addition to V4H-7 SoC variants based on OTP fuse programming.
The V4H-3 and V4H-5 variants have reduced DRAM frequency options.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Update the DRAM initialization code to match DBSC5 initialization code
rev.1.10 , which is currently the latest version available. This makes
DRAM initialization operational on Renesas R-Car V4H R8A779G0 rev.3.0.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reinstate missing increment by two in DBTR11 calculation based
on the original DBSC5 initialization code rev.0.80. The original
code did ... ODTLon - (js2[JS2_tODTon_min] - 1) + 1 , which was
incorrectly converted into ODTLon - js2[JS2_tODTon_min], but
should have been converted to ODTLon - js2[JS2_tODTon_min] + 2.
Add the missing +2 .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The JS1 index is calculated correctly, but the limiter cannot
be the max() function because the index should be lower than
JS1_USABLEC_SPEC_HI and the max() function would unconditionally
override the JS1 index to JS1_USABLEC_SPEC_HI. Use clamp() to
limit the JS1 index instead.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Fix copy paste error in MD pin handling for 5500 Mbps and 4800 Mbps case,
each should be handled by MD[19,17] == 2 and MD[19,17] == 3 respectively.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The DBSC5 DRAM controller driver needs access to OTP fuses to discern
Renesas R-Car V4H-3, V4H-5 and V4H-7 SoC variants based on OTP fuse
programming. Make OTP block DT node available in U-Boot SPL DT so the
DBSC5 driver can determine its base address and read out the OTP fuses.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The R-Car V4H SPL implementation was originally running on the Cortex-R52
core, but this is no longer the case. Majority of the SPL now runs on the
Cortex-A76 core. Drop the stale description.
Fixes: ec53fdee5bec ("arm64: renesas: Add Renesas R-Car V4H SPL implementation")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Remove stale Makefile description, this used to be valid for the
original Makefile from which the common Makefile was made generic,
but is no longer applicable to the common Makefile.
Fixes: c7d2d7f90a91 ("ARM: renesas: Simplify board Makefiles")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Enable fallback PSCI provider on Renesas R-Car R8A779G0 V4H White Hawk board.
This fallback PSCI provider provides basic PSCI interface which can be used
by the Linux kernel, but does not provide support for bringing up additional
CPU cores or any other functionality, except for SoC level reset.
This fallback PSCI provider is intended as a fallback in case a proper PSCI
provider is not started before the Linux kernel is started. Linux kernel on
ARMv8a will fail to boot in case a PSCI provider is not available, and this
basic fallback PSCI provider assures such a boot failure cannot occur, even
if that means the system will boot in degraded mode with only one CPU core
available, that is still sufficient to perform recovery.
In the common case, a proper PSCI provider should be started as part of
the Linux kernel fitImage, as the BL31 loadable, and replace this basic
fallback PSCI provider before the Linux kernel is started.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Implement custom U_BOOT_FIT_LOADABLE_HANDLER and armv8_switch_to_el2_prep()
handling in case the TFA was loaded. The loadables handler sets up custom
handoff structure used by Renesas TFA fork in fixed location in DRAM and
indicates the TFA has been loaded.
The custom armv8_switch_to_el2_prep() handling tests whether the TFA BL31
was previously loaded and the custom handoff structure was set up, and if
so, jumps to TFA BL31 which switches from EL3 to EL2 and then returns to
U-Boot just past bl in armv8_switch_to_el2() to finish starting the Linux
kernel.
The jump to Linux through TFA works in such a way that the custom
armv8_switch_to_el2_prep() handler configures the custom handoff structure
such that the target jump address of the TFA BL31 on exit is set to the
armv8_switch_to_el2() + 4, which is just past the bl, and just before the
U-Boot code which implements the Linux kernel boot from either EL. The
registers passed through the TFA BL31 are all the registers passed into
armv8_switch_to_el2_prep() to assure maximum compatibility with all the
boot modes. The armv8_switch_to_el2_prep() handler jumps to the TFA BL31,
which does its setup, drops EL from EL3 to EL2 and finally jumps to the
armv8_switch_to_el2() + 4 entry point, which then allows U-Boot to boot
the Linux kernel the usual way.
In order to build suitable kernel fitImage, build TFA first, upstream
is currently under review:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/35799
Or if necessary, downstream repository:
remote: https://github.com/renesas-rcar/arm-trusted-firmware.git
branch: rcar_gen4_v2.7_v4x
```
$ git clean -fqdx
$ MBEDTLS_DIR=/path/to/mbedtls/ make -j$(nproc) bl31 \
PLAT=rcar_gen4 ARCH=aarch64 LSI=V4H SPD=none \
CTX_INCLUDE_AARCH32_REGS=0 MBEDTLS_COMMON_MK=1 \
PTP_NONSECURE_ACCESS=1 LOG_LEVEL=20 DEBUG=0 \
ENABLE_ASSERTIONS=0 E=0
```
Build Linux kernel Image and device tree from current mainline Linux
kernel repository, obtain 'Image' and 'r8a779g0-white-hawk.dtb' .
Bundle the files together using provided fit-image.its fitImage description:
```
$ mkimage -f fit-image.its fitImage
```
To start the kernel fiImage generated in previous step, load fitImage
to DRAM and use the 'bootm' command to start it:
=> load 0x58000000 ... fitImage && bootm 0x58000000
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The regulator extras should be placed in the USB H1 regulator node,
the /regulator-usb-h1-vbus. They are already present there in the
upstream DT, so delete this bogus node entirely.
Signed-off-by: Marek Vasut <marex@denx.de>
Updates for RPi for 2025.04:
- Copy Bluetooth device address in DT
- Keep warnings from firmware in DT, if any
- Only add frame buffer node if CONFIG_FDT_SIMPLEFB is set
- Add identifiers for the new RPi 5 series
The firmware sets local-bd-address, copy it when loading a new DT.
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
The /chosen/user-warnings property is created by the RPi firmware if
there are warnings to report, keep it to make debugging easier.
For example, if the firmware config.txt contains
"dtoverlay=error-example" and that example references an undefined
symbol "&nosuchdev" the warning can be read after boot:
$ cat /proc/device-tree/chosen/user-warnings
dterror: can't find symbol 'nosuchdev'
Failed to resolve overlay 'error-example'
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
The functions fdt_simplefb_add_node and fdt_simplefb_enable_and_mem_rsv
are only available if CONFIG_FDT_SIMPLEFB is enabled.
Signed-off-by: Martin Stolpe <martin.stolpe@gmail.com>
Acked-by: Matthias Brugger <mbrugger@suse.com>
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
The Raspberry Pi foundation have released the Raspberry
Pi 500, CM5 an CM5 lite devices so add the assoicated
revision identifers so we can detect them.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Acked-by: Matthias Brugger <mbrugger@suse.com>
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/25106
- Fix VDDQ voltage setting for LPDDR4x on imx93_evk.
The default PCA9451 BUCK2 volt is 0.6 V for LPDDR4x VDDQ. The codes
are actually used for reworking to LPDDR4 which needs VDDQ at 1.1 V.
So remove it to avoid LPDDR4x issue.
Signed-off-by: Ye Li <ye.li@nxp.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
Resync all defconfig files using qconfig.py
Signed-off-by: Tom Rini <trini@konsulko.com>
ARM: stm32mp: Fix boot hang on STM32MP15xx with 1 GiB of DRAM.
On STM32MP15xx with 1 GiB of DRAM, the gd->ram_top becomes 0,
because DRAM base 0xc0000000 + DRAM size 0x40000000 leads to
gd->ram_top overflow which resets it to 0. Handle this special
case simply by checking for gd->ram_top being zero, and if it
is, assume there is no addr >= gd->ram_top .
This fixes boot hang on STM32MP15xx with 1 GiB of DRAM.
Fixes: 25fb58e88aba ("ARM: stm32mp: Fix dram_bank_mmu_setup() for LMB located above ram_top")
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
A problem we have today is that some instances of IS_ENABLED(FOO) have
crept in to the code. This is in turn because with checkpatch.pl this is
only a warning and not an error, so they were overlooked. And looking
deeper, in the Linux kernel this pattern is allowed because
IS_ENABLED(DEFINED_FLAG) is allowed if discouraged and a quick skim of
the instances I saw in the current kernel follow this pattern. In U-Boot
however, this is not allowed, so bump to an error.
Signed-off-by: Tom Rini <trini@konsulko.com>
In case MAX_SYMLINK_NEST is reached while determining the size
on a symlink node, the function returns immediately.
This would not free the resources after the free_strings: label
causing a memory leak.
Set the ret value and just break out of the switch to fix this.
Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
The GPL-2.1+ SPDX License Identifier doesn't exist, but luckily the full
license text was available which shows that GPL-2.1+ was a typo and it
should have been LGPL-2.1-or-later.
As the '+' in LGPL-2.1+ is deprecated in SPDX 3.0, use the preferred
identifier, which is '-or-later'.
Normally the full license header is removed when switching to SPDX
License Identifiers, so do that now.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Update Sumit Garg's email address to @kernel.org.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
AMD/Xilinx changes for v2025.04-rc4
Zynq:
- Guard code around SPL_FS_LOAD_PAYLOAD_NAME
Versal*:
- Remove tftp block size 4096
Versal:
- Use clocks per DT binding
- Store driver data in data section
Versal Gen 2:
- Fix major/minor version decoding
The zynqmp gem driver support max MTU size 1536, so remove tftp
block size 4096 from defconfig and use default tftp block size.
Fixes: a33b4b96b3cf ("xilinx: Enable MBEDTLS/LWIP/WGET and WGET_HTTPS")
Signed-off-by: Padmarao Begari <padmarao.begari@amd.com>
Link: https://lore.kernel.org/r/20250304043030.2344536-1-padmarao.begari@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
The following was reported by Coverity scan:
*** CID 542488: Control flow issues (NO_EFFECT)
/drivers/led/led-uclass.c: 277 in led_get_function_name()
271 return uc_plat->label;
272
273 /* Now try to detect function label name */
274 func = dev_read_string(dev, "function");
275 cp = dev_read_u32(dev, "color", &color);
276 // prevent coverity scan error CID 541279: (TAINTED_SCALAR)
>>> CID 542488: Control flow issues (NO_EFFECT)
>>> This less-than-zero comparison of an unsigned value is never true. "color < 0U".
277 if (color < LED_COLOR_ID_WHITE || color >= LED_COLOR_ID_MAX)
278 cp = -EINVAL;
279
Fix it.
Addresses-Coverity-ID: 542488
Link: https://lists.denx.de/pipermail/u-boot/2025-February/581567.html
Signed-off-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Currently, Kconfig allows building CONFIG_DM_74X164 without
CONFIG_DM_SPI, which results in linker errors because this driver
actually uses dm_spi_* functions:
drivers/gpio/74x164_gpio.o: in function `gen_74x164_write_conf':
undefined reference to `dm_spi_claim_bus'
undefined reference to `dm_spi_xfer'
undefined reference to `dm_spi_release_bus'
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Simon Glass <sjg@chromium.org> says:
This series has the skip-at-start change and a few fixes.
Sadly it also includes a revert for the dm_probe_devices() patch, since
it breaks jerry (RK3288). I will need to investigate way.
It is based on -next and I can send a PR if desired.
https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/24835
Link: https://lore.kernel.org/r/20250226162621.2681677-1-sjg@chromium.org
With a recent Binman change, the skip-at-start property is now honoured,
meaning that all image-pos values in the affected section start from
the skip-at-start value.
The x86 code works around the old behaviour at present, so update it.
Signed-off-by: Simon Glass <sjg@chromium.org>
A discussion on the mailing list about dealing with block offsets and
binman symbols made me think that something is wrong with how Binman
deals with the skip-at-start property.
The feature was originally designed to handle x86 ROMs, which are mapped
at the top of the address space. That seemed too specific, whereas
skipping some space at the start seemed more generally useful.
It has proved useful. For example, rockchip images start at block 64,
so a skip-at-start of 0x8000 deals with this.
But it doesn't actually work correctly, since the image_pos value does
not give the actual position on the media.
Fix this and update the documentation, moving it into the 'section'
section.
Signed-off-by: Simon Glass <sjg@chromium.org>
The property is named end_at_4gb so name the variable the same, to avoid
confusion.
Signed-off-by: Simon Glass <sjg@chromium.org>
Snow requires a fixed bloblist to operate, so re-enable this option.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 864106f3c47 ("bloblist: Make BLOBLIST_ALLOC the default")
Unfortunately this change was not safe as some devices are bound before
relocation, but we don't want to probe them.
It causes 'raise: Signal # 8 caught' on jerry.
Move the bootstage timer to after autoprobe in initf_dm() since the
trace test does not tolerate any variance.
This reverts commit 21dd873572a01d74bfdfceb7a30b056f8ccba187.
Signed-off-by: Simon Glass <sjg@chromium.org>
The commit bc07851897bd ("board: ti: Pull redundant DDR functions to a
common location and Fixup DDR size when ECC is enabled") broke DRAM
support for the Verdin AM62. This was partially fixed with commit
3f866c47b582 ("board: verdin-am62: add dram_init_banksize"). However,
because fixup_memory_node was not called, the Linux kernel was started
with the wrong memory size on modules with less memory available. This
resulted in boot failures. Fix this issue by calling fixup_memory_node
in the board file.
spl_perform_fixups will be called in the SPL and now sets the correct
memory size in the device tree of U-Boot by calling fixup_memory_node.
U-Boot will then adjust the memory sizes of Linux during bootm/booti in
fdt_fixup_memory_banks. This chain ensures that U-Boot and Linux only
use RAM that is actually available.
Fixes: 3f866c47b582 ("board: verdin-am62: add dram_init_banksize")
Fixes: bc07851897bd ("board: ti: Pull redundant DDR functions to a common location and Fixup DDR size when ECC is enabled")
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
When enabling net console and console multiplexing, a boot crash was
observed using mtk_eth driver with stdin/stdout set to "serial,nc"
in persistent environment:
> CPU: MediaTek MT7981
> Model: OpenWrt One
> DRAM: 1 GiB
> Core: 35 devices, 15 uclasses, devicetree: separate
> spi-nand: spi_nand spi_nand@0: Winbond SPI NAND was found.
> spi-nand: spi_nand spi_nand@0: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 64
> Loading Environment from UBI... SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
> mtd: partition "ubi" extends beyond the end of device "spi-nand0" -- size truncated to 0x7f00000
> Read 126976 bytes from volume ubootenv to 000000007f7bf0c0
> Read 126976 bytes from volume ubootenv2 to 000000007f7de100
> OK
> "Synchronous Abort" handler, esr 0x96000004, far 0xeafffffeea000018
> elr: 0000000041e63cd4 lr : 0000000041e1b844 (reloc)
> elr: 000000007ff9ecd4 lr : 000000007ff56844
> x0 : eafffffeea000018 x1 : 000000007fb552e0
> x2 : 00000000000000fe x3 : 0000000000000000
The cause is that "serial,nc" forced the console subsystem to
initialize the ethernet driver before ethernet subsystem
initialization (console_init_r() is called before initr_net()).
During the mtk_eth driver initialization, mdio_register() will be
called, and miiphy_get_dev_by_name() will then be called.
The miiphy_get_dev_by_name() will check the list "mii_devs" to see
if the passed device name exists. However the mii_devs is defined
without initialization:
> static struct list_head mii_devs;
and the actual initialization is done in the following chain:
initr_net -> eth_initialize -> eth_common_init -> miiphy_init
Since initr_net() hasn't be called, iterating over the mii_devs
will access to physical address 0 (mii_devs.next == NULL) and will
cause the crash.
The fix is to define mii_devs using:
> static LIST_HEAD(mii_devs);
As the "current_mii" is defined as a static variable, it will
always be NULL in board_r stage and initializing it will NULL is
unnecessary. So the entire miiphy_init() can be remove.
Signed-off-by: Weijie Gao <hackpascal@gmail.com>
My previous address is no longer accessible, but I will continue to be
involved in maintaining the ADI sc5xx platforms. This updates my contact
information and hopefully avoids bouncing emails from other developers.
Signed-off-by: Greg Malysa <malysagreg@gmail.com>
ES1 silicon is 0x10 (16) and production is 0x20 (32) but correct number to
see are v1.0 or v2.0 instead of v16 or v32.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20095339334fe07f373ffae3bdbfec51f5a00dc7.1739882585.git.michal.simek@amd.com
Line 171 in README is describing that before relocation
no code should use global variable because global variables
are placed to BSS section which is initialized to 0 after
relocation.
On Versal platforms clock driver is initialized before
relocation (via using dm,bootph-all flag in DT) and global
variables are initialized which works if this is used only
before relocation. But the variables are used after
relocation too but values are zeroed which is ending up
incorrect behavior.
That's why place variables to data section to ensure that
values are not cleared which is for now the quickest
temporary solution. The correct way to do it is to move
all global variables to private data to avoid it.
Signed-off-by: Padmarao Begari <padmarao.begari@amd.com>
Link: https://lore.kernel.org/r/20250218052419.1141139-1-padmarao.begari@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Guard code around CONFIG_SPL_FS_LOAD_PAYLOAD_NAME usage to avoid
compilation failure.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/f15a9762494945814b06a71db90ee4db59dd17ed.1738910601.git.michal.simek@amd.com
CI: https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq/-/pipelines/24933
Fixes:
- Re-arm packet buffer in error case in tsec driver
- Fix LS1021a build
- Fix flush dcache alignment in caam_hash
CI:
* https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/24904
UEFI:
* Let efi_net_set_dp properly update the device path
Network:
* Avoid buffer overflows in wget_info with legacy TCP stack
As per the bindings the reference clocks naming has changed
from "pl_alt_ref_clk" to "pl_alt_ref" and "ref_clk" to "ref".
Update the same in the clock driver. Also add the fallback option
for older DT bindings.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20250206091533.1447234-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Loading a FIT kernel image with hash hardware acceleration enabled
(CONFIG_SHA_HW_ACCEL=y) displays the following CACHE warning:
[...]
Trying 'kernel-1' kernel subimage
[...]
Verifying Hash Integrity ... sha256CACHE: Misaligned operation at
range [16000128, 1673fae8]
[...]
Trying 'ramdisk-1' ramdisk subimage
[...]
Verifying Hash Integrity ... sha256CACHE: Misaligned operation at
range [1676d6d4, 1737a5d4]
[...]
Trying 'fdt-imx6q-xxx.dtb' fdt subimage
[...]
Verifying Hash Integrity ... sha256CACHE: Misaligned operation at
range [1673fbdc, 1674b0dc]
[...]
This patch fixes it.
Tested on:
- i.MX 6 custom board
- LS1021A custom board
Signed-off-by: Benjamin Lemouzy <blemouzy@centralp.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Fix build error "undefined reference to `is_warm_boot'" when
ls1021atsn and ls1021atwr boards are built with CONFIG_SPL=y and
CONFIG_DEEP_SLEEP=n.
Signed-off-by: Benjamin Lemouzy <blemouzy@centralp.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
spl_perform_fixups is redundant in the current implementation. SPLs call
dram_init during spl_enable_cache in arch/arm/mach-k3/common.c. In
U-Boot, dram_init and dram_init_banksize are automatically called in
init_sequence_f. Therefore, SPLs and U-Boot always determine the correct
RAM size. During Linux boot, fdt_fixup_memory_banks adjusts the RAM size
in the Linux device tree, ensuring correct RAM usage.
dram_init() calls get_ram_size() for the Verdin AM62, which determines
the correct RAM size through read/write operations. However, due to the
K3 bootflow placing ATF in RAM and requiring cache coherence, calling
get_ram_size() with caches enabled prevents ATF boot. Removing this call
restores ATF boot functionality.
This fixes a regression introduced in commit 4164289db882 ("board:
verdin-am62: fix missing memory fixup call") which prevents some of our
Verdin AM62 modules from booting.
Fixes: 4164289db882 ("board: verdin-am62: fix missing memory fixup call")
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
The defines for the different build phases shouldn't be used in device
trees, currently they aren't even defined for device tree pre processing,
resulting in build errors.
Link: https://lists.denx.de/pipermail/u-boot/2025-March/582787.html
Signed-off-by: Hendrik Donner <hd@os-cillation.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
The header of the StarFive U-Boot SPL file u-boot-spl.normal.out has a
field indicating the payload size. When copying U-Boot SPL from a
partition the copied file might be too long.
Currently in this situation a misleading error message 'Incorrect CRC32' is
written.
We must use the payload size and not the file size when calculating the
CRC32.
Write a warning if the file is too long indicating the correct size. This
enables the user to truncate the file accordingly.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
U-Boot version command is no longer showing information about GCC and LD.
The reason is that version.h has been removed that's why CC_VERSION_STRING
and LD_VERSION_STRING are not pass.
Values are generated to generated/version_autogenerated.h which is sourced
in version.h.
Fixes: 54ecce2cbf90 ("version: Separate our version string from the version command")
Signed-off-by: Michal Simek <michal.simek@amd.com>
Pull request efi-2025-04-rc5
CI:
* https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/25196
UEFI:
* Export _start symbol from crt0_*_efi stubs
* Move .dynamic out of .text in EFI
* scripts/Makefile.lib: Preserve the .dynstr section as well
Documentation:
* net: miiphybb: Convert documentation to rst
These are mainly DBSC5 DRAM controller specific fixes and updates for
current release. There is the long overdue BL31 start V4H board code as
well, that should be in the current release to make the V4H White Hawk
board usable with SPL, and a fallback U-Boot PSCI implementation
enablement to make sure the board always boots. And finally, there are
two comment fixes.
EFI applications need to be relocatable. Ordinarily, this is achieved
through a PE-format .reloc section, but since that requires toolchain
tricks to achieve, U-Boot's EFI applications instead embed ELF-flavored
relocation information and use it for self-relocation; thus, the
.dynamic section needs to be preserved.
Before this patch, it was tacked on to the end of .text, but this was
not proper: A .text section is SHT_PROGBITS, while the .dynamic section
is SHT_DYNAMIC. Attempting to combine them like this creates a section
type mismatch. While GNU ld doesn't seem to complain, LLVM's lld
considers this a fatal linking error.
This patch moves .dynamic out to its own section, so that the output ELF
has the correct types. (They're all mashed together when converting to
binary anyway, so this patch causes no change in the final .efi output.)
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
While the _start label is only intended for use locally to populate the
(hand-written) PE header, the linker script includes ENTRY(_start) which
designates it as the entry point in the output ELF, resulting in linker
warnings under some linkers (e.g. LLVM's lld) due to _start not being a
globally-visible symbol. Since ELF is only an intermediary build
format, and the aforementioned PE header correctly points to _start, the
ENTRY(_start) directive could easily be removed to silence this warning.
However, since some developers who are debugging EFI by analyzing the
intermediary ELF may appreciate having correct entry-point information,
this patch instead promotes the _start labels to global symbols,
silencing the linker warning and making the intermediary ELF reflect the
true entry point.
This patch doesn't affect the final output binaries in any way.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Reinstate missing increment by two in DBTR11 calculation based
on the original DBSC5 initialization code rev.0.80. The original
code did ... ODTLon - (js2[JS2_tODTon_min] - 1) + 1 , which was
incorrectly converted into ODTLon - js2[JS2_tODTon_min], but
should have been converted to ODTLon - js2[JS2_tODTon_min] + 2.
Add the missing +2 .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The JS1 index is calculated correctly, but the limiter cannot
be the max() function because the index should be lower than
JS1_USABLEC_SPEC_HI and the max() function would unconditionally
override the JS1 index to JS1_USABLEC_SPEC_HI. Use clamp() to
limit the JS1 index instead.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The DBSC5 DRAM controller driver needs access to OTP fuses to discern
Renesas R-Car V4H-3, V4H-5 and V4H-7 SoC variants based on OTP fuse
programming. Make OTP block DT node available in U-Boot SPL DT so the
DBSC5 driver can determine its base address and read out the OTP fuses.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The R-Car V4H SPL implementation was originally running on the Cortex-R52
core, but this is no longer the case. Majority of the SPL now runs on the
Cortex-A76 core. Drop the stale description.
Fixes: ec53fdee5bec ("arm64: renesas: Add Renesas R-Car V4H SPL implementation")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Remove stale Makefile description, this used to be valid for the
original Makefile from which the common Makefile was made generic,
but is no longer applicable to the common Makefile.
Fixes: c7d2d7f90a91 ("ARM: renesas: Simplify board Makefiles")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Enable fallback PSCI provider on Renesas R-Car R8A779G0 V4H White Hawk board.
This fallback PSCI provider provides basic PSCI interface which can be used
by the Linux kernel, but does not provide support for bringing up additional
CPU cores or any other functionality, except for SoC level reset.
This fallback PSCI provider is intended as a fallback in case a proper PSCI
provider is not started before the Linux kernel is started. Linux kernel on
ARMv8a will fail to boot in case a PSCI provider is not available, and this
basic fallback PSCI provider assures such a boot failure cannot occur, even
if that means the system will boot in degraded mode with only one CPU core
available, that is still sufficient to perform recovery.
In the common case, a proper PSCI provider should be started as part of
the Linux kernel fitImage, as the BL31 loadable, and replace this basic
fallback PSCI provider before the Linux kernel is started.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Implement custom U_BOOT_FIT_LOADABLE_HANDLER and armv8_switch_to_el2_prep()
handling in case the TFA was loaded. The loadables handler sets up custom
handoff structure used by Renesas TFA fork in fixed location in DRAM and
indicates the TFA has been loaded.
The custom armv8_switch_to_el2_prep() handling tests whether the TFA BL31
was previously loaded and the custom handoff structure was set up, and if
so, jumps to TFA BL31 which switches from EL3 to EL2 and then returns to
U-Boot just past bl in armv8_switch_to_el2() to finish starting the Linux
kernel.
The jump to Linux through TFA works in such a way that the custom
armv8_switch_to_el2_prep() handler configures the custom handoff structure
such that the target jump address of the TFA BL31 on exit is set to the
armv8_switch_to_el2() + 4, which is just past the bl, and just before the
U-Boot code which implements the Linux kernel boot from either EL. The
registers passed through the TFA BL31 are all the registers passed into
armv8_switch_to_el2_prep() to assure maximum compatibility with all the
boot modes. The armv8_switch_to_el2_prep() handler jumps to the TFA BL31,
which does its setup, drops EL from EL3 to EL2 and finally jumps to the
armv8_switch_to_el2() + 4 entry point, which then allows U-Boot to boot
the Linux kernel the usual way.
In order to build suitable kernel fitImage, build TFA first, upstream
is currently under review:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/35799
Or if necessary, downstream repository:
remote: https://github.com/renesas-rcar/arm-trusted-firmware.git
branch: rcar_gen4_v2.7_v4x
```
$ git clean -fqdx
$ MBEDTLS_DIR=/path/to/mbedtls/ make -j$(nproc) bl31 \
PLAT=rcar_gen4 ARCH=aarch64 LSI=V4H SPD=none \
CTX_INCLUDE_AARCH32_REGS=0 MBEDTLS_COMMON_MK=1 \
PTP_NONSECURE_ACCESS=1 LOG_LEVEL=20 DEBUG=0 \
ENABLE_ASSERTIONS=0 E=0
```
Build Linux kernel Image and device tree from current mainline Linux
kernel repository, obtain 'Image' and 'r8a779g0-white-hawk.dtb' .
Bundle the files together using provided fit-image.its fitImage description:
```
$ mkimage -f fit-image.its fitImage
```
To start the kernel fiImage generated in previous step, load fitImage
to DRAM and use the 'bootm' command to start it:
=> load 0x58000000 ... fitImage && bootm 0x58000000
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The /chosen/user-warnings property is created by the RPi firmware if
there are warnings to report, keep it to make debugging easier.
For example, if the firmware config.txt contains
"dtoverlay=error-example" and that example references an undefined
symbol "&nosuchdev" the warning can be read after boot:
$ cat /proc/device-tree/chosen/user-warnings
dterror: can't find symbol 'nosuchdev'
Failed to resolve overlay 'error-example'
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
On STM32MP15xx with 1 GiB of DRAM, the gd->ram_top becomes 0,
because DRAM base 0xc0000000 + DRAM size 0x40000000 leads to
gd->ram_top overflow which resets it to 0. Handle this special
case simply by checking for gd->ram_top being zero, and if it
is, assume there is no addr >= gd->ram_top .
This fixes boot hang on STM32MP15xx with 1 GiB of DRAM.
Fixes: 25fb58e88aba ("ARM: stm32mp: Fix dram_bank_mmu_setup() for LMB located above ram_top")
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
A problem we have today is that some instances of IS_ENABLED(FOO) have
crept in to the code. This is in turn because with checkpatch.pl this is
only a warning and not an error, so they were overlooked. And looking
deeper, in the Linux kernel this pattern is allowed because
IS_ENABLED(DEFINED_FLAG) is allowed if discouraged and a quick skim of
the instances I saw in the current kernel follow this pattern. In U-Boot
however, this is not allowed, so bump to an error.
Signed-off-by: Tom Rini <trini@konsulko.com>
In case MAX_SYMLINK_NEST is reached while determining the size
on a symlink node, the function returns immediately.
This would not free the resources after the free_strings: label
causing a memory leak.
Set the ret value and just break out of the switch to fix this.
Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
The GPL-2.1+ SPDX License Identifier doesn't exist, but luckily the full
license text was available which shows that GPL-2.1+ was a typo and it
should have been LGPL-2.1-or-later.
As the '+' in LGPL-2.1+ is deprecated in SPDX 3.0, use the preferred
identifier, which is '-or-later'.
Normally the full license header is removed when switching to SPDX
License Identifiers, so do that now.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
The zynqmp gem driver support max MTU size 1536, so remove tftp
block size 4096 from defconfig and use default tftp block size.
Fixes: a33b4b96b3cf ("xilinx: Enable MBEDTLS/LWIP/WGET and WGET_HTTPS")
Signed-off-by: Padmarao Begari <padmarao.begari@amd.com>
Link: https://lore.kernel.org/r/20250304043030.2344536-1-padmarao.begari@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
The following was reported by Coverity scan:
*** CID 542488: Control flow issues (NO_EFFECT)
/drivers/led/led-uclass.c: 277 in led_get_function_name()
271 return uc_plat->label;
272
273 /* Now try to detect function label name */
274 func = dev_read_string(dev, "function");
275 cp = dev_read_u32(dev, "color", &color);
276 // prevent coverity scan error CID 541279: (TAINTED_SCALAR)
>>> CID 542488: Control flow issues (NO_EFFECT)
>>> This less-than-zero comparison of an unsigned value is never true. "color < 0U".
277 if (color < LED_COLOR_ID_WHITE || color >= LED_COLOR_ID_MAX)
278 cp = -EINVAL;
279
Fix it.
Addresses-Coverity-ID: 542488
Link: https://lists.denx.de/pipermail/u-boot/2025-February/581567.html
Signed-off-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Currently, Kconfig allows building CONFIG_DM_74X164 without
CONFIG_DM_SPI, which results in linker errors because this driver
actually uses dm_spi_* functions:
drivers/gpio/74x164_gpio.o: in function `gen_74x164_write_conf':
undefined reference to `dm_spi_claim_bus'
undefined reference to `dm_spi_xfer'
undefined reference to `dm_spi_release_bus'
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Simon Glass <sjg@chromium.org> says:
This series has the skip-at-start change and a few fixes.
Sadly it also includes a revert for the dm_probe_devices() patch, since
it breaks jerry (RK3288). I will need to investigate way.
It is based on -next and I can send a PR if desired.
https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/24835
Link: https://lore.kernel.org/r/20250226162621.2681677-1-sjg@chromium.org
A discussion on the mailing list about dealing with block offsets and
binman symbols made me think that something is wrong with how Binman
deals with the skip-at-start property.
The feature was originally designed to handle x86 ROMs, which are mapped
at the top of the address space. That seemed too specific, whereas
skipping some space at the start seemed more generally useful.
It has proved useful. For example, rockchip images start at block 64,
so a skip-at-start of 0x8000 deals with this.
But it doesn't actually work correctly, since the image_pos value does
not give the actual position on the media.
Fix this and update the documentation, moving it into the 'section'
section.
Signed-off-by: Simon Glass <sjg@chromium.org>
Unfortunately this change was not safe as some devices are bound before
relocation, but we don't want to probe them.
It causes 'raise: Signal # 8 caught' on jerry.
Move the bootstage timer to after autoprobe in initf_dm() since the
trace test does not tolerate any variance.
This reverts commit 21dd873572a01d74bfdfceb7a30b056f8ccba187.
Signed-off-by: Simon Glass <sjg@chromium.org>
The commit bc07851897bd ("board: ti: Pull redundant DDR functions to a
common location and Fixup DDR size when ECC is enabled") broke DRAM
support for the Verdin AM62. This was partially fixed with commit
3f866c47b582 ("board: verdin-am62: add dram_init_banksize"). However,
because fixup_memory_node was not called, the Linux kernel was started
with the wrong memory size on modules with less memory available. This
resulted in boot failures. Fix this issue by calling fixup_memory_node
in the board file.
spl_perform_fixups will be called in the SPL and now sets the correct
memory size in the device tree of U-Boot by calling fixup_memory_node.
U-Boot will then adjust the memory sizes of Linux during bootm/booti in
fdt_fixup_memory_banks. This chain ensures that U-Boot and Linux only
use RAM that is actually available.
Fixes: 3f866c47b582 ("board: verdin-am62: add dram_init_banksize")
Fixes: bc07851897bd ("board: ti: Pull redundant DDR functions to a common location and Fixup DDR size when ECC is enabled")
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
When enabling net console and console multiplexing, a boot crash was
observed using mtk_eth driver with stdin/stdout set to "serial,nc"
in persistent environment:
> CPU: MediaTek MT7981
> Model: OpenWrt One
> DRAM: 1 GiB
> Core: 35 devices, 15 uclasses, devicetree: separate
> spi-nand: spi_nand spi_nand@0: Winbond SPI NAND was found.
> spi-nand: spi_nand spi_nand@0: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 64
> Loading Environment from UBI... SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
> mtd: partition "ubi" extends beyond the end of device "spi-nand0" -- size truncated to 0x7f00000
> Read 126976 bytes from volume ubootenv to 000000007f7bf0c0
> Read 126976 bytes from volume ubootenv2 to 000000007f7de100
> OK
> "Synchronous Abort" handler, esr 0x96000004, far 0xeafffffeea000018
> elr: 0000000041e63cd4 lr : 0000000041e1b844 (reloc)
> elr: 000000007ff9ecd4 lr : 000000007ff56844
> x0 : eafffffeea000018 x1 : 000000007fb552e0
> x2 : 00000000000000fe x3 : 0000000000000000
The cause is that "serial,nc" forced the console subsystem to
initialize the ethernet driver before ethernet subsystem
initialization (console_init_r() is called before initr_net()).
During the mtk_eth driver initialization, mdio_register() will be
called, and miiphy_get_dev_by_name() will then be called.
The miiphy_get_dev_by_name() will check the list "mii_devs" to see
if the passed device name exists. However the mii_devs is defined
without initialization:
> static struct list_head mii_devs;
and the actual initialization is done in the following chain:
initr_net -> eth_initialize -> eth_common_init -> miiphy_init
Since initr_net() hasn't be called, iterating over the mii_devs
will access to physical address 0 (mii_devs.next == NULL) and will
cause the crash.
The fix is to define mii_devs using:
> static LIST_HEAD(mii_devs);
As the "current_mii" is defined as a static variable, it will
always be NULL in board_r stage and initializing it will NULL is
unnecessary. So the entire miiphy_init() can be remove.
Signed-off-by: Weijie Gao <hackpascal@gmail.com>
Line 171 in README is describing that before relocation
no code should use global variable because global variables
are placed to BSS section which is initialized to 0 after
relocation.
On Versal platforms clock driver is initialized before
relocation (via using dm,bootph-all flag in DT) and global
variables are initialized which works if this is used only
before relocation. But the variables are used after
relocation too but values are zeroed which is ending up
incorrect behavior.
That's why place variables to data section to ensure that
values are not cleared which is for now the quickest
temporary solution. The correct way to do it is to move
all global variables to private data to avoid it.
Signed-off-by: Padmarao Begari <padmarao.begari@amd.com>
Link: https://lore.kernel.org/r/20250218052419.1141139-1-padmarao.begari@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
As per the bindings the reference clocks naming has changed
from "pl_alt_ref_clk" to "pl_alt_ref" and "ref_clk" to "ref".
Update the same in the clock driver. Also add the fallback option
for older DT bindings.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20250206091533.1447234-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Loading a FIT kernel image with hash hardware acceleration enabled
(CONFIG_SHA_HW_ACCEL=y) displays the following CACHE warning:
[...]
Trying 'kernel-1' kernel subimage
[...]
Verifying Hash Integrity ... sha256CACHE: Misaligned operation at
range [16000128, 1673fae8]
[...]
Trying 'ramdisk-1' ramdisk subimage
[...]
Verifying Hash Integrity ... sha256CACHE: Misaligned operation at
range [1676d6d4, 1737a5d4]
[...]
Trying 'fdt-imx6q-xxx.dtb' fdt subimage
[...]
Verifying Hash Integrity ... sha256CACHE: Misaligned operation at
range [1673fbdc, 1674b0dc]
[...]
This patch fixes it.
Tested on:
- i.MX 6 custom board
- LS1021A custom board
Signed-off-by: Benjamin Lemouzy <blemouzy@centralp.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>