From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0077.outbound.protection.outlook.com [104.47.1.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 2DCCD21ECCB0C for ; Wed, 20 Sep 2017 10:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9xpbaTPMh1nFFsl6GpCae8OF0n1gCYg1e7A/yqzHWqc=; b=AID9R7zQZ3Uvl9KbMv8TJwsKoW0N9yS/wHmMEdpZbYiZZhO8oqMpM4oJ5Ua0wm1aM6CTUV8X4UpEn4+BmC1ICAX8DS6etPWDfNPB+Yf40x7VyMYhgWwmKsb65kCM7OWz7CKlPK6eRbpgsBhQi0mKoH+re7wPXMGyvYAdtQ6yJTY= Received: from AM6PR0402MB3334.eurprd04.prod.outlook.com (52.133.18.151) by AM6PR0402MB3669.eurprd04.prod.outlook.com (52.133.28.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 20 Sep 2017 17:34:42 +0000 Received: from AM6PR0402MB3334.eurprd04.prod.outlook.com ([fe80::4d05:6a0c:bcca:93be]) by AM6PR0402MB3334.eurprd04.prod.outlook.com ([fe80::4d05:6a0c:bcca:93be%13]) with mapi id 15.20.0056.018; Wed, 20 Sep 2017 17:34:42 +0000 From: Udit Kumar To: Pankaj Bansal , Andrew Fish , "Ard Biesheuvel" , "Olivier.Martin@arm.com" CC: Vladimir Olovyannikov , "edk2-devel@lists.01.org" Thread-Topic: [edk2] Storing Non volatile variables on SD/NAND Thread-Index: AdMwhGas4HV30Cb6RHux5gL+cq9qtgAEHTUAAAJm0wAAGXHS4AAYW1AAABfKRvAAAbCQAAAAEh/QAAD7vYAAE55LQAAD1row Date: Wed, 20 Sep 2017 17:34:42 +0000 Message-ID: References: <4CC33CC2-86D1-490E-A67E-12D751745121@apple.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=udit.kumar@nxp.com; x-originating-ip: [117.220.42.70] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR0402MB3669; 6:QYEsRZ+P9onuUMvOBr33kWcfIENofg6/t27YRpHYP+ng/iGPI0W6v3FBxkcVCPibp3toem4npceE9icE1t1cR3SMDSlnSCp80Cu5f1dCitOZOEMP8hoEd//Jxj19QEAlIT80qypfbNHDaCiI28VRES2UQrwHlVErkhG3NwnCZpLfXEMkqolq2MipspNCdVV1NMDH8BFHbQ1sSMi8PhvsheuQuOzPnaRRW1NlvSOlMJre2r66gnJqKQscDXd4m5KKt1tlykh4yVwAJLhBL4kJrKSquBOZ3wL8vEQcpXOaKYRHkuRz+QmVr2rJmDPZFxcjQd18K5I1LJefK06RoPwXOg==; 5:Te3+DYggVsTrrZD0fNtQNS57ZRJtmMzAq9o9J8inl7cQLUnrOfMuUbQZwbUp/zDMWBR/O/lItnodwP3abkFoTm5v0D8Ee4JHYqZPORQmam+5bwQtL16M0jfixDmd8R3hUjFBYwjelGCg8u/0r/q+5A==; 24:9PD8Bpyi+amjoAI0tkjo73IcVghqoeRW9TsKaYkLi2kBWmmujUwnRzMhviwOvopTnxpKy6jaW+MJf+XZNEPg24y4licEgx0IEB4Y3kvKehU=; 7:bqkETXBhNRNs0GzRGkjng9ijt9smXNkFF1NDU2G9weMLwgBkgNlwl3S8Ra2nwSQLeiWxb2xuhZaBt7O6cuwEPGZ7aXh/WiYcPLUWsjNZZLuPsIAsYyDuLu6xLcX8ag1TYqAy+9xZlbFSDjtI/asyKuFRqIfUldVGLWaGtgpgfDNXSDlKwhRMQnawJFYQkP/rF7p/w+c5fAm5sfsYOT4W/kKjPqpT8SHXMebqnlnTBCY= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(39860400002)(199003)(24454002)(13464003)(189002)(377454003)(81156014)(102836003)(8676002)(53936002)(189998001)(86362001)(3846002)(6116002)(8666007)(81166006)(53546010)(105586002)(9686003)(6306002)(106356001)(68736007)(2950100002)(2900100001)(6246003)(66066001)(6436002)(74316002)(2906002)(55016002)(8936002)(25786009)(229853002)(99286003)(54906003)(305945005)(7736002)(6506006)(7696004)(2501003)(316002)(966005)(93886005)(3280700002)(5660300001)(110136005)(97736004)(5250100002)(14454004)(478600001)(3660700001)(33656002)(50986999)(76176999)(101416001)(4326008)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR0402MB3669; H:AM6PR0402MB3334.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: d41e995e-c93b-4132-2dc9-08d5004de07c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM6PR0402MB3669; x-ms-traffictypediagnostic: AM6PR0402MB3669: x-exchange-antispam-report-test: UriScan:(80524489315369)(180628864354917)(192374486261705)(185117386973197)(162533806227266)(31960201722614); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM6PR0402MB3669; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM6PR0402MB3669; x-forefront-prvs: 04362AC73B received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2017 17:34:42.0415 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0402MB3669 Subject: Re: Storing Non volatile variables on SD/NAND X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 17:31:39 -0000 Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When we want to have UEFI and OS accessing same media ,=20 Possibilities I see=20 1- Patch OS For status check of media (diversion from generic OS), Good cas= e will be modify low level driver.=20 But we may end up some surprises on synchronization. =20 2- no runtime service for OS . I guess this will not be possible 3- Way the Vladimir implemented for eMMC, This has risk of losing data in = case of AC power off.=20 4- update hardware with dual view (Ard suggestion)=20 Thanks to add, if I missed some option here.=20 > This use case also arises for single-board systems like raspberry-pi, whi= ch do not > have an onboard flash. > The boot firmware/bootloader as well as operating system are loaded from = SD > card. > https://www.raspberrypi.org/documentation/configuration/config-txt/ Raspberry follow the different boot scheme. What I think, Linux running on= Raspberry/ARM is unware of UEFI boot.=20 Copied text=20 Stage 1 boot is in the on-chip ROM. Loads Stage 2 in the L2 cache Stage 2 is bootcode.bin. Enables SDRAM and loads Stage 3 Stage 3 is loader.bin. It knows about the .elf format and loads start.elf Stage 4: start.elf loads kernel.img. It then also reads config.txt, cmdline= .txt=20 and bcm2835.dtb If the dtb file exists, it is loaded at 0=D7100 & kernel @ = 0=D78000=20 If disable_commandline_tags is set it loads kernel @ 0=D70 Otherwise it loa= ds kernel @ 0=D78000 and put ATAGS at 0=D7100 Stage 5: kernel.img is then run on the ARM I think up to stage 4, we have GPU .=20 Here SD is exclusivity used by UEFI or OS. Any corrections ? =20 =20 Thanks Udit > -----Original Message----- > From: Pankaj Bansal > Sent: Wednesday, September 20, 2017 8:22 PM > To: Andrew Fish ; Udit Kumar ; edk2- > devel@lists.01.org > Cc: Vladimir Olovyannikov ; > Olivier.Martin@arm.com; Ard Biesheuvel > Subject: RE: [edk2] Storing Non volatile variables on SD/NAND >=20 > This use case also arises for single-board systems like raspberry-pi, whi= ch do not > have an onboard flash. > The boot firmware/bootloader as well as operating system are loaded from = SD > card. > https://www.raspberrypi.org/documentation/configuration/config-txt/ >=20 > Thanks & Regards, > Pankaj Bansal >=20 > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of > Andrew Fish > Sent: Wednesday, September 20, 2017 10:48 AM > To: Udit Kumar > Cc: edk2-devel@lists.01.org; Vladimir Olovyannikov > ; Olivier.Martin@arm.com; Ard > Biesheuvel > Subject: Re: [edk2] Storing Non volatile variables on SD/NAND >=20 >=20 > > On Sep 19, 2017, at 10:09 PM, Udit Kumar wrote: > > > >>> On Sep 19, 2017, at 9:27 PM, Udit Kumar wrote: > >>> > >>> > >>>> On 18 September 2017 at 22:28, Udit Kumar > wrote: > >>>>> Thanks Vladimir, > >>>>> With your design, you did delayed write to eMMC due to sharing > >>>>> with OS. But it works for you:) Say if eMMC controllers offers > >>>>> you a status bit, if eMMC storage is being used for not. Then this > >>>>> could be possible to > >>>> update at run time, both OS/UEFI needs to check and wait if > >>>> controller is being used. > >>>> > >>>> That is the problem right there. The nice thing about a firmware > >>>> spec is that you don't have to care about how it was implemented if > >>>> you adhere to > >> the API rules. > >>> > >>> Yup, we are fine as long as long UEFI firmware is stored on dedicated > media. > >>> > >>>> Imposing additional restrictions (such as requiring the OS to be > >>>> careful about not using the eMMC when it may be in use by the > >>>> firmware) defeats the purpose of using UEFI, since you won't be > >>>> able to use a > >> generic OS anyway. > >>>> > >>> > >>> Hmm, so far, I haven't come across where UEFI specs says, we need a > >>> separate Storage for firmware. (May be I missed some part of specs) > >>> Irrespective of storage media, we have this problem if OS and UEFI > >>> shares same storage. > >>> > >> > >> Udit, > >> > >> Can you point out the spec that states you can't boot Linux and > >> Windows at the same time on a PC? :) > >> > >> When you write a spec it is not practical do document what is not > >> possible, you can only document the API the rest is implied by the > >> implementation. So for example the UEFI spec does not document why > >> the firmware and OS can't share a hardware device, just like you > >> can't have 2 operating systems running on bare metal at the same > >> time. It is a little like Occam's Razor the reason that the firmware > >> and the OS can not share a hardware device is the mechanics of how to > >> share a hardware device is not defined in the spec, thus it is not par= t of the > API and not possible. > > > > Right, This is left on implementation how to put firmware and OS. > > Ideally, keeping both storage separate is best case, no need to sync b= etween > two. > > > > My reply to Ard, was to highlight that in any case (NOR or eMMC /NAND) > > if we are keeping OS and firmware on same storage, we will have same > > issue not limited to eMMC. > > > > For some requirement, if we need to keep firmware and OS on same > > media, Then implementation should make sure there is exclusive access > > (be it NOR controller, SD controller etc). > > >=20 > Udit, >=20 > Sorry I'm a little swamped on my email right now and might be a little be= hind on > the thread.... >=20 > Yea the only way to realistically Implement an EFI runtime service in UEF= I is to > have UEFI own the hardware device. There is no architecture for sharing t= he > device, and the type of device is not really relevant. >=20 > Thanks, >=20 > Andrew Fish >=20 > > Thanks > > Udit > > > >> Thanks, > >> > >> Andrew Fish > >> > >>>>> For sure, some synchronization issues need to be ironed out (or > >>>>> maybe I am > >>>> just dreaming here). > >>>>> > >>>>> On part 2) where you forked VariableRuntime driver , could we > >>>>> think of updating VariableRuntime driver, to support non-XIP or > >>>>> memory mapped > >>>> devices. > >>>>> > >>>> > >>>> I think being able to support non-memorymapped FV volumes for the > >>>> variable store would be a big improvement. This does require > >>>> changes to both the FaultTolerantWrite drivers and the > >>>> VariableRuntime drivers, which both appear in PEI, DXE and SMM > >>>> flavors, and require thorough review due to the security impact > >>>> bugs have in this layer, so this is a > >> rather large chunk of work to take on. > >>> > >>> Thanks, your list is longer than what I was thinking :-) I think, > >>> for embedded world with UEFI, later or sooner, this will be required. > >>> > >>> Thanks > >>> Udit > >>> _______________________________________________ > >>> edk2-devel mailing list > >>> edk2-devel@lists.01.org > >>> https://lists.01.org/mailman/listinfo/edk2-devel >=20 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel