David Lechner [Fri, 4 Jul 2025 20:39:27 +0000 (15:39 -0500)]
configs: legoev3: adjust to reduce binary size
Adjust legoev3_defconfig to reduce the binary output size.
As u-boot has bloated a bit over the years, the legoev3_defconfig can no
longer build something that fits in the 256kB size limit of the EV3.
This drops a few unused features, but the real difference-makers are
enabling thumb instructions and using link time optimization to reduce
the size.
This reduced u-boot.bin from 279,920 to 198,416 bytes on my local
machine with arm-none-eabi-gcc (15:13.2.rel1-2) 13.2.1 20231009.
HAS_BOARD_SIZE_LIMIT is also added to catch any future regressions.
Signed-off-by: David Lechner <david@lechnology.com>
mx6sabresd: Reduce U-Boot proper size to fix boot regression
The mx6sabresd U-Boot proper binary size has grown beyond the
CONFIG_BOARD_SIZE_LIMIT.
Reduce its size by removing the CONFIG_MULTI_DTB_FIT, BOOTM_PLAN9 and
BOOTM_RTEMS options.
According to doc/README.multi-dtb-fit:
"Usually the DTB is selected by the SPL and passed down to U-Boot. But some
platforms don't use the SPL. In this case MULTI_DTB_FIT can used to provide
U-Boot with a choice of DTBs"
mx6sabresd uses SPL, so MULTI_DTB_FIT can be safely dropped as the DTB
selection in SPL is done by board_fit_config_name_match().
Tom Rini [Thu, 3 Jul 2025 14:25:38 +0000 (08:25 -0600)]
Merge tag 'efi-next-03072025' of https://source.denx.de/u-boot/custodians/u-boot-tpm into next
Sughosh added EFI HTTP(s) support into our eficonfig application. Up to
now we could only enable that via our efidebug command. Users now get that
option on the eficonfig menu.
Javier implemented support for the EFI_PARTITION_INFO_PROTOCOL,
to provide cached partition information for GPT partition types.
The protocol describes legacy MBR partition types, but that's for backward
compatibility and not implemented by this series.
The protocol is needed by [0], an implementation of a UEFI based A/B boot
protocol for the root filesystem.
Paul added support for EFI_DEBUG_IMAGE_INFO_TABLE. This is part of the EFI
spec and is defining a debug protocol that Google currently uses to debug
their Generic Bootloader project [1][2], using EFI to load Android.
Heinrich contributed a test EFI application for it as well.
The efi_realloc() function he added will realloc any type of memory to
BootServicesData, but keeping in mind the new protocol is the only consumer
he will fix that on a followup patch.
Finally another round of smatch fixes from Andrew cleans up coding errors.
The CI https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/26935
seems happy
The firmware on the Icicle is capable of providing a devicetree in a1 to
U-Boot, but until now the devicetree has been packaged in a "payload" [1]
alongside U-Boot (or other bootloaders/RTOSes) and appended to the image.
The address of this appended devicetree is placed in a1 by the firmware.
This meant that the mechanism used by OF_SEPARATE to locate the
devicetree at the end of the image would pick up the one provided by the
firmware when u-boot-nodtb.bin was in the payload and U-Boot's devicetree
when u-boot.bin was.
The firmware is now going to be capable of providing a minimal devicetree
(quite cut down due to severe space constraints), but this devicetree is
linked into the firmware that runs out of the L2 rather than at the end
of the U-Boot image.
Implement board_fdt_blob_setup() so that this devicetree can be
optionally used, and the devicetree provided in the "payload" can be
used without relying on "happening" to implement the same strategy as
OF_SEPARATE expects in combination with u-boot-nodtb.bin.
Unlike other RISC-V boards, the firmware provided devicetree is only
used when OF_BOARD is set, so that the almost certainly more complete
devicetree in U-Boot will be used unless explicitly requested otherwise.
Implement board_fit_config_name_match(), so that, using the firmware
provided cut-down/minimal dtb, U-Boot can select one of several
devicetrees when MULTI_DTB_FIT is enabled.
Enabling both MULTI_DTB_FIT and OF_BOARD will lead to a conflict
between the two options, with the latter taking priority due to
board_fdt_blob_setup() being executed before board_fit_config_name_match(),
which causes gd->fdt_blob to be overwritten with a pointer to the
minimal devicetree rather than the location of the fit image containing
the multiple dtbs. Let MULTI_DTB_FIT take priority in this case, by
explicitly blocking the override when MULTI_DTB_FIT is enabled.
Yao Zi [Wed, 18 Jun 2025 09:54:56 +0000 (09:54 +0000)]
riscv: dts: th1520: Add pin controllers
Describe the three pin controllers integrated in TH1520 SoC. Since we
don't have support for clocks in the AON region, a dummy fixed-clock
node is added to supply the pin controller locating in it.
Signed-off-by: Yao Zi <ziyao@disroot.org> Acked-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Yao Zi [Wed, 18 Jun 2025 09:54:55 +0000 (09:54 +0000)]
pinctrl: Port pin controller driver for T-Head TH1520 SoC
The SoC pads of TH1520 are separated into three groups (AP 1, AP 2 and
AON) controlled by independent pin controllers. This patch ports their
driver from Linux kernel with most code for setting pinconf and pinmux
kept as is.
The dt-binding of TH1520 pin controller uses a schema where pins to
configure are specfied as strings and looked up at runtime, which the
generic pinctrl helpers of U-Boot cannot parse, thus a customized
set_state() callback is implemented to parse pinconfig nodes and setup
the configuration.
Signed-off-by: Yao Zi <ziyao@disroot.org> Acked-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Ben Dooks [Fri, 13 Jun 2025 16:12:58 +0000 (17:12 +0100)]
riscv: byteorder: add test for big-endian
Test for big-endian either via __RISCVEB__ which migth be
rather old, or check the BYTE_ORDER if the compiler defines
it (which should be any modern gcc like v12)
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Acked-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Provide a test application to dump the EFI_DEBUG_IMAGE_INFO_TABLE
as implemented in EDK II.
EFI_DEBUG_IMAGE_INFO is not packed in contrast to many other EFI
structures.
As of today EDK II when removing an entry in the EfiDebugImageInfoTable
just sets NormalImage = NULL but does not compact the array. So
TableSize reflects the number of non-NULL entries and not the array
size as reported independently in
https://github.com/tianocore/edk2/pull/11013 and
https://github.com/tianocore/edk2/pull/11019.
The current implementation tolerates this deviation from the UEFI
specification.
This is what the output may look like:
Debug Info Table Dump
=====================
=> dump
Modified
Number of entries: 0x0000004a
Info type 0x00000001
Address: [0x000000008315a000, 0x00000000831bafff]
File: FvFile(D6A2CB7F-6A18-4E2F-B43B-9920A733700A)
Handle: 0x000000017fe3cb18
...
Info type 0x00000001
Address: [0x000000017e8db000, 0x000000017ea00f3f]
File: FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1)
Handle: 0x000000017f358e98
Info type 0x00000001
Address: [0x000000017eae5000, 0x000000017eae81ff]
File: \dbginfodump.efi
Handle: 0x000000017eaf0298
=>
This commit adds the functionality of generate EFI_DEBUG_IMAGE_INFO
while loading the image.
This feature is described in UEFI Spec 2.10. Section 18.4.3.
The implementation ensures support for hardware-assisted debugging and
provides a standardized mechanism for debuggers to discover the load
address of an EFI application.
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Peter Robinson <pbrobinson@gmail.com> Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
EFI_DEBUG_IMAGE_INFO_TABLE is used to store EFI_LOADED_IMAGE for
debug purpose. This commit adds the table to the EFI_CONFIGURATION_TABLE.
This feature is described in UEFI Spec version 2.10. Section 18.4.
The implementation ensures support for hardware-assisted debugging and
provides a standardized mechanism for debuggers to discover and interact
with system-level debug resources.
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Peter Robinson <pbrobinson@gmail.com> Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add EFI_SYSTEM_TABLE_POINTER structure for remote debugger to locate
the address of EFI_SYSTEM_TABLE.
This feature is described in UEFI SPEC version 2.10. Section 18.4.2.
The implementation ensures support for hardware-assisted debugging and
provides a standardized mechanism for debuggers to discover the EFI
system table.
Cc: Peter Robinson <pbrobinson@gmail.com> Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> # change memset(systab_pointer, 0 ...) -> systab_pointer->crc32 = 0; Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
cmd: eficonfig: add support for URI device path based boot options
The eficonfig command provides a menu based interface for maintenance
of the EFI boot options. Add support for adding a URI based boot
option. This boot option can then be used for HTTP boot.
Andrew Goodbody [Wed, 2 Jul 2025 10:01:38 +0000 (11:01 +0100)]
efi_loader: Prevent free of uninitialised pointer
Taking a goto to out_of_resources before receive_lengths is assigned
will result in an attempt to free an unitialised pointer. Instead
initialise receive_lengths to NULL on declaration to prevent this from
occurring.
This issue was found by Smatch.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Andrew Goodbody [Wed, 2 Jul 2025 10:01:36 +0000 (11:01 +0100)]
efi_loader: Prevent dereferencing NULL pointer
Taking the first goto error: in file_open could either result in an
attempt to dereference fh when NULL or else free fh->path which has
not been assigned to and so will be unknown. Avoid both of these
problems by passing path to free instead of fh->path.
This issue found by Smatch.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
efi_selftest: Add basic partition info check to block io test
Test the EFI_PARTITION_INFO_PROTOCOL in the existing EFI_BLOCK_IO_PROTOCOL
unit test. It is fairly basic, since it only checks that the values of the
struct efi_partition_info .revision, .type and .system fields are correct.
It doesn't check the MBR partition record information, because that's not
supported by the EFI_PARTITION_INFO_PROTOCOL implementation yet. The test
can be extended once the support is implemented, or if the in-memory disk
image used for the test is modified to have a GPT partition type instead.
Suggested-by: Tom Rini <trini@konsulko.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
efi_loader: disk: add EFI_PARTITION_INFO_PROTOCOL support
The UEFI 2.10 specification mentions that this protocol shall be installed
along with EFI_BLOCK_IO_PROTOCOL. It provides cached partition information
for MBR and GPT partition types.
This patch just implements support for GPT partition types. The legacy MBR
partition types is only needed for backward compatibility and can be added
as a follow-up if needed, to make it fully compliant with the EFI spec.
Yao Zi [Fri, 6 Jun 2025 04:28:02 +0000 (04:28 +0000)]
riscv: cpu: th1520: Add a routine to bring up secondary cores
On coldboot, only HART 0 among the four HARTs of TH1520 is brought up by
hardware, and the remaining HARTs are in reset states, requiring manual
setup of reset address and deassertion to function normal. Introduce a
routine to do the work.
Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Yao Zi [Fri, 6 Jun 2025 04:28:01 +0000 (04:28 +0000)]
riscv: cpu: th1520: Setup CPU feature CSRs in harts_early_init
C910 cores integrated in TH1520 SoC provide various customized CSRs for
configuring core behavior, including cache coherency and timing, branch
predication, and clock gating for internal components.
This patch sets them up for efficient operation and satisfying
requirements of an SMP system.
Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Yao Zi [Fri, 6 Jun 2025 04:28:00 +0000 (04:28 +0000)]
riscv: aclint_ipi: Support T-Head C900 CLINT
Although timer component of the CLINT isn't fully compatible with the
generic RISC-V ACLINT, the IPI component behaves the same.
As the CLINT doesn't have corresponding riscv_aclint_timer driver
available, let's try looking for a compatible SYSCON device directly
when no riscv_aclint_timer device could be found on IPI initialization.
Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
- Get clock manager address via DT for socfpga_dw_mmc
- Revert "drivers: mmc: rpmb: Use R1 response"
- Fix offsets relative to the end of the partition for mmc env
Michael Walle [Thu, 5 Jun 2025 07:46:10 +0000 (09:46 +0200)]
env: mmc: fix offsets relative to the end of the partition
According to the help text, you can set negative offsets to indicated
that the offset is relative to the end of the parition. But kconfig
doesn't let you specify negative hex values. I think this fell through
the cracks when converting the symbol from a '#define' to a kconfig
option.
Introduce a new boolean kconfig option to switch on the "relative to the
end" behavior.
Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Tom Rini [Tue, 1 Jul 2025 16:52:04 +0000 (10:52 -0600)]
Merge patch series "binman: properly error out if path provided to key-name-hint in signature nodes"
Quentin Schulz <foss+uboot@0leil.net> says:
I misunderstood the documentation and put the signing key in a keys/
directory while setting key-name-hint property in the signature node and
u-boot-spl-pubkey-dtb to a path.
mkimage doesn't fail if it cannot find the public key when signing a
FIT but returns something on stderr to notify the user it couldn't find
the key. The issue is that bintool currently discards stderr if the
command successfully returns, so the FIT is not signed AND the user
isn't made aware of it unless the image is manually inspected.
mkimage does fail when trying to insert a public key in a DTB if it
isn't found but we can have a better error message.
binman: etype: u_boot_spl_pubkey_dtb: provide more explicit error for key-name-hint with path
key-name-hint property in u-boot-spl-pubkey-dtb binman entry may contain
a path instead of a filename due to user mistake.
Because we currently assume it is a filename instead of a path, binman
will find the full path to the key based on that path, and return the
dirname of the full path but keeps the path in key-name-hint instead of
stripping the directories from it.
This means mkimage will fail with the following error message if we have
key-name-hint set to keys/dev:
binman: Error 1 running 'fdt_add_pubkey -a sha256,rsa2048 -k /home/qschulz/work/upstream/u-boot/keys -n keys/dev -r conf /home/qschulz/work/upstream/u-boot/build/ringneck/u-boot-spl-dtbdhsfx3mf': Couldn't open RSA certificate: '/home/qschulz/work/upstream/u-boot/keys/keys/dev.crt': No such file or directory
Let's make it a bit more obvious what the error is by erroring out in
binman if a path is provided in key-name-hint (it is named key-name-hint
and not key-path-hint after all).
binman: etype: fit: raise ValueError if key-name-hint is a path
mkimage doesn't fail if it cannot find the public key but it prints to
stderr. Considering that btool.run() discards stderr, it means binman
happily returns an unsigned FIT and doesn't tell you something went
wrong.
Binman will actually find the file if there's a path in the
key-name-hint property but the current logic expects key-name-hint to be
a filename and thus returns the dirname of the found path for the key,
but with the original key-name-hint appended. This means we can have the
following:
- key-name-hint = "keys/dev"
- name = "/home/qschulz/work/upstream/u-boot/keys/"
so we pass /home/qschulz/work/upstream/u-boot/keys/ to the -k option of
mkimage but the FIT still contains "keys/dev" in key-name-hint which
means mkimage will try to find the key at
/home/qschulz/work/upstream/u-boot/keys/keys/, which doesn't exist.
Let's assume paths are simply not supported (it is named key-name-hint
and not key-path-hint after all) and raise an error if the property
contains a path so that the build fails and not quietly.
Fixes: 133c000ca334 ("binman: implement signing FIT images during image build") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org>
Andrew Goodbody [Mon, 30 Jun 2025 10:23:39 +0000 (11:23 +0100)]
cmd: tpm: Fix attempt to return value not in enum
The function tpm2_name_to_algorithm is defined as returning an
enum for the algorithm specified but it also attempts to return
an error on failure, but that error is not included in the enum.
Add the error to the enum so that it can be returned.
Giulio Benetti [Sat, 28 Jun 2025 22:19:44 +0000 (00:19 +0200)]
arch/arm/include/asm/arch-imxrt/gpio.h: imxrt gpio use common gpio.h
The current file defines a struct gpio_regs identical to the one in
<asm/mach-imx/gpio.h>. To eliminate code duplication and align with
the approach used for i.MX8M, include the common header instead of
redefining the struct.
Lukasz Majewski [Fri, 27 Jun 2025 05:49:43 +0000 (07:49 +0200)]
arm: pinctrl: Define .mux_mask field for NXP's SoC
The commit e8a9521e649f
("vf500/vf610: synchronise device trees with linux")
has synchronized U-Boot's DTS with v5.19 Linux kernel.
It turned out that in Linux's upstream iomuxc node description the
'fsl,mux_mask' was missing, so the U-Boot's pinctrl driver for NXP's
Vybrid SoC was not working properly.
As by default the mux mask was set to 0, for example the vf610 based
boards (like BK4) were bricked, due to misconfiguration of gpio at
early boot stage.
The fix for all NXP eligible boards is to define .mux_mask field for
soc specific *pinctrl_soc_info structure and use it directly in pinctrl
MMIO driver, without the need to read the "fsl,mux_mask" property from
device tree.
This change brings the NXP's pinctrl driver in U-Boot closer to Linux
upstream one.
Signed-off-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Peng Fan <peng.fan@nxp.com> #for i.MX8ULP
The commit c69103218ee4 ("i2c: mxc_i2c: add DM_FLAG_PRE_RELOC flag")
has enabled by default the i2c initialization in the pre-relocation
phase.
It turned out that vf610 based boards had too small SYS_MALLOC_F_LEN
pool size.
As a solution the explicit value of CONFIG_SYS_MALLOC_F_LEN for all
vf610 based boards has been removed from their configs.
Instead, the default value of 0x2000 is now used, which causes boards
to work correctly again. This approach has been tested on BK4 device.
Peng Fan [Mon, 23 Jun 2025 07:02:33 +0000 (15:02 +0800)]
imx8mq: evk: Add support for capsule update
Capsule update is EFI based firmware update which is widely
used in various OS distributions. This feature is required
by ARM System-Ready compliance test. So
- Define image array and GUID
- Select configs for EFI Capsule update
Peng Fan [Mon, 23 Jun 2025 07:02:32 +0000 (15:02 +0800)]
imx93: evk: Add support for capsule update
Capsule update is EFI based firmware update which is widely
used in various OS distributions. This feature is required
by ARM System-Ready compliance test. So
- Define image array and GUID
- Select configs for EFI Capsule update
Peng Fan [Mon, 23 Jun 2025 07:02:31 +0000 (15:02 +0800)]
imx8mn: evk: Add support for capsule update
Capsule update is EFI based firmware update which is widely
used in various OS distributions. This feature is required
by ARM System-Ready compliance test. So
- Define image array and GUID
- Select configs for EFI Capsule update
Peng Fan [Mon, 23 Jun 2025 07:02:30 +0000 (15:02 +0800)]
imx8mm: evk: Add support for capsule update
Capsule update is EFI based firmware update which is widely
used in various OS distributions. This feature is required
by ARM System-Ready compliance test. So
- Define image array and GUID
- Select configs for EFI Capsule update
Peng Fan [Mon, 23 Jun 2025 07:02:29 +0000 (15:02 +0800)]
imx8mp: evk: Add support for capsule update
Capsule update is EFI based firmware update which is widely
used in various OS distributions. This feature is required
by ARM System-Ready compliance test. So
- Define image array and GUID
- Select configs for EFI Capsule update
Fiona Klute [Mon, 23 Jun 2025 11:38:01 +0000 (13:38 +0200)]
doc: mention that extlinux.conf can use environment in "append"
This option is very useful for A/B boot setups with read-only
filesystems: Letting U-Boot fill in the rootfs (and possibly related
parameters) allows keeping all boot parameters except the actual slot
selection in the extlinux.conf file, where they can be updated easily.
Signed-off-by: Fiona Klute <fiona.klute@gmx.de> Cc: Tom Rini <trini@konsulko.com>
Tom Rini [Fri, 27 Jun 2025 19:07:17 +0000 (13:07 -0600)]
Revert the last two mach-k3 changes
This reverts both commit 4628730ee6c4 ("mach-k3: add runtime memory
carveouts for MMU table") as well as commit b77066d73261 ("mach-k3: add
dynamic mmu fixups for SPL stage") as some feedback from previous
iterations was missed.
Instructions that lead ito an exception in the hypervisor can't modify two
CPU registers at once for the ARM ISA.
These instructions cannot be emulated by KVM as they do not produce
syndrome information data that KVM can use to infer the destination
register, the faulting address, whether it was a load or store, or
if it's a 32 or 64 bit general-purpose register.
As a result an external abort is injected from QEMU, via ext_dabt_pending.
Ilias Apalodimas [Wed, 18 Jun 2025 06:58:14 +0000 (09:58 +0300)]
qemu: arm: Enable virtualizable IO accessors
We recently added IO accessors that will work with KVM for any MMIO
access that casues an exception to the hypervisor. Enable them by
default for QEMU.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Ilias Apalodimas [Wed, 18 Jun 2025 06:58:13 +0000 (09:58 +0300)]
arm: io.h: Fix io accessors for KVM
commit 2e2c2a5e72a8 ("arm: qemu: override flash accessors to use virtualizable instructions")
explains why we can't have instructions with multiple output registers
when running under QEMU + KVM and the instruction leads to an exception
to the hypervisor.
USB XHCI is such a case (MMIO) where a ldr w1, [x0], #4 is emitted for
xhci_start() which works fine with QEMU but crashes for QEMU + KVM.
These instructions cannot be emulated by KVM as they do not produce
syndrome information data that KVM can use to infer the destination
register, the faulting address, whether it was a load or store, or
if it's a 32 or 64 bit general-purpose register.
As a result an external abort is injected from QEMU, via ext_dabt_pending
to KVM and we end up throwing an exception that looks like
There are two problems making this the default.
- It will emit ldr + add or str + add instead of ldr/str(post increment)
in somne cases
- Some platforms that depend on TPL/SPL grow in size enough so that the
binary doesn't fit anymore.
So let's add proper I/O accessors add a Kconfig option
to turn it off by default apart from our QEMU builds.
Reported-by: Mikko Rapeli <mikko.rapeli@linaro.org> Tested-by: Mikko Rapeli <mikko.rapeli@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tom Rini [Fri, 20 Jun 2025 16:25:02 +0000 (10:25 -0600)]
tools: rmboard.py: Fix conversion from run_pipe to new helper
When this utility was converted from run_pipe and to the new output
helper, two problems were introduced. First, the conversion for calling
"git rm -f" wasn't correct. Change this to match the other conversions.
Second, the final call we do we need to construct the list because we
print that command for the user to use to inspect remaining references.
Fixes: 3d094ce28a22 ("u_boot_pylib: Add a function to run a single command") Signed-off-by: Tom Rini <trini@konsulko.com>
Newer versions of python will emit a TypeError about not enough
arguments for a format string:
FAILED ub/test/py/tests/test_mmc.py::test_mmc_dev - TypeError: not enough arguments for format string
FAILED ub/test/py/tests/test_mmc.py::test_mmcinfo - TypeError: not enough arguments for format string
FAILED ub/test/py/tests/test_mmc.py::test_mmc_info - TypeError: not enough arguments for format string
FAILED ub/test/py/tests/test_mmc.py::test_mmc_rescan - TypeError: not enough arguments for format string
FAILED ub/test/py/tests/test_mmc.py::test_mmc_part - TypeError: not enough arguments for format string
Add parentheses around all multi argument format strings so all
arguments will be passed to the format string
Signed-off-by: Bryan Brattlof <bb@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Anshul Dalal [Wed, 18 Jun 2025 12:42:09 +0000 (18:12 +0530)]
mach-k3: add dynamic mmu fixups for SPL stage
On platforms with spl splash support i.e CONFIG_VIDEO=y, the top of DDR
is reserved for the framebuffer.
The size for the framebuffer is computed at runtime by video_reserve.
During the MMU configuration an entry corresponding to the framebuffer
should be dynamically created to properly map the required space for the
framebuffer.
Therefore this patch adds k3_spl_mem_map_init which adds the required
MMU entry by querying the gd after the framebuffer size has been
computed in spl_reserve_video_from_ram_top.
For non VIDEO=y platforms, the added k3_spl_mem_map_init function gets
optimized out of the final binary so overall, the spl size is not
impacted[1].
Anshul Dalal [Wed, 18 Jun 2025 12:42:08 +0000 (18:12 +0530)]
mach-k3: add runtime memory carveouts for MMU table
In u-boot we only provide a single MMU table for all k3 platforms,
this does not scale for devices with reserved memory outside the range
0x9e780000 - 0xa0000000 or for devices with < 2GiB of memory (eg
am62-SIP with 512MiB of RAM).
To properly configure the MMU on various k3 platforms, the
reserved-memory regions need to be queried at runtime from the
device-tree and the MMU table should be updated accordingly.
This patch adds the required fixups to the MMU table (during proper
U-boot stage) by marking the reserved regions as non cacheable and
keeping the remaining area as cacheable.
For the A-core SPL, the 128MiB region starting from SPL_TEXT_BASE
is marked as cacheable i.e 0x80080000 to 0x88080000.
The 128MiB size is chosen to allow for future use cases such as falcon
boot from the A-Core SPL which would require loading kernel image from
the SPL stage. This change also ensures the reserved memory regions that
all exist past 0x88080000 are non cacheable preventing speculative
accesses to those addresses.
Tom Rini [Fri, 27 Jun 2025 14:32:29 +0000 (08:32 -0600)]
Merge patch series "drivers: pci: pcie_dw_common: Add dw_pcie_link_set_max_link_width()"
This patch set from Marek Vasut <marek.vasut+renesas@mailbox.org>
introduces dw_pcie_link_set_max_link_width() similar to the Linux Kernel
and then migrates the current platform drivers to use it. Next it adds
support for Renesas R-Car Gen4 platforms and enables it on one.
Add R-Car Gen4 PCIe controller support for host mode.
This controller is based on Synopsys DesignWare PCIe. However, this
particular controller has a number of vendor-specific registers, and as
such, requires initialization code, including PHY firmware loading.
The PHY firmware loading is implemented in an entirely generic manner,
by calling a firmware loading script, which the user can configure in
a way they require. This provides the user with flexibility of loading
the PCIe firmware from whichever storage device they need to load it
from.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Tue, 17 Jun 2025 08:16:30 +0000 (10:16 +0200)]
pci: pcie_dw_rockchip: Use dw_pcie_link_set_max_link_width()
Use dw_pcie_link_set_max_link_width() instead of local implementation
of the same functionality. This does change the behavior slightly, as
the dw_pcie_link_set_max_link_width() implementation also programs the
LNKCAP register MLW, this should however be correct and is now aligned
with Linux kernel behavior.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Tue, 17 Jun 2025 08:16:28 +0000 (10:16 +0200)]
pci: pcie_dw_meson: Use dw_pcie_link_set_max_link_width()
Use dw_pcie_link_set_max_link_width() instead of local implementation
of the same functionality. This does change the behavior slightly, as
the dw_pcie_link_set_max_link_width() implementation also programs the
LNKCAP register MLW, this should however be correct and is now aligned
with Linux kernel behavior.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Add dw_pcie_link_set_max_link_width() implementation ported from Linux kernel
as of commit 89db0793c9f2 ("PCI: dwc: Add missing PCI_EXP_LNKCAP_MLW handling").
This is common code which is already duplicated in multiple drivers.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tom Rini [Thu, 26 Jun 2025 23:16:49 +0000 (17:16 -0600)]
Merge patch series "Add TI K3 PCIe Endpoint Controller support for AM64X"
Hrushikesh Salunke <h-salunke@ti.com> says:
This series adds support for the Endpoint mode on Cadence PCIe controller
on TI's K3 family of SoCs. The driver is an adaptation of the Linux
driver (drivers/pci/controller/cadence/pci-j721e.c) and has been
implemented specifically for Endpoint mode of operation on AM64X. A minor
set of changes will be sufficient to support other K3 SoCs as well.
This patch is tested on AM64X EVM. Following are the log corresponding
to this feature.
configs: am64x_evm_a53_defconfig: Enable configs for PCI Endpoint mode
TI's AM64x SoC has a single instance of PCIe Controller namely PCIe0
which is a Cadence PCIe Controller. To support PCI Endpoint
functionality with the PCIe0 instance of PCIe, enable the corresponding
configs.
pci_endpoint: Add TI K3 Cadence PCIe Endpoint Controller driver
Add support for Endpoint mode of operation in the Cadence PCIe
Controller present on TI's K3 SoCs. This driver is an adaptation of the
Linux kernel v6.15 driver (drivers/pci/controller/cadence/pci-j721e.c).
Anshul Dalal [Mon, 16 Jun 2025 08:04:30 +0000 (13:34 +0530)]
arm: Kconfig: enable LTO for ARCH_K3
CONFIG_LTO enables Link Time Optimizations that helps in reducing binary
size. The config has been validated on all K3 platforms so can be safely
enabled.
phy: cadence: torrent: add support for three or more links using 2 protocols
This is a port of the corresponding commit in the Linux kernel which
adds the same support for the Cadence Torrent driver[0]. The commit
message below is taken as-is from the Linux kernel commit being ported.
The Torrent SERDES can support at most two different protocols (PHY types).
This only mandates that the device-tree sub-nodes used to represent the
configuration should describe links with at-most two different protocols.
The existing implementation however imposes an artificial constraint that
allows only two links (device-tree sub-nodes). As long as at-most two
protocols are chosen, using more than two links to describe them in an
alternating configuration is still a valid configuration of the Torrent
SERDES.
A 3-Link 2-Protocol configuration of the 4-Lane SERDES can be:
Lane 0 => Protocol 1 => Link 1
Lane 1 => Protocol 1 => Link 1
Lane 2 => Protocol 2 => Link 2
Lane 3 => Protocol 1 => Link 3
A 4-Link 2-Protocol configuration of the 4-Lane SERDES can be:
Lane 0 => Protocol 1 => Link 1
Lane 1 => Protocol 2 => Link 2
Lane 2 => Protocol 1 => Link 3
Lane 3 => Protocol 2 => Link 4
牛 志宏 [Fri, 13 Jun 2025 01:45:28 +0000 (01:45 +0000)]
bootm: Pass SMP core ID and DTB address for ELF-formatted kernels
When booting RISC-V ELF-formatted kernel images (IH_TYPE_KERNEL + IH_OS_ELF),
explicitly pass SMP hart ID (via a0/argc) and DTB address (via a1/argv)
to comply with modern SMP-enabled kernels' boot protocol requirements.
See https://www.kernel.org/doc/html/latest/arch/riscv/boot.html#register-state
Tom Rini [Thu, 26 Jun 2025 19:45:43 +0000 (13:45 -0600)]
Merge patch series "sandbox: align LMB memory"
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> says:
To implement the EFI_SYSTEM_TABLE_POINTER we need 4 MiB aligned
memory.
On the sandbox LMB uses addresses relative to the start of a page aligned
RAM buffer allocated with mmap(). This leads to a mismatch of alignment
between EFI which uses pointers and LMB which uses phys_addr_t.
Ensure that the RAM buffer used for LMB is 4 MiB aligned.
Provide a unit test for efi_alloc_aligned_pages() verifying this alignment.
To implement the EFI_SYSTEM_TABLE_POINTER we need 4 MiB aligned
memory.
On the sandbox LMB uses addresses relative to the start of a page aligned
RAM buffer allocated with mmap(). This leads to a mismatch of alignment
between EFI which uses pointers and LMB which uses phys_addr_t.
Ensure that the RAM buffer used for LMB is 4 MiB aligned.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
projects / thirdparty / u-boot.git / log
