Re: [PATCH 1/1] x86 support for the initrd= command line option

[hpa]

On March 19, 2020 4:49:05 PM PDT, ron minnich <rminnich@xxxxxxxxx> wrote:
>In LinuxBoot systems, a kernel and initramfs are loaded into FLASH
>to replace proprietary firmware/BIOS code. Space being at a premium
>on some systems, the kernel and initramfs must be place in whatever
>open corners of the FLASH exist. These corners are not always
>easily used.
>
>For example, on Intel-based UEFI systems, the Management Engine
>(ME) is given half the FLASH, though it uses very little, as little
>as 1.25MiB.  Not only is 2.75MiB of an 8MiB part unused; but
>10.75MiB of a 16MiB part is unused. This space can be recovered by
>a number of tools, e.g. utk and its tighten_me command, and if
>Linux can be told where the space is Linux can load an initrd from
>it.
>
>In an ideal case, we would take the space from the ME and add it to
>a FLASH-based filesystem.  While UEFI does have filesystem-like
>structures, this recovered space can only be added to its "file
>system" by rebuilding UEFI from source or writing a UEFI device
>driver. Both these options are impractical in most cases. The space
>can only be referenced as a physical address.
>
>There is code in the core that allows specification of the initrd
>as a physical address and size, but it is not supported on all
>architectures. This patch adds support for initrd= to the x86.
>
>For debugging and recovery purposes, if initrd= is present in the
>command line, other existing initrd sources should still have
>higher priority. The initramfs in flash might be damaged or
>broken. Hence, it must still be possible to load a kernel and
>initramfs with a conventional bootloader, or even load the
>FLASH-based kernel with a different initramfs; or boot a
>kernel and let it use the initrd in FLASH.
>
>In support of that priority ordering, this patch sets the ramdisk
>image pointer to phys_initrd_start only if it is not already set;
>and sets ramdisk_size to phys_initrd_size only if it is not already
>set.
>
>It has been tested extensively in LinuxBoot environments.
>
>Signed-off-by: Ronald G. Minnich <rminnich@xxxxxxxxx>
>---
> arch/x86/kernel/setup.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
>diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>index a74262c71484..1b04ef8ea12d 100644
>--- a/arch/x86/kernel/setup.c
>+++ b/arch/x86/kernel/setup.c
>@@ -237,6 +237,9 @@ static u64 __init get_ramdisk_image(void)
>
>     ramdisk_image |= (u64)boot_params.ext_ramdisk_image << 32;
>
>+    if (ramdisk_image == 0) {
>+        ramdisk_image = phys_initrd_start;
>+    }
>     return ramdisk_image;
> }
> static u64 __init get_ramdisk_size(void)
>@@ -245,6 +248,9 @@ static u64 __init get_ramdisk_size(void)
>
>     ramdisk_size |= (u64)boot_params.ext_ramdisk_size << 32;
>
>+    if (ramdisk_size == 0) {
>+        ramdisk_size = phys_initrd_size;
>+    }
>     return ramdisk_size;
> }

The initrd= option is reserved namespace for the bootloader. It is also worth noting that the x86 boot protocol now allows the bootloader to point to arbitrary chunks of memory for the initrd.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.