From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10085.outbound.protection.outlook.com [40.107.1.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5BBEC21CEB0FA for ; Tue, 19 Sep 2017 22:06: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=2Ef+u3jGlC6l+0Ba21h8Fmbm3XRESfdIfAz3z8pQd1Q=; b=bWClKrJXmpOPFhSO7T5tdE2W9Q++QL3/7G0iYLxBa4p+0+rVAoB0dChcH1GEvF6IsdQWseu1dwTZdUzyvCdVdIg1uer8DvpCviGi4PEJmu+o0gtJgLLvlPsFIP8xBNE4ja8QjzRfFVYMwqfAzdxyinor1aHU+L+bR7qmnFCfJXU= Received: from AM6PR0402MB3334.eurprd04.prod.outlook.com (52.133.18.151) by AM6PR0402MB3544.eurprd04.prod.outlook.com (52.133.19.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Wed, 20 Sep 2017 05:09:41 +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 05:09:41 +0000 From: Udit Kumar To: "afish@apple.com" CC: Ard Biesheuvel , "edk2-devel@lists.01.org" , Vladimir Olovyannikov , "Olivier.Martin@arm.com" Thread-Topic: [edk2] Storing Non volatile variables on SD/NAND Thread-Index: AdMwhGas4HV30Cb6RHux5gL+cq9qtgAEHTUAAAJm0wAAGXHS4AAYW1AAABfKRvAAAbCQAAAAEh/Q Date: Wed, 20 Sep 2017 05:09:41 +0000 Message-ID: References: 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: [192.88.169.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR0402MB3544; 6:7CR1VhSxBQfG7gNCKo6y295QCJrq5ELab5felDuNgUzhBeLXZ1aK5gbW2mc0ud5ZuJzm5CbrMYIPue9oJrb79OSeW/wOEJca96YWq0d490CFpPfJa1zZ3JUCIl3JPppMdjYScAIh2L1aOJCX1D4tPXGc9miUN1OrFF55KHNQ2KNB+0Rk0Z/AA/1yTI2axZ9JjFj4hgpGi8H/NC4iZ4DHo8cl7mzmLZqf5wIicopA4tkCPxjkPTN8BLdVhSSSiWTB0JT3B6ATQyszZ52VpPwz8E8kKoHPjdeyQSMJZX4h6tF7sz9/Zzfvp7y+5LqCXR5A52bDmOdnDJKyBKkh8gXrRA==; 5:Ftn8ha/MTPnZbgnKSkXCFgeOaAVwz1pvYvQCDTMvnRXTntHpwodpbpxfhzRrQWiKB8Aoz2a9h9bOBZVjq9oIVwVJNwWKSvLvalhO69yoEjP23TGEoDvCUpo3I1xgwSt2gUx82KxXYfZlTpPxiFuFO+UC0w2Icym/0Zjyq0RY05c=; 24:A+LwA0D2dpyRwGM12DARqOdzniUB1NM2Eg2HVF75s9eXwPgePH30MwnOecct4hxOUfs2R1yQwhFL+eKt/PtMXY2V7ceXD3/iw2hplUKnw5k=; 7:v0lX7u9SbsnU6NKLT3iP8m5K2DHcerS/4rbTineV2U2duPEjxd8NLQkBiBNy1ZRxpmN7jdzBK7wljdDIF7zGx+CSy0lmmCpL0ndrc+qCQ9lApf4lrvP57uZrnXY0beJL1abEufrbRlDtxF2FolDpUk5/BOxNTJ9eDwFabW7/wTPwGqdlZ4dLpr8GwpLjk2rU5qILaEQwtPhZDIJWSiPiHTZBWKMzgDkau7U8A+a9J1Y= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 60d7f011-ca3c-4318-d330-08d4ffe5ccbc 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:AM6PR0402MB3544; x-ms-traffictypediagnostic: AM6PR0402MB3544: x-exchange-antispam-report-test: UriScan:(192374486261705)(185117386973197)(162533806227266); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123558100)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM6PR0402MB3544; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM6PR0402MB3544; x-forefront-prvs: 04362AC73B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(199003)(189002)(377454003)(24454002)(7696004)(5640700003)(6916009)(2950100002)(229853002)(5660300001)(74316002)(6506006)(6436002)(2906002)(3660700001)(3280700002)(2900100001)(478600001)(14454004)(54906003)(25786009)(6306002)(101416001)(8676002)(54356999)(76176999)(4326008)(1730700003)(50986999)(53546010)(55016002)(8666007)(6246003)(9686003)(53936002)(99286003)(966005)(81166006)(8936002)(81156014)(189998001)(316002)(97736004)(6116002)(3846002)(33656002)(102836003)(2501003)(5250100002)(68736007)(66066001)(7736002)(106356001)(305945005)(93886005)(86362001)(105586002)(2351001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR0402MB3544; H:AM6PR0402MB3334.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 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 05:09:41.2509 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0402MB3544 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 05:06:40 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > > 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 adh= ere to > the API rules. > > > > Yup, we are fine as long as long UEFI firmware is stored on dedicated m= edia. > > > >> 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 t= o 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. > > >=20 > Udit, >=20 > Can you point out the spec that states you can't boot Linux and Windows a= t the > same time on a PC? :) >=20 > When you write a spec it is not practical do document what is not possibl= e, you > can only document the API the rest is implied by the implementation. So f= or > example the UEFI spec does not document why the firmware and OS can't sha= re > a hardware device, just like you can't have 2 operating systems running o= n 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 h= ow > 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 betwe= en 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=20 issue not limited to eMMC. For some requirement, if we need to keep firmware and OS on same media,=20 Then implementation should make sure there is exclusive access (be it NOR controller, SD controller etc).=20 Thanks Udit > Thanks, >=20 > Andrew Fish >=20 > >>> 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