Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp830775ybb; Wed, 25 Mar 2020 10:23:53 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvIIMTxp3ZpF2uJl2o67u176+aG8metr4IAEJDL6fbwkKus3I2T7845VR6jun2No9OKFPNU X-Received: by 2002:a05:6830:1d1:: with SMTP id r17mr3325915ota.81.1585157033822; Wed, 25 Mar 2020 10:23:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585157033; cv=none; d=google.com; s=arc-20160816; b=YfWbgkkLk6/G8HvuUg+hfqo5/+9Uaz5RmUDPscyuyG8BfoyYtU6zf3YwNeERsX0mLb nyb0c4tNBgQpLiTkBWsXJyD3ZjcUJOek/DPLwG5ok3MqR08+krARx2NMbZGDlxY8gMR8 Hpruj/YFMCCF2tDzbvHNwXmqcNliDzVRDV/5aYc+YzqaKm5yIiyIYrxwgV1vqCKSLIs0 WpEHlrOYLl5EF8pvttU0fbE82Ldtx7SIg7qNpudqL3DBP9ekbznmVVXW2T2R6+AhPeFV cAi+8y8f2V2OOEFxjHe4H1NDWLeCpTGH4++01CRrfEeVSpTIVArj0f3dvU6pRyDDyyp8 GIMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:from:cc:to:subject :content-transfer-encoding:mime-version:references:in-reply-to :user-agent:date:dkim-signature:dkim-filter; bh=hNa8evV5Hu1zOs/UUGiqrSieOily/K/LQaClIZEAxmc=; b=esqM/hmEEhKCw+D1+3Liezv2o3A0kyyxAMgm03reITuF/n4+g+jto6o4RikXGDb0BP 2TZSUwbQZ9NVRpSUzAsW2YL4v5uP2Tgr22rMV/xN7NBN8ynUljS1NwfQrv1HIWmmhZwo AK42mK2tmhIcwQ6I2DskRW7XIEQmi+F6Ct9o111AtcRaDWJ4T3ykaT+0i1OotIeSDPok oIKyVWkwlHeJczbA/RiNmJDjYEGnsWR2WhbNCmyA2rqSYEdM+viEdFxEeowumnD2uluV AEyUj3PWYk0kW4Mnm9s5AUeJwWME0TQPNBbwVu7itKTvwfk3lMpCPZj49h9D+3PVagVw nA7w== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@zytor.com header.s=2020032201 header.b=AsmavEhC; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=zytor.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c6si6929083oto.178.2020.03.25.10.23.39; Wed, 25 Mar 2020 10:23:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@zytor.com header.s=2020032201 header.b=AsmavEhC; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=zytor.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727653AbgCYRXK (ORCPT + 99 others); Wed, 25 Mar 2020 13:23:10 -0400 Received: from terminus.zytor.com ([198.137.202.136]:41563 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727236AbgCYRXK (ORCPT ); Wed, 25 Mar 2020 13:23:10 -0400 Received: from [IPv6:2601:646:8600:3281:c898:2a71:8b3c:1618] ([IPv6:2601:646:8600:3281:c898:2a71:8b3c:1618]) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id 02PHLjgI3526476 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 25 Mar 2020 10:21:46 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 02PHLjgI3526476 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2020032201; t=1585156906; bh=hNa8evV5Hu1zOs/UUGiqrSieOily/K/LQaClIZEAxmc=; h=Date:In-Reply-To:References:Subject:To:CC:From:From; b=AsmavEhCc1MFkyU0nBp1sVNYnVxuijnL/E5P61pz6a+Pa6hrtKVg54sNCJBe7RoX9 CWtebAS/xDHrfxUFzQUGWphTWVZgT4FSTu8bTkJKqg8kfJYu72IZz3HJ8x9fzCrIwf SP2PvNTMj4+NIi8nhpOTmCwc8pqNJfYLS8f5E2mJEr2oPEoDkOqCbHZilmIUoFnfP3 0fmfd6lah2QwXcrUbrWZwJmEoz5IItpE4umtgf1wR9/73SoPfDFUOM5AA9NYaXHZgq XxI76OYxuel3r2Oeyn6HRMr9mjNcZXLeII/fC3ry5y5ayujkiyj7B53wEileAVuoey Pofp5dLQKUqXg== Date: Wed, 25 Mar 2020 10:21:39 -0700 User-Agent: K-9 Mail for Android In-Reply-To: References: <8E80838A-7A3F-4600-AF58-923EDA3DE91D@zytor.com> <2837291a-b682-bd6d-4e08-ffa76d3097b0@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH 1/1] x86 support for the initrd= command line option To: ron minnich , Randy Dunlap CC: Matthew Garrett , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "maintainer:X86 ARCHITECTURE..." , lkml - Kernel Mailing List From: hpa@zytor.com Message-ID: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On March 24, 2020 9:19:01 AM PDT, ron minnich wrote: >Subject: [PATCH 1/1] initrdmem=3D option to specify initrd physical >address > >This patch adds the initrdmem option: >initrdmem=3Dss[KMG],nn[KMG] >which is used to specify the physical address of the initrd, >almost always an address in FLASH=2E It also adds code for >x86 to use the existing phys_init_start and >phys_init_size variables in the kernel=2E >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=2E > >One such situation occurs when we have reclaimed unused FLASH >space on UEFI systems by, e=2Eg=2E, taking it from the Management >Engine=2E For example, on many systems, the ME is given half the >FLASH part; not only is 2=2E75M of an 8M part unused; but 10=2E75M >of a 16M part is unused=2E We can use this space to contain >an initrd, but need to tell Linux where it is=2E > >This space is "raw": due to, e=2Eg=2E, UEFI limitations: >it can not be added to UEFI firmware volumes without rebuilding >UEFI from source or writing a UEFI device driver=2E We can reference it >only as a physical address and size=2E > >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=2E 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=2E In practice this >has proven to be very helpful as we integrate Linux into FLASH >on x86=2E > >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=2E > >For example, on the DigitalLoggers Atomic Pi, we burn an image into >FLASH with a built-in command line which includes: >initrdmem=3D0xff968000,0x200000 >which specifies a location and size=2E > >Signed-off-by: Ronald G=2E Minnich >--- > Documentation/admin-guide/kernel-parameters=2Etxt | 7 +++++++ > arch/x86/kernel/setup=2Ec | 6 ++++++ > init/do_mounts_initrd=2Ec | 13 ++++++++++++- > 3 files changed, 25 insertions(+), 1 deletion(-) > >diff --git a/Documentation/admin-guide/kernel-parameters=2Etxt >b/Documentation/admin-guide/kernel-parameters=2Etxt >index c07815d230bc=2E=2E9cd356958a7f 100644 >--- a/Documentation/admin-guide/kernel-parameters=2Etxt >+++ b/Documentation/admin-guide/kernel-parameters=2Etxt >@@ -1714,6 +1714,13 @@ > > initrd=3D [BOOT] Specify the location of the initial ramdisk > >+ initrdmem=3D [KNL] Specify a physical adddress and size from >which >+ to load the initrd=2E If an initrd is compiled in or >+ specified in the bootparams, it takes priority >+ over this setting=2E >+ Format: ss[KMG],nn[KMG] >+ Default is 0, 0 >+ >init_on_alloc=3D [MM] Fill newly allocated pages and heap objects with > zeroes=2E > Format: 0 | 1 >diff --git a/arch/x86/kernel/setup=2Ec b/arch/x86/kernel/setup=2Ec >index a74262c71484=2E=2E1b04ef8ea12d 100644 >--- a/arch/x86/kernel/setup=2Ec >+++ b/arch/x86/kernel/setup=2Ec >@@ -237,6 +237,9 @@ static u64 __init get_ramdisk_image(void) > > ramdisk_image |=3D (u64)boot_params=2Eext_ramdisk_image << 32; > >+ if (ramdisk_image =3D=3D 0) { >+ ramdisk_image =3D 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 |=3D (u64)boot_params=2Eext_ramdisk_size << 32; > >+ if (ramdisk_size =3D=3D 0) { >+ ramdisk_size =3D phys_initrd_size; >+ } > return ramdisk_size; > } > >diff --git a/init/do_mounts_initrd=2Ec b/init/do_mounts_initrd=2Ec >index dab8b1151b56=2E=2Ed72beda824aa 100644 >--- a/init/do_mounts_initrd=2Ec >+++ b/init/do_mounts_initrd=2Ec >@@ -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=2E >+ * It should not be; it is reserved for bootloaders=2E >+ */ >+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=2E Peter Anvin (Intel) --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E