[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <F4664C3D-B6A0-4559-BEFB-59098190904D@zytor.com>
Date: Wed, 25 Mar 2020 10:21:39 -0700
From: hpa@...or.com
To: ron minnich <rminnich@...il.com>,
Randy Dunlap <rdunlap@...radead.org>
CC: Matthew Garrett <mjg59@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"maintainer:X86 ARCHITECTURE..." <x86@...nel.org>,
lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] x86 support for the initrd= command line option
On March 24, 2020 9:19:01 AM PDT, ron minnich <rminnich@...il.com> wrote:
>Subject: [PATCH 1/1] initrdmem= option to specify initrd physical
>address
>
>This patch adds the initrdmem option:
>initrdmem=ss[KMG],nn[KMG]
>which is used to specify the physical address of the initrd,
>almost always an address in FLASH. It also adds code for
>x86 to use the existing phys_init_start and
>phys_init_size variables in the kernel.
>This is useful in cases where we wish to place a kernel
>and initrd in FLASH, but there is no firmware file
>system structure in the FLASH.
>
>One such situation occurs when we have reclaimed unused FLASH
>space on UEFI systems by, e.g., taking it from the Management
>Engine. For example, on many systems, the ME is given half the
>FLASH part; not only is 2.75M of an 8M part unused; but 10.75M
>of a 16M part is unused. We can use this space to contain
>an initrd, but need to tell Linux where it is.
>
>This space is "raw": due to, e.g., UEFI limitations:
>it can not be added to UEFI firmware volumes without rebuilding
>UEFI from source or writing a UEFI device driver. We can reference it
>only as a physical address and size.
>
>At the same time, should we netboot a kernel or load it from
>GRUB or syslinux, we want to have the option of not using
>the physical address specification. Then, should we wish, it
>is easy to boot the kernel and provide an initrd; or boot the
>the kernel and let it use the initrd in FLASH. In practice this
>has proven to be very helpful as we integrate Linux into FLASH
>on x86.
>
>Hence, the most flexible and convenient path is to enable the
>initrdmem command line flag in a way that it is the last choice tried.
>
>For example, on the DigitalLoggers Atomic Pi, we burn an image into
>FLASH with a built-in command line which includes:
>initrdmem=0xff968000,0x200000
>which specifies a location and size.
>
>Signed-off-by: Ronald G. Minnich <rminnich@...il.com>
>---
> Documentation/admin-guide/kernel-parameters.txt | 7 +++++++
> arch/x86/kernel/setup.c | 6 ++++++
> init/do_mounts_initrd.c | 13 ++++++++++++-
> 3 files changed, 25 insertions(+), 1 deletion(-)
>
>diff --git a/Documentation/admin-guide/kernel-parameters.txt
>b/Documentation/admin-guide/kernel-parameters.txt
>index c07815d230bc..9cd356958a7f 100644
>--- a/Documentation/admin-guide/kernel-parameters.txt
>+++ b/Documentation/admin-guide/kernel-parameters.txt
>@@ -1714,6 +1714,13 @@
>
> initrd= [BOOT] Specify the location of the initial ramdisk
>
>+ initrdmem= [KNL] Specify a physical adddress and size from
>which
>+ to load the initrd. If an initrd is compiled in or
>+ specified in the bootparams, it takes priority
>+ over this setting.
>+ Format: ss[KMG],nn[KMG]
>+ Default is 0, 0
>+
>init_on_alloc= [MM] Fill newly allocated pages and heap objects with
> zeroes.
> Format: 0 | 1
>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;
> }
>
>diff --git a/init/do_mounts_initrd.c b/init/do_mounts_initrd.c
>index dab8b1151b56..d72beda824aa 100644
>--- a/init/do_mounts_initrd.c
>+++ b/init/do_mounts_initrd.c
>@@ -28,7 +28,7 @@ static int __init no_initrd(char *str)
>
> __setup("noinitrd", no_initrd);
>
>-static int __init early_initrd(char *p)
>+static int __init early_initrdmem(char *p)
> {
> phys_addr_t start;
> unsigned long size;
>@@ -43,6 +43,17 @@ static int __init early_initrd(char *p)
> }
> return 0;
> }
>+early_param("initrdmem", early_initrdmem);
>+
>+/*
>+ * This is here as the initrd keyword has been in use since 11/2018
>+ * on ARM, PowerPC, and MIPS.
>+ * It should not be; it is reserved for bootloaders.
>+ */
>+static int __init early_initrd(char *p)
>+{
>+ return early_initrdmem(p);
>+}
> early_param("initrd", early_initrd);
>
>static int init_linuxrc(struct subprocess_info *info, struct cred *new)
Reviewed-by: H. Peter Anvin (Intel) <hpa@...or.com>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Powered by blists - more mailing lists