| Age | Commit message (Collapse) | Author |
|---|
|
The Linux kernel can discover SMBIOS tables through two primary methods:
1. Via EFI tables, when using EFI boot;
2. Via the 'smbios3-entrypoint' property in the /chosen node of the
device tree.
When U-Boot boots a Linux kernel using a non-EFI command ("bootm",
"bootz", or "booti"), the kernel relies on the device tree to detect
the hardware. If SMBIOS tables are available in U-Boot, they should
be passed to the kernel via this device tree property.
This patch modifies boot_fdt_prepare(), to inject the SMBIOSv3 table
address into the device tree if there is a table generated by U-boot.
The "board_fdt_chosen_smbios" is weak in order to leave the possibilty
for specific boards to select custom SMBIOS addresses.
The changes in this patch are added in the context of supporting this
device tree property in linux kernel:
https://lkml.org/lkml/2025/10/24/1393
Device tree schema was updated to include the "smbios3-entrypoint" node
in pull request: https://github.com/devicetree-org/dt-schema/pull/177
Signed-off-by: Adriana Nicolae <[email protected]>
|
|
This reverts commit 9fe2e4b46458f9c4ec6b8115ebf18b4b26fe6127.
Commit 9fe2e4b46458 ("fdt: Make sure there is no stale initrd left")
introduces a regression in case when U-Boot transfers control to an EFI
app which acts as a subsequent bootloading program. Such an app might
try to set "linux,initrd-start" and "linux,initrd-end" fdt properties,
but by that time those properties are already removed by the code added
in the mentioned commit.
Particularly, the issue was observed on the E850-96 board where GBL EFI
app [1] can't run Android successfully anymore. More specifically, the
kernel can't see the ramdisk and panics with next messages:
/dev/root: Can't open blockdev
VFS: Cannot open root device "" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; ...
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
fdt_initrd() function (where initrd dts properties are removed) is
called two times:
1. First it's called by EFI boot manager (e.g. as a part of U-Boot
Standard Boot mechanism) when it's installing FDT:
fdt_initrd
image_setup_libfdt
efi_install_fdt
efi_bootmgr_run
efi_mgr_boot
It's already enough for EFI app to malfunction. But then it's also
called second time:
2. From the EFI app, via EFI DT fixup protocol:
fdt_initrd
image_setup_libfdt
efi_dt_fixup
struct efi_dt_fixup_protocol efi_dt_fixup_prot = {
.fixup = efi_dt_fixup
};
See [2] for specific GBL code which sets those fdt properties and then
runs DT fixup protocol callback.
This issue was discussed [3], but no action was taken since then. Revert
this patch for now, until a proper solution can be found.
[1] https://source.android.com/docs/core/architecture/bootloader/generic-bootloader/gbl-dev
[2] https://android.googlesource.com/platform/bootable/libbootloader/+/refs/heads/gbl-mainline/gbl/libgbl/src/android_boot/mod.rs#208
[3] https://lists.denx.de/pipermail/u-boot/2025-July/593879.html
Fixes: 9fe2e4b46458 ("fdt: Make sure there is no stale initrd left")
Signed-off-by: Sam Protsenko <[email protected]>
|
|
Although if we don't setup an initrd, there could be a stale initrd
setting from the previous boot firmware in the live device tree. So,
make sure there is no setting left if we don't want an initrd.
This can happen when booting on a Raspberry Pi. The boot firmware can
happily load an initrd before us and configuring the addresses in the
live device tree we get handed over.
Especially the setting `auto_initramfs` in config.txt is dangerous.
When enabled (default), the firmware tries to be smart and looks for
initramfs files.
Signed-off-by: Richard Weinberger <[email protected]>
|
|
One of the problems an OS may face, when running in EFI, is that
a mounted ISO, after calling ExitBootServices goes away, if that ISO
is resident in RAM memory as a ramdisk.
ACPI has NFIT and NVDIMM support to provide ramdisks to the OS, but we
don't have anything in place for DTs. Linux and device trees have support
for persistent memory devices. So add a function that can inject a pmem
node in a DT, so we can pass information on the ramdisk the OS.
Signed-off-by: Masahisa Kojima <[email protected]>
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Sometimes, it is necessary to provide an additional bootargs string to
the kernel command line.
We have a real scenario where one U-Boot blob needs to boot several
kernel images: the vendor-patched kernel image and the latest upstream
kernel image. The Amlogic (Meson architecture) tty driver has different
tty suffixes in these kernels: the vendor uses 'ttySx', while the
upstream implementation uses 'ttyAMLx'. The initial console setup is
provided to the kernel using the kernel command line (bootargs). For the
vendor kernel, we should use 'console=ttyS0,115200', while for the
upstream kernel, it must be 'console=ttyAML0,115200'. This means we have
to use different command line strings depending on the kernel version.
To resolve this issue, we cannot use the CMDLINE_EXTEND kernel
configuration because it is considered legacy and is not supported for
the arm64 architecture. CMDLINE_EXTEND is outdated primarily because we
can provide additional command line strings through the
'chosen/bootargs' FDT node. However, U-Boot uses this node to inject the
U-Boot bootargs environment variable content, which results in U-Boot
silently overriding all data in the 'chosen/bootargs' node. While we do
have the board_fdt_chosen_bootargs() board hook to address such issues,
this function lacks any FDT context, such as the original value of the
'chosen/bootargs' node.
This patch introduces a read-only (RO) fdt_property argument to
board_fdt_chosen_bootargs() to share the original 'chosen/bootargs' data
with the board code. Consequently, the board developer can decide how to
handle this information for their board setup: whether to drop it or
merge it with the bootargs environment.
Signed-off-by: Dmitry Rokosov <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
It should be structured this way to demonstrate to the caller that
freeing the return value is unnecessary and that the caller cannot
modify it.
The function fdt_setprop() includes a parameter with a const char*
prototype, so it is better to use the const qualifier.
Signed-off-by: Dmitry Rokosov <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Tim Harvey <[email protected]> says:
This series will automatically add /chosen/kaslr-seed to the dt if
DM_RNG is enabled
during the boot process.
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
If we have DM_RNG enabled populate this value automatically when
fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT
is enabled as its implementation uses a different source of entropy
that is not yet implemented as DM_RNG. We also skip this if
MEASURED_BOOT is enabled as in that case any modifications to the
dt will cause measured boot to fail (although there are many other
places the dt is altered).
As this fdt node is added elsewhere create a library function and
use it to deduplicate code. We will provide a parameter to overwrite
the node if present.
For our automatic injection, we will use the first rng device and
not overwrite if already present with a non-zero value (which may
have been populated by an earlier boot stage). This way if a board
specific ft_board_setup() function wants to customize this behavior
it can call fdt_kaslrseed with a rng device index of its choosing and
set overwrite true.
Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
but left in place in case boot scripts exist that rely on this command
existing and returning success. An informational message is printed to
alert users of this command that it is likely no longer needed.
Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
randomization and completely ignores the kaslr-seed for its own
randomness needs (i.e the randomization of the physical placement of
the kernel). It gets weeded out from the DTB that gets handed over via
efi_install_fdt() as it would also mess up the measured boot DTB TPM
measurements as well.
|
|
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
If we have DM_RNG enabled populate this value automatically when
fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT
is enabled as its implementation uses a different source of entropy
that is not yet implemented as DM_RNG. We also skip this if
MEASURED_BOOT is enabled as in that case any modifications to the
dt will cause measured boot to fail (although there are many other
places the dt is altered).
Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
randomization and completely ignores the kaslr-seed for its own
randomness needs (i.e the randomization of the physical placement of
the kernel). It gets weeded out from the DTB that gets handed over via
efi_install_fdt() as it would also mess up the measured boot DTB TPM
measurements as well.
Signed-off-by: Tim Harvey <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Cc: Michal Simek <[email protected]>
Cc: Andy Yan <[email protected]>
Cc: Akash Gajjar <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Patrick Delaunay <[email protected]>
Cc: Patrice Chotard <[email protected]>
Cc: Devarsh Thakkar <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Hugo Villeneuve <[email protected]>
Cc: Marek Vasut <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Chris Morgan <[email protected]>
|
|
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
Add a fdt_kaslrseed function to accommodate this allowing an existing
node to be overwritten if present. For now use the first rng device
but it would be good to enhance this in the future to allow some sort
of selection or policy in choosing the rng device used.
Signed-off-by: Tim Harvey <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Cc: Michal Simek <[email protected]>
Cc: Andy Yan <[email protected]>
Cc: Akash Gajjar <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Patrick Delaunay <[email protected]>
Cc: Patrice Chotard <[email protected]>
Cc: Devarsh Thakkar <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Hugo Villeneuve <[email protected]>
Cc: Marek Vasut <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Chris Morgan <[email protected]>
Reviewed-by: Caleb Connolly <[email protected]>
|
|
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.
Reported-by: Jonas Karlman <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Remove <common.h> from all "boot/" files and when needed add
missing include files directly.
Signed-off-by: Tom Rini <[email protected]>
|
|
Create separate helper for just reserving framebuffer region without
creating or enabling simple-framebuffer node.
This is useful for scenarios where user want to preserve the bootloader
splash screen till OS boots up and display server gets started without
displaying anything else in between and thus not requiring
simple-framebuffer.
Signed-off-by: Devarsh Thakkar <[email protected]>
Reviewed-by: Nikhil M Jain <[email protected]>
|
|
When "memory" node is being processed in fdt_pack_reg() on ARM64
platforms, an unaligned bus access might happen, which leads to
"synchronous abort" CPU exception. Consider next dts example:
/ {
#address-cells = <2>;
#size-cells = <1>;
memory@80000000 {
device_type = "memory";
reg = <0x0 0x80000000 0x3ab00000>,
<0x0 0xc0000000 0x40000000>,
<0x8 0x80000000 0x80000000>;
};
};
After fdt_pack_reg() reads the first addr/size entry from such memory
node, the "p" pointer becomes 12 bytes shifted from its original value
(8 bytes for two address cells + 4 bytes for one size cell). So now it's
not 64-bit aligned, and an attempt to do 64-bit bus access to that
address will cause an abort like this:
"Synchronous Abort" handler, esr 0x96000021, far 0xba235efc
This issue was originally reported by David Virag [1] who observed it
happening on Samsung Exynos7885 SoC (ARM64), and later the same issue
was observed on Samsung Exynos850 (ARM64).
Fix the issue by using put_unaligned_be64() helper, which takes care of
possible unaligned 64-bit accesses. That solution was proposed by Simon
Glass in the original thread [1].
[1] https://lists.denx.de/pipermail/u-boot/2023-July/522074.html
Fixes: 739a01ed8e02 ("fdt_support: fix an endian bug of fdt_fixup_memory_banks")
Suggested-by: Simon Glass <[email protected]>
Reported-by: David Virag <[email protected]>
Closes: https://lists.denx.de/pipermail/u-boot/2023-July/522074.html
Signed-off-by: Sam Protsenko <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Add a bit more detail about what this function does.
Signed-off-by: Simon Glass <[email protected]>
|
|
Remove superfluous "did".
Signed-off-by: Hugo Villeneuve <[email protected]>
|
|
This relates to booting since it fixes up the devicetree for the OS. Move
it into the boot/ directory.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
