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: 133c000ca3 ("binman: implement signing FIT images during image build")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
This option doesn't work as expected since it sets the cwd to the work
directory, which does not necessarily hold the source code.
It should be left unset, so that the current directory is the source
directory.
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
This issue was reported by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
The commit e8a9521e64
("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 c69103218e ("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.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
In the contemporary U-Boot the "spi-flash" compatible is used only when
CONFIG_$(PHASE_)SPI_FLASH_TINY is defined so spi-nor-tiny.c is compiled.
As vf610 devices are not using SPL at all, the SPI_FLASH_TINY is not
defined and no QSPI flash child nodes are considered as valid ones.
The result is that the 'sf probe' command fails and SPI NOR memory is not
accessible on e.g. BK4 device.
The fix is to use proper compatible - in this case "jedec,spi-nor".
Signed-off-by: Lukasz Majewski <lukma@denx.de>
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
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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
Signed-off-by: Peng Fan <peng.fan@nxp.com>
This variable might end up being uninitialized if we exit early.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
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>
This reverts both commit 4628730ee6 ("mach-k3: add runtime memory
carveouts for MMU table") as well as commit b77066d732 ("mach-k3: add
dynamic mmu fixups for SPL stage") as some feedback from previous
iterations was missed.
This reverts commit b77066d732 and commit
4628730ee6.
Signed-off-by: Tom Rini <trini@konsulko.com>
Ilias Apalodimas <ilias.apalodimas@linaro.org> says:
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.
Link: https://lore.kernel.org/r/20250618065828.1312146-1-ilias.apalodimas@linaro.org
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>
commit 2e2c2a5e72 ("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
U-Boot 2025.07-rc4 (Jun 10 2025 - 12:00:15 +0000)
[...]
Register 8001040 NbrPorts 8
Starting the controller
"Synchronous Abort" handler, esr 0x96000010, far 0x10100040
elr: 000000000005b1c8 lr : 000000000005b1ac (reloc)
elr: 00000000476fc1c8 lr : 00000000476fc1ac
x0 : 0000000010100040 x1 : 0000000000000001
x2 : 0000000000000000 x3 : 0000000000003e80
x4 : 0000000000000000 x5 : 00000000477a5694
x6 : 0000000000000038 x7 : 000000004666f360
x8 : 0000000000000000 x9 : 00000000ffffffd8
x10: 000000000000000d x11: 0000000000000006
x12: 0000000046560a78 x13: 0000000046560dd0
x14: 00000000ffffffff x15: 000000004666eed2
x16: 00000000476ee2f0 x17: 0000000000000000
x18: 0000000046660dd0 x19: 000000004666f480
x20: 0000000000000000 x21: 0000000010100040
x22: 0000000010100000 x23: 0000000000000000
x24: 0000000000000000 x25: 0000000000000000
x26: 0000000000000000 x27: 0000000000000000
x28: 0000000000000000 x29: 000000004666f360
Code: d5033fbf aa1503e0 5287d003 52800002 (b8004401)
Resetting CPU ...
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>
A following patch is replacing our IO accessors with
do { ... } while(0) ones in order to make them usable with KVM.
That leads to an error eventually looking like this:
arch/arm/include/asm/io.h:62:9: error: expected expression before 'do'
62 | do { \
| ^~
arch/arm/include/asm/io.h:211:41: note: in expansion of macro '__raw_writel'
211 | #define out_arch(type,endian,a,v) __raw_write##type(cpu_to_##endian(v),a)
| ^~~~~~~~~~~
arch/arm/include/asm/io.h:223:25: note: in expansion of macro 'out_arch'
223 | #define out_be32(a,v) out_arch(l,be32,a,v)
| ^~~~~~~~
drivers/spi/fsl_dspi.c:127:17: note: in expansion of macro 'out_be32'
127 | out_be32(addr, val) : out_le32(addr, val);
| ^~~~~~~~
So adjust the current macros and code to be compatible with the upcoming
change.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
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: 3d094ce28a ("u_boot_pylib: Add a function to run a single command")
Signed-off-by: Tom Rini <trini@konsulko.com>
Per section 14.2.1.3 Kick Protection Registers of AM62A TRM[1],
there is no partition 5. Delete it.
[1] https://www.ti.com/lit/pdf/spruj16
Fixes: b511b371ad ("arm: mach-k3: introduce basic files to support the am62a")
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.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>
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].
[1]: Tested on clang 19.1.7 and gcc 15.1.1
Signed-off-by: Anshul Dalal <anshuld@ti.com>
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.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Enable support for R-Car Gen4 PCIe controller and NVMe storage
on Retronix R-Car V4H Sparrow Hawk board .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
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>
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>
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>
The TPM emulation on the sandbox is incomplete.
Even basic tcg2 functionality like get_capability() fails:
lib/efi_selftest/efi_selftest_tcg2.c(886):
ERROR: get_manufacturer_id buffer too small failed
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
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.
https://gist.github.com/hrushikesh221/e8557cbe7667877c50f7d7e9bb96d060
Link: https://lore.kernel.org/r/20250616164929.631791-1-h-salunke@ti.com
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.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
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).
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
This is same as done in commit 27cd65ca1b ("mach-k3: am62ax: enable
caches for the SPL stage").
This is resulting in ~2x speedup in the A53 SPL stage.
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Use default value of malloc size coming from Kconfig, instead of
board specific override.
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Many boards of K3 overwrites default malloc size, instead
of doing at almost each board level,
Add default size at Kconfig.
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
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.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
