From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=40.107.0.49; helo=eur02-am5-obe.outbound.protection.outlook.com; envelope-from=udit.kumar@nxp.com; receiver=edk2-devel@lists.01.org Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00049.outbound.protection.outlook.com [40.107.0.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4F0D42034A891 for ; Fri, 27 Oct 2017 02:31:34 -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=AAEZfKN1OeKs32DueSna4yknq8LcqlwI656/uj6DgJ0=; b=Gzby2V2MkA++VPfRI1ASzts2C/XQEL/TSlj8RSY4GcE3j2K5k+Qx2+ZWYM47RaCvyBRlqg0fDa3x3XnV8LRndtRsmWJVBuOhu4AEDRKlPsqAB2SzTbPZ4pE0w6DwrJnuheo/ikhgUcAeMf7qWzqdQrrLL/2BPDn6pTBbSpGaYPo= Received: from VI1PR0402MB3341.eurprd04.prod.outlook.com (52.134.8.141) by VI1PR0402MB3344.eurprd04.prod.outlook.com (52.134.8.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Fri, 27 Oct 2017 09:35:18 +0000 Received: from VI1PR0402MB3341.eurprd04.prod.outlook.com ([fe80::51e3:cf90:1646:9c51]) by VI1PR0402MB3341.eurprd04.prod.outlook.com ([fe80::51e3:cf90:1646:9c51%13]) with mapi id 15.20.0156.007; Fri, 27 Oct 2017 09:35:19 +0000 From: Udit Kumar To: "afish@apple.com" , Ard Biesheuvel CC: "edk2-devel@lists.01.org" , "Olivier.Martin@arm.com" , Vladimir Olovyannikov Thread-Topic: [edk2] Storing Non volatile variables on SD/NAND Thread-Index: AdMwhGas4HV30Cb6RHux5gL+cq9qtgAEHTUAAAJm0wAAGXHS4AAYW1AAABfKRvAAAbCQAAAAEh/QAAD7vYAAE55LQAAD1rowAAJt04AAAAgMgAAAOC4ABzIbAfA= Date: Fri, 27 Oct 2017 09:35:19 +0000 Message-ID: References: <4CC33CC2-86D1-490E-A67E-12D751745121@apple.com> <7B611C7B-2DC3-4419-9840-926A4B253E9F@apple.com> In-Reply-To: <7B611C7B-2DC3-4419-9840-926A4B253E9F@apple.com> 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; VI1PR0402MB3344; 6:x3I84zo19GAZ6TfACYmlyIe5jUzegPVuaQXW+IpaxRWv2JBB4+vcgtC73a7EavP6tg69FBIurbRUuAC4DQ+aM4GmQhYM+y9F1K2RLZGzKbIVyBEYmOq2pdi5lF/AN+eHpYvxtceA4gi05YIYSgbcaE274s4fNm3BRZsw5sFaAHgWXn0p2Uw5JgxLsm91B2mvce4d50lHg9g/S4fjvys3k6jkE8qja4MdItvt/BmkKPxOiOJzQK4oqvCMZYgx/ALvDTzHCnATS/zSgq3BFtsSWD/3xeOR76NxEnhvzXEUkocvqjt3+Ws8XDlH+ZTldvFI8mYa/hhH4YxxVwd76b8iTQ==; 5:pyZqhuQseKL5z8X7JyCSc7DWUQHoyUN0ZMS8+B3wumPm2nftHSxhhXlcQGA6w0x9czNxcAknCiqJniNrpaSBA5WCMZEoN4bN4kObwUok8K/+BdFyyiEJvIVtd3jAAaMUGWKGlteCRjuvntfkmv7vDQ==; 24:06QVZoDuIhmfnGou47FC34gPv9+XhgSLTAhvdVUVQulQxucRtWpiBoiWbnnruJdsOU0AG8n4EREyV1Y37Dn7JhS/z4gihml8E1ivdmSW9tg=; 7:l3OgWt3zcb7DCuhebQ52Vu+BNO7SGDUvksebuXSxsRvu3CEiIDsFPcX+8n5NmZsqNFdZCtz4PI4q/oPHnU4kL+Ma6FO4tu/B1wYU/rgPYugBVG69SnRgeVU6h26wOztMzxMX50gdj+c7dkPv7wpFj2Z+GhQMRI7f8PderactVaHy2wO5+R6cCbldBULkZYP59Sm2Q6QaRND1riy6Yv9UJ8xoOEGesYCyiSg3v4pB9MM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f25f101c-04d3-4473-f195-08d51d1e09b7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603238); SRVR:VI1PR0402MB3344; x-ms-traffictypediagnostic: VI1PR0402MB3344: x-exchange-antispam-report-test: UriScan:(180628864354917)(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)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231020)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0402MB3344; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0402MB3344; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(39860400002)(189002)(199003)(24454002)(13464003)(6116002)(3846002)(54356999)(3280700002)(101416001)(105586002)(229853002)(8936002)(50986999)(6246003)(97736004)(8676002)(81166006)(53936002)(74316002)(102836003)(106356001)(7736002)(81156014)(33656002)(25786009)(3660700001)(68736007)(76176999)(9686003)(316002)(53546010)(54906003)(966005)(305945005)(6506006)(4326008)(6436002)(189998001)(5660300001)(99286003)(55016002)(5250100002)(110136005)(14454004)(478600001)(6306002)(8666007)(2900100001)(2906002)(66066001)(93886005)(2950100002)(86362001)(7696004)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0402MB3344; H:VI1PR0402MB3341.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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-Network-Message-Id: f25f101c-04d3-4473-f195-08d51d1e09b7 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 09:35:19.0973 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0402MB3344 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: Fri, 27 Oct 2017 09:31:35 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andrew,=20 > The concept of a runtime EFI driver is in the UEFI spec, but the issue is= there is no > way to tell the OS to not bind it's driver for that device that is univer= sal. If you > boot an unmodified OS it is going to conflict with the EFI runtime servic= e. In order to bind driver with universal device, OS driver could be modified and device tree could indicate if this storage is shared with BIOS runtime.= (Assuming booting Linux) =20 But I am struggling here, how OS will get services of this driver.=20 I assume in Linux, struct efi_runtime_services is fixed as per specs.=20 Will this modified driver, needs to access unsigned long runtime; of struct= efi to get=20 UEFI run time services ?=20 > My gut feel is if the OS has a driver for the device it may be better to = make the > media format the architectural point. That way the OS can read/write it v= ia a > driver/app. There could be an UEFI Services Table entry that implies what > scheme is being used. That way there is only every one owner of the hardw= are > device. I assume #3 is like this? Yeah , probably can think of this, if OS update the runtime variables with= out help of UEFI runtime services using some sort of file system. =20 Thanks Udit > -----Original Message----- > From: afish@apple.com [mailto:afish@apple.com] > Sent: Wednesday, September 20, 2017 11:16 PM > To: Ard Biesheuvel > Cc: Udit Kumar ; edk2-devel@lists.01.org; > Olivier.Martin@arm.com; Vladimir Olovyannikov > > Subject: Re: [edk2] Storing Non volatile variables on SD/NAND >=20 >=20 > > On Sep 20, 2017, at 10:39 AM, Ard Biesheuvel > wrote: > > > > On 20 September 2017 at 10:39, Ard Biesheuvel > wrote: > >> On 20 September 2017 at 10:34, Udit Kumar wrote: > >>> > >>> When we want to have UEFI and OS accessing same media , > >>> Possibilities I see > >>> > >>> 1- Patch OS For status check of media (diversion from generic OS), Go= od > case will be modify low level driver. > >>> But we may end up some surprises on synchronization. > >>> > >>> 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 da= ta in > case of AC power off. > >>> > >>> 4- update hardware with dual view (Ard suggestion) > >>> > >> > >> 5 - abstract direct block device access into a firmware service that > >> is exposed via a DXE_RUNTIME_DRIVER. > >> > >> The UEFI spec allows you to expose entry points into a > >> DXE_RUNTIME_DRIVER module via a UEFI configuration table, and the OS > >> can use a driver that uses the abstracted device rather than the real > >> device. Performance is going to be terrible, probably, and lots of > >> things that are specific to SD/MMC will no longer work, but it is a > >> possibility nonetheless. > > > > BTW this would go beyond the UEFI spec, and would effectively be a > > PI/UEFI dependent feature. >=20 > The concept of a runtime EFI driver is in the UEFI spec, but the issue is= there is no > way to tell the OS to not bind it's driver for that device that is univer= sal. If you > boot an unmodified OS it is going to conflict with the EFI runtime servic= e. >=20 > My gut feel is if the OS has a driver for the device it may be better to = make the > media format the architectural point. That way the OS can read/write it v= ia a > driver/app. There could be an UEFI Services Table entry that implies what > scheme is being used. That way there is only every one owner of the hardw= are > device. I assume #3 is like this? >=20 > Thanks, >=20 > Andrew Fish >=20 > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel