Tom Rini [Mon, 7 Apr 2025 22:40:02 +0000 (16:40 -0600)]
Merge branch 'next'
Note that this undoes the changes of commit cf6d4535cc4c ("x86:
emulation: Disable bloblist for now") as that was intended only for the
release due to time.
It has been reported that memory corruption can occurred because network
packages where received after EXIT_BOOT_SERVICES. See the thread
starting at [1].
We try to remove all drivers when EXIT_BOOT_SERVICES is called. But
* Some network drivers don't call their own stop method when removed.
* Some network drivers don't have a remove method.
* Some devices have CONFIG_DM_DEVICE_REMOVE=n.
Let's call eth_halt() in EXIT_BOOT_SERVICES explicitly.
Cc: Michael Brown <mcb30@ipxe.org> Reported-by: Christian Kohlschütter <christian@kohlschutter.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Michael Brown <mcb30@ipxe.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Christian Kohlschütter <christian@kohlschutter.com>
A recent change tried to speed up EFI booting by not calling dhcp_run
from eth_bootdev_hunt() every time. PXE so far relied on that dhcp_run
call to get an IP address.
Fix that by adding a dhcp_run call to the pxe bootflow, with autoload
disabled to only get the ip address and nothing else.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Fixes: 1f68057e0320 ("net: eth_bootdev_hunt() should not run DHCP") Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Raymond Mao [Fri, 4 Apr 2025 14:05:25 +0000 (07:05 -0700)]
mbedtls: remove incorrect attribute type checker
S/MIME Capabilities (OID: 1.2.840.113549.1.9.15) attributes are
expected to be algorithms but neither data nor MS Inderect Data,
thus the checker for data type is incorrect.
This patch fixes a capsule authentication failure with PKCS#7
message that contains S/MIME capabilities, which formed by the EDK2
GenerateCapsule tool.
S/MIME Capabilities are not common attributes in an EFI capsule,
thus this failure cannot be reproduced with the capsules generated
via mkeficapsule.
Fixes: 7de0d155cce7 ("mbedtls: add PKCS7 parser porting layer") Reported-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Tom Rini [Fri, 4 Apr 2025 16:36:17 +0000 (10:36 -0600)]
x86: emulation: Disable bloblist for now
As reported by Niklas Sombert, enabling bloblist on these platforms
means that we currently don't pass SMBIOS tables on to later stages. For
the v2025.04 release, disable bloblists as that is sufficient to restore
functionality and we will address the underlying problem for the next
release.
Include spl.h to avoid definition errors in custom builds.
Fixes: commit bc07851897bd ("board: ti: Pull redundant DDR functions to a common location and Fixup DDR size when ECC is enabled") Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Andrew Davis [Wed, 19 Mar 2025 18:54:58 +0000 (13:54 -0500)]
arm: mach-k3: j721e: Split out J7200 SoC support from J721e
Currently in j721e_init.c we check which firewalls to remove using
the board configuration (e.g CONFIG_TARGET_J721E_R5_EVM). We do this
as J721e and J7200 have different IP and firewalls but use the same
SoC definition (SOC_K3_J721E) even though they are different SoCs.
The idea was they would be similar enough that they both could use
the same SoC config to help with common code sharing. Board checks
would then be used differentiate.
This has grown far too messy to maintain any more, especially now
that there is more than one board using J721e (EVM, SK, Beagle AI64).
As differentiation is done based on board, every one of these boards
would have to have checks added for them. Instead let's split J7200
support out from J721e like how normal new SoC support is done.
This patch touches several subsystems and could not be split much better
as when we add SOC_K3_J7200 we want to make use of it in all spots that
once used the combined SOC_K3_J721E so we can turn off SOC_K3_J721E when
building for J7200 boards.
Tom Rini [Fri, 4 Apr 2025 18:26:50 +0000 (12:26 -0600)]
Merge patch series "64-bit U-Boot configuration without SPL"
Jeremy Compostella <jeremy.compostella@intel.com> says:
Introduces a new configuration option X86_RUN_64BIT_NO_SPL to allow
building U-Boot as a 64-bit binary without using the SPL (Secondary
Program Loader). The motivation is to simplify the boot process for
specific x86-based platforms that do not require SPL, such as those
booting directly from a 64-bit coreboot firmware.
configs: Add coreboot64-no-spl_defconfig for 64-bit X86 without SPL
Create a new defconfig file called `coreboot64-no-spl_defconfig`,
tailored specifically for 64-bit X86 architecture systems that operate
without the Secondary Program Loader (SPL). This configuration takes its
inspiration from `coreboot64_defconfig`..
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Correct the preprocessor directive used to check for 64-bit kernel
support in the `zboot_go` function. The code previously checked for
`CONFIG_X86_RUN_64BIT`, which is not the correct configuration option
for determining if the kernel should run in 64-bit mode. The correct
option is `CONFIG_X86_64`.
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org>
arch/x86: Add 64-bit U-Boot configuration without SPL
This commit introduces a new configuration option X86_RUN_64BIT_NO_SPL
to allow building U-Boot as a 64-bit binary without using the SPL
(Secondary Program Loader). The motivation is to simplify the boot
process for certain x86-based platforms that do not require SPL, such as
those booting directly from a 64-bit coreboot firmware.
This update revises the `X86_RUN_64BIT` configuration to more accurately
describe its role as "32-bit SPL followed by 64-bit U-Boot." It
clarifies the sequence of operations during the boot process, where the
system transitions from a 32-bit SPL (Secondary Program Loader) to the
main 64-bit U-Boot.
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Fri, 4 Apr 2025 18:25:11 +0000 (12:25 -0600)]
Merge patch series "cmd: fuse: Introduce fuse writebuff sub-system and clean up"
Harsha Vardhan V M <h-vm@ti.com> says:
This patch series introduces the fuse writebuff sub-system command and
makes improvements to the existing fuse implementation by removing the
custom string functions. The patches are required to be applied in
sequence.
The series consists of the following changes:
Patch 1 removes custom string functions and replaces them with standard
string functions.
Patch 2 introduces fuse.rst documentation for fuse commands.
Patch 3 introduces the fuse writebuff sub-system command, allowing to
write a structured buffer in memory to fuses, and implementing the
necessary function calls.
Patch 4 enables the fuse sub-system in the K3 platform.
Patch 5 updates the fuse.rst documentation to include details about the
new fuse writebuff command.
These changes aim to improve the fuse sub-system by the removal of
custom string functions and the addition of the fuse writebuff
command improves fuse programming workflows by allowing to write a
structured buffer in memory to efuses.
Add CMD_FUSE_WRITEBUFF config option to add and enable fuse writebuff
sub-system command. Add fuse_writebuff function to be invoked on
writebuff command.
Signed-off-by: Harsha Vardhan V M <h-vm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Ilias Apalodimas [Wed, 19 Mar 2025 07:22:02 +0000 (09:22 +0200)]
arm64: Fix page permissions for platforms running at EL2
We currently set both and print both PXN and UXN bits when removing
execution for pages. This happens even in the existing per platform
definitions of 'struct mm_region'.
That's not entirely correct though. For stage-1 translations, if a
platform runs on a translation regime with a single privilege level or the
the translation regime supports two privilege levels and we are not
in EL1&0 with HCR_EL2.{NV, NV1} = {1, 1} only BIT54 (XN) is needed
and BIT53(PXN) is reserved 0.
Currently we support Non-Secure EL2, Non-secure EL2&0 and Non-secure
EL1&0.
We already have get_effective_el() which returns 1 if we are
- Running in EL1 so we assume an EL1 translation regime but without
checking HCR_EL2.{NV, NV1} != {1,1}
- Running in EL2 with HCR_EL2.E2H = 1
The only problem with the above is that if we are in EL1&0 and
HCR_EL2.{NV1, NV} == {1, 1}, then
- Bit[54] holds the PXN instead of the UXN
- The Effective value of UXN is 0
- Bit[53] is RES0
So let's re-use that function and set PXN only when we are in
and EL[2|1]&0 translation regime.
Tom Rini [Thu, 3 Apr 2025 17:43:38 +0000 (11:43 -0600)]
Merge patch series "x86: Improve operation under QEMU"
Simon Glass <sjg@chromium.org> says:
U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it
is not perfect.
With both builds, executing the VESA ROM causes an intermittent hang, at
least on some AMD CPUs.
With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit)
is done in a way that works on real hardware but not with QEMU. This
means that performance is 4-5x slower than it could be, at least on my
CPU.
We can work around the first problem by using Bochs, which is anyway a
better choice than VESA for QEMU. The second can be addressed by using
the same descriptor across the jump to long mode.
With an MTRR fix this allows booting into Ubuntu on qemu-x86_64
In v3 some e820 patches are included to make booting reliable and avoid
ACPI tables being dropped. Also, several MTTR problems are addressed, to
support memory sizes above 4GB reliably.
Simon Glass [Sat, 15 Mar 2025 14:26:05 +0000 (14:26 +0000)]
acpi: Support checking checksums
When the ACPI tables come from an earlier bootloader it is helpful to
see whether the checksums are correct or not. Add a -c flag to the
'acpi list' command to support that.
Simon Glass [Sat, 15 Mar 2025 14:25:58 +0000 (14:25 +0000)]
boot: Consider non-bootable partitions
Any 'bootable' flag in a DOS partition causes boostd to only scan
bootable partitions for that media. This can mean that extlinux.conf
files on the root disk are missed.
Put this logic behind a flag and update the documentation.
For now, the flag is enabled, to preserve the existing behaviour of
bootstd which is to ignore non-bootable partitions so long as there is
at least one bootable partition on the disk. Future work may provide a
command (or some other mechanism) to control this.
Simon Glass [Sat, 15 Mar 2025 14:25:55 +0000 (14:25 +0000)]
x86: emulation: Support BLOBLIST_TABLES properly
The existing QEMU implementation mostly ignored BLOBLIST_TABLES and
allocates the bulk of the tables with malloc(). Update it to place all
tables in the bloblist. Since QEMU declares a size of 128KB regardless
of the size of its tables, this requires a larger bloblist.
Fix up the e820 table to handle this, keeping the old code as an option
for now, to assist with any future bug-fixing.
Simon Glass [Sat, 15 Mar 2025 14:25:51 +0000 (14:25 +0000)]
test/py: Allow tests to be filtered by role
Some test can only be run by a particular board in a lab, e.g. because
they are loaded with an OS image used by the test. Add a way to specify
this in tests.
Simon Glass [Sat, 15 Mar 2025 14:25:50 +0000 (14:25 +0000)]
test/py: Add a helper to send characters
The existing run_command() method is not great for sending things other
than U-Boot commands. Add a helper for sending arbitrary strings as well
as control characters.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Sat, 15 Mar 2025 14:25:46 +0000 (14:25 +0000)]
x86: Allow adding non-aligned size for MTRR
At present mtrr_add_request() requires that the size is a power of two.
This is too limiting for machines with 4GB (or more) of RAM, since they
often must take account of a memory hole at 3GB.
Update the function to automatically deal with an unaligned size, using
more MTRRs as required.
The algorithm is taken from coreboot commit 60bce10750
Simon Glass [Sat, 15 Mar 2025 14:25:42 +0000 (14:25 +0000)]
x86: Add functions to convert between mtrr size and mask
Rather than repeating the same code in several places, add some
functions which can do the conversion.
Use the cpu_phys_address_size() function to obtain the physical-address
size, since it is more reliable with kvm, where the host CPU may have a
different value from the emulation CPU.
Simon Glass [Sat, 15 Mar 2025 14:25:38 +0000 (14:25 +0000)]
x86: Use the same GDT when jumping to long mode
Make use the existing GDT which now includes entries for 64-bit code.
Leave the interrupt descriptors alone. They can be tidied up once U-Boot
starts up.
With this, kvm mode works with QEMU.
Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/31
Simon Glass [Sat, 15 Mar 2025 14:25:31 +0000 (14:25 +0000)]
x86: Add 64-bit entries to the GDT
At present it is not possible to execution 64-bit code without
installing an entire new Global Descriptor Table. This is inconvenient
since kvm does not seem to like switching into long mode with a new
table.
It isn't actually necessary, since we can just extend the existing
table. Add some new entries to this effect.
Simon Glass [Sat, 15 Mar 2025 14:25:24 +0000 (14:25 +0000)]
x86: qemu: Switch to bochs display
The vesa display is widely used on hardware, but it is a bit of a pain
with QEMU. It requires executing option ROMs, which either doesn't work
with kvm, or is difficult to do in a kvm/QEMU-friendly way.
THe bochs display is probably better anyway, so switch to that. It works
fine with kvm as it doesn't need an option ROM.
Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/31
Patrick Rudolph [Sun, 16 Mar 2025 08:32:52 +0000 (09:32 +0100)]
acpi_table: Fix IORT RC node
Even though the RC node has the correct size and the ID mappings
are written to the end of the node, the ID 'mapping offset' and
'mapping count' are not written in the IORT RC node header, thus it
looks like that the RC node has no ID mappings.
The Linux kernel doesn't complain about the invalid IORT RC node,
even though the spec says that each RC node must have an ID mapping.
The kernel will fail to use MSI IRQs and fall back to a legacy IRQ
mechanism that's not working either.
Finally it will show strange behaviour around PCI interrupts, making it
hard to trace back to an invalid IORT RC nodes.
Add the missing ID mapping count and mapping offset.
TEST: Fixes IRQ usage of PCI devices on qemu/sbsa-ref. Fixes: bf5d37662da5 "acpi: acpi_table: Add IORT support" Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tom Rini [Thu, 3 Apr 2025 17:37:57 +0000 (11:37 -0600)]
Merge patch series "Introduce J742S2 SoC and EVM"
Manorit Chawdhry <m-chawdhry@ti.com> says:
The series adds support for J742S2 family of SoCs. Also adds J742S2 EVM
Support and re-uses most of the stuff from the superset device J784s4.
This device is a subset of J784S4 and shares the same memory map and
thus the code is being reused from J784S4 to avoid duplication.
It initially cleans up the J784s4 and AM69 files so that they can be
re-usable for j742s2 and then it introduces J742S2.
The DT for the following SoC will be coming to U-boot during 6.13 Sync
so the series is kept as RFC till then.
Here are some of the salient features of the J742S2 automotive grade
application processor:
The J742S2 SoC belongs to the K3 Multicore SoC architecture platform,
providing advanced system integration in automotive, ADAS and industrial
applications requiring AI at the network edge. This SoC extends the K3
Jacinto 7 family of SoCs with focus on raising performance and
integration while providing interfaces, memory architecture and compute
performance for multi-sensor, high concurrency applications.
Some changes that this devices has from J784S4 are:
* 4x Cortex-A72 vs 8x Cortex-A72
* 3x C7x DSP vs 4x C7x DSP
* 4 port ethernet switch vs 8 port ethernet switch
* 2 DDR controller vs 4 DDR controller
arm: dts: k3-j784s4-binman.dtsi: Clean up and templatize boot binaries
Clean up templatized boot binaries for j784s4 soc. This includes
modifying the k3-j784s4-binman.dtsi to use SPL_BOARD_DTB,
BOARD_DESCRIPTION and UBOOT_BOARD_DESCRIPTION from the files that
include it to further reuse code.
k3-j784s4-binman.dtsi will contain only templates. Only required boot
binaries can be built from the templates in the boards' respective
-u-boot.dtsi file (or k3-<board>-binman.dtsi if it exists). This allows
clear distinction between the SoC common stuff vs. what is additionally
needed to boot up a specific board.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
[ Do it only for j784s4 ] Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
tools: binman: control.py: Delete template nodes after parsing
Dynamically going through the subnode array and deleting leads to
templates being skipped from deletion when templates are consecutive in
the subnode list. Prevent this from happening by first parsing the DT
and then deleting the nodes. Add a testcase as well for this cornercase.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
projects / thirdparty / u-boot.git / log
