On Ubuntu 25.04 installing the dependency pyyaml 6.0 fails with
License classifiers are deprecated
Update PyYAML to the current release.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.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: 1f68057e03 ("net: eth_bootdev_hunt() should not run DHCP")
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
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: 7de0d155cc ("mbedtls: add PKCS7 parser porting layer")
Reported-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Include spl.h to avoid definition errors in custom builds.
Fixes: commit bc07851897 ("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>
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.
Signed-off-by: Andrew Davis <afd@ti.com>
The file k3-am62a7.dtsi is part of upstream DT and should
have been removed when migrating to OF_UPSTREAM but must
have been missed. Do this here.
Signed-off-by: Andrew Davis <afd@ti.com>
MUX_MMIO is required in SPL stage in order to boot hyperflash
successfully. Add configs to enable MUX_MMIO in SPL stage.
Signed-off-by: Anurag Dutta <a-dutta@ti.com>
MUX_MMIO is required in SPL stage in order to boot hyperflash
successfully. Add configs to enable MUX_MMIO in SPL stage.
Signed-off-by: Anurag Dutta <a-dutta@ti.com>
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.
Link: https://lore.kernel.org/r/87bjtyutkp.fsf@jcompost-mobl.amr.corp.intel.com
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>
This change aligns the preprocessor directive with the standard
configuration flag used for detecting 64-bit x86 architecture.
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>
As both CONFIG_X86_RUN_64BIT and X86_RUN_64BIT_NO_SPL cases run U-Boot
in 64-bit mode with the CPU fully initialized already.
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
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.
Link: https://lore.kernel.org/r/20250319084714.335777-1-h-vm@ti.com
Add K3_FUSE config option to add and enable fuse sub-system
implementation function calls.
Signed-off-by: Harsha Vardhan V M <h-vm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
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>
Add documentation for the 'fuse' sub-system commands in
doc/usage/cmd/fuse.rst file.
Remove doc/README.fuse file.
Signed-off-by: Harsha Vardhan V M <h-vm@ti.com>
Remove custom string functions and replace them with normal string
functions. Remove the custom strtou32 and replace it with
simple_strtoul.
Signed-off-by: Harsha Vardhan V M <h-vm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
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.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Simon Glass <sjg@chromium.org> says:
The membuff implementation curently has no tests. It also assumes that
head and tail can never correspond unless the buffer is empty.
This series provides a compile-time flag to support a 'full' flag. It
also adds some tests of the main routines.
The data structure is also renamed to membuf which fits better with
U-Boot.
There may be some cases in the code which could be optimised a little,
but the implementation is functional.
Link: https://lore.kernel.org/r/20250318152059.1464369-1-sjg@chromium.org
Show the start in end in the comment. Comment a missing variable in
membuf_readline() and fix its line length.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rename the C and header files to use the membuf basename, to match the
functions.
Add a MAINTAINERS entry while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
The double 'f' is not necessary and is a bit annoying as elsewhere in
U-Boot we use 'buf'. Rename all the functions before it is used more
widely.
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Link: https://lore.kernel.org/all/20250315142643.2600605-1-sjg@chromium.org/
Now that U-Boot can boot this quickly, using kvm, add a test that the
installer starts up correctly.
Use the qemu-x86_64 board in the SJG lab.
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
Free the memory used in tests to avoid a leak. Also unmap the addresses
for sandbox.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This table lacks a correct checksum at present, so fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The values in the FADT are pointers so should not go through sandbox's
normal addr<->pointer mapping. Fix this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a condition for sandbox, to match that of x86, to avoid the warning
"FADT not ACPI-hardware-reduced-compliant".
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the string to take account of UARTs which are connected on I/O
ports, as on x86.
Fix a typo in an error message in the same command, while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
If only a single label is provided in the list, bootdev_next_label()
does not operate correctly and reads beyond the end of the pointer list.
Fix this by adding a new check. Also add a note to convert this array
to an alist
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the size of this struct is too large on 64-bit machines.
Annotate it with __packed to fix this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add some missing pieces to bootparams so that a 64-bit ramdisk address
can be used. Tidy up the logging while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
The existing mechanism is pretty painful as it requires manual
calculations for anything but a trivial setup.
Add a new API for adding e820 entries.
Signed-off-by: Simon Glass <sjg@chromium.org>
Heinrich SchuchardtandTom Rini
Heiko StuebnerandTom Rini
Raymond MaoandTom Rini
Neha Malcom FrancisandTom Rini
Andrew DavisandTom Rini
Anurag DuttaandTom Rini
Jeremy CompostellaandTom Rini
Harsha Vardhan V MandTom Rini
Ilias ApalodimasandTom Rini
Neil Armstrong
Simon GlassandTom Rini