| Age | Commit message (Collapse) | Author |
|---|
|
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 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.
This reverts commit b77066d73261855af406422fbbe28a5d527f4dbf and commit
4628730ee6c40864dbe475e4ca91e47a92f371fe.
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 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
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>
|
|
This board is currently unmaintained. Remove it.
Acked-by: Angelo Dureghello <angelo@kernel-space.org>
Signed-off-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: 3d094ce28a22 ("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: b511b371ad76 ("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>
|
|
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.
Link: https://lore.kernel.org/r/20250617081641.8385-1-marek.vasut+renesas@mailbox.org
|
|
Sparrow Hawk board
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.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.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>
|
|
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> says:
The sandbox is used for a lot of generic development, we should run the
UEFI tests there, too.
The TPM emulation on the sandbox is incomplete. Disable the TCG test on
sandbox.
Link: https://lore.kernel.org/r/20250617061945.9266-1-heinrich.schuchardt@canonical.com
|
|
The sandbox is used for a lot of generic development, we should run the
UEFI tests there, too.
Reported-by: Javier Martinez Canillas <javierm@redhat.com>
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>
|
|
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>
|
|
Udit Kumar <u-kumar1@ti.com> says:
Many boards based upon K3 ARCH overrides default malloc size to 32MB,
as part of cleanup, add default size of 32MB for K3 ARCH.
Link: https://lore.kernel.org/r/20250614093717.2479920-1-u-kumar1@ti.com
|
|
This is same as done in commit 27cd65ca1bf1 ("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>
|
|
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
[0] https://github.com/torvalds/linux/commit/5b7b83a9839be643410c31d56f17c2d430245813
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
|
|
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
Signed-off-by: Zone.N <zone.niuzh@hotmail.com>
|
|
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.
Do not overwrite RAM size in dram_init().
Link: https://lore.kernel.org/r/20250608075428.32631-1-heinrich.schuchardt@canonical.com
|
|
Provide unit tests for efi_alloc_aligned_pages() and
efi_allocate_pages().
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
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>
|
|
dram_init() must not overwrite the value of gd->ram_buf set by
setup_ram_buf() for main U-Boot or board_init_f() for SPL.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
Background:
I have several customers that will be using a certain remote signing
service for signing their images, in order that the private keys are
never exposed outside that company's secure servers. This is done via
a pkcs#11 interface that talks to the remote signing server, and all
of that works quite well.
However, the way this particular signing service works is that one
must upfront create a "signing session", where one indicates which
keys one will use and, importantly, how many times each key will (may)
be used. Then, depending on the keys requested and the customer's
configuration, one or more humans must authorize that signing session
So for example, if official release keys are to be used, maybe two
different people from upper management must authorize, while if
development keys are requested, the developer himself can authorize
the session.
Once authorized, the requester receives a token that must then be used
for signing via one of the keys associated to that session.
I have that integrated in Yocto in a way that when a CI starts a BSP
build, it automatically works out which keys will be needed (e.g. one
for signing U-Boot, another for signing a kernel FIT image) based on
bitbake metadata, requests an appropriate signing session, and the
appropriate people are then notified and can then look at the details
of that CI pipeline and confirm that it is legitimate.
The problem:
The way mkimage does FIT image signing means that the remote server
can be asked to perform a signature an unbounded number of times, or
at least a number of times that cannot be determined upfront. This
means that currently, I need to artificially say that a kernel key
will be used, say, 10 times, even when only a single FIT image with
just one configuration node is created.
Part of the security model is that once the number of signings using a
given key has been depleted, the authorization token becomes useless
even if somehow leaked from the CI - and _if_ it is leaked/compromised
and abused before the CI has gotten around to do its signings, the
build will then fail with a clear indication of the
compromise. Clearly, having to specify a "high enough" expected use
count is counter to that part of the security model, because it will
inevitably leave some allowed uses behind.
While not perfect, we can give a reasonable estimate of an upper bound
on the necessary extra size by simply counting the number of hash and
signature nodes in the FIT image.
As indicated in the comments, one could probably make it even more
precise, and if there would ever be signatures larger than 512 bytes,
probably one would have to do that. But this works well enough in
practice for now, and is in fact an improvement in the normal case:
Currently, starting with size_inc of 0 is guaranteed to fail, so we
always enter the loop at least twice, even when not doing any signing
but merely filling hash values.
Just in case I've missed anything, keep the loop incrementing 1024
bytes at a time, and also, in case the estimate turns out to be over
64K, ensure that we do at least one attempt by changing to a do-while
loop.
With a little debug printf, creating a FIT image with three
configuration nodes previously resulted in
Trying size_inc=0
Trying size_inc=1024
Trying size_inc=2048
Trying size_inc=3072
Succeeded at size_inc=3072
and dumping info from the signing session (where I've artifically
asked for 10 uses of the kernel key) shows
"keyid": "kernel-dev-20250218",
"usagecount": 9,
"maxusagecount": 10
corresponding to 1+2+3+3 signatures requested (so while the loop count
is roughly linear in the number of config nodes, the number of
signings is quadratic).
With this, I instead get
Trying size_inc=3456
Succeeded at size_inc=3456
and the expected
"keyid": "kernel-dev-20250218",
"usagecount": 3,
"maxusagecount": 10
thus allowing me to set maxusagecount correctly.
Update a binman test case accordingly: With the previous behaviour,
mkimage would try size_inc=0 and then size_inc=1024 and then
succeed. With this patch, we first try, and succeed, with 4*128=512
due to the four hash nodes (and no signature nodes) in 161_fit.dts, so
the image ends up 512 bytes smaller.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
|
|
supernodes"
Moteen Shah <m-shah@ti.com> says:
In the U-Boot pre-relocation stage, if the parent node lacks
bootph-all/bootph-some-ram property and the driver lacks a pre-reloc
flag, all of its subsequent subnodes gets skipped over from driver
binding—even if they have a bootph* property.
This series addresses the issue by scanning through all the nodes during
build time and propagating the applicable property to all of its supernode.
Link: https://lore.kernel.org/r/20250516114148.3862114-1-m-shah@ti.com
|
|
Add a testcase to ensure that scan_and_prop_bootph() actually
propagates bootph-* properties to supernodes.
Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
to supernodes
As per bootph schema, bootph-* property in child node should be
implied in their parent, but this feature is not implemented in
the U-Boot proper stage (before relocation) resulting in devices
not being bound because of the missing bootph-all or bootph-some-ram
property in the parent node.
To mitigate this issue, add a function to scan through all the nodes
in the device-tree for bootph-all and bootph-some-ram properties. If
found, propagate it to all of its parent nodes up the hierarchy.
Signed-off-by: Moteen Shah <m-shah@ti.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
Yannic Moog <y.moog@phytec.de> says:
This series solves a contradiction regarding ext blobs packaged in
binman. When they are marked as optional, by default they are faked, two
messages are emitted. One says the image is not functional the other
says the image is still functional. Both concern the same binman
entry/blob.
Binman is set up to have fake external blobs in case they are missing.
This is regardless on whether they are optional or not.
The implementation does not allow different types of entries to override
the faking decision; at least there wouldn't be much sense in doing so.
Here is an example build output of a phycore-imx8mp:
BINMAN .binman_stamp
Image 'image' is missing optional external blobs but is still functional: tee-os
/binman/section/fit/images/tee/tee-os (tee.bin):
See the documentation for your board. You may need to build Open Portable
Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin
Image 'image' has faked optional external blobs and is still functional: tee.bin
OFCHK .config
The output stays to inform/warn the user, but in this case the tee-os
entry will not be present in the final image.
Link: https://lore.kernel.org/r/20250613-binman_faked_optional-v3-0-1e23dd7c41a2@phytec.de
|
|
When external blobs are marked optional, they should not cause a
build to fail. Extend the test cases for FitTeeOsOptional and
ExtblobOptional.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
Some test cases don't use _DoTestFile directly which accepts
allow_fake_blobs. However, they specifically test functionality that
requires external blobs not to be faked. Extend the _DoReadFileDtb
signature to allow passing that option to _DoTestFile.
Also fix tests that require non-faked ext blobs.
By default, external blobs are faked. Some tests care only about more
basic functionality. In those cases no external blobs should be faked.
That would trigger a different (binman) case which is not in scope for
those particular tests.
Thus, disable faked blobs for those test cases.
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
When having an entry that is marked as optional and is missing in the
final image, the following output is observed:
CFGS spl/u-boot-spl.cfgout
BINMAN .binman_stamp
Image 'image' has faked external blobs and is non-functional: tee.bin
Image 'image' is missing optional external blobs but is still functional: tee-os
/binman/section/fit/images/tee/tee-os (tee.bin):
See the documentation for your board. You may need to build Open Portable
Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin
Some images are invalid
make: *** [Makefile:1135: .binman_stamp] Error 103
To solve this contradictory messaging, when checking the faked blob
list, remove entries that are allowed to be missing. Instead add an
info message for faked optional blobs. Also reduce verbosity of the
optional image warning to an info message.
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
When blobs are absent and are marked as optional, they can be safely
dropped from the binman tree. Use the drop_absent function for that.
Rename drop_absent to drop_absent_optional as we do not want to drop any
entries that are absent; they should be reported by binman as errors
when they are missing.
We also reorder the processing of the image the following:
- We call the CheckForProblems function before the image is built.
- We drop entries after we checked for problems with the image.
This is okay because CheckForProblems does not look at the file we have
written but rather queries the data structure (image) built with binman.
This also allows us to get all error and warning messages that we want
to report while avoiding putting missing optional entries in the final
image.
As only the blobs are dropped, the sections still remain in the
assembled image. Thus add them to the expected test case checks where
necessary.
In addition, a rework of testPackTeeOsOptional test case is necessary.
The test did not really do what it was supposed to. The description said
that optional binary is tested, but the binary is not marked as
optional. Further, the tee.elf file, when included in the image
properly, also shows up in the image data. This must be added as well.
As there is no global variable for the elf data, set the pathname to the
elf file that was created when setting up the test suite.
For the test case get the filename and read the contents, comparing them
to the contents of the created binman image.
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
