From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B2DE521ECCB0C for ; Wed, 20 Sep 2017 10:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1505928900; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RJUu89MlIbDXzOzJbbv3wNhVWW/9HBELMYE7O6TnXac=; b=vc5OPmYzTrCf+lpmzc2nZRg4CVn5L4MCj6jNduSqmxd9rzMGZr1DLndqsXbZCp/n 9MrJUzkXkIClx2gzH7K2OQ9J+wJKUeg6D5aQ5eAJ/FV4FxIJhIvqgWuZI6YTzvSz pHF3wWr5nQ3fnMT974HfNyIsJ58ISVb0ObvP/EoygLfDEJLKIfSJiNbiH6OCwnmy AdrfSRQdZwTE6iDI6XN+RqQeaebm+nKMQ/OKb9oEkWp5xF8WxjF2WwjkIUd8LbNo SSdifej1j7U2R5Lh4XLmWLyq1wy4mivots2d/erF5cR4k/0sc60CeAU/xoFUt/G/ 632ivSIhUW5iCys+GZTlGQ==; Received: from relay22.apple.com (relay22.apple.com [17.171.128.103]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id E9.FF.21774.4C6A2C95; Wed, 20 Sep 2017 10:35:00 -0700 (PDT) X-AuditID: 11ab0215-451ff7000000550e-96-59c2a6c403eb Received: from ma1-mmpp-sz07.apple.com (ma1-mmpp-sz07.apple.com [17.171.128.149]) by relay22.apple.com (Apple SCV relay) with SMTP id 25.85.07334.4C6A2C95; Wed, 20 Sep 2017 10:35:00 -0700 (PDT) MIME-version: 1.0 Received: from [17.234.221.13] by ma1-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OWL0009LA69C580@ma1-mmpp-sz07.apple.com>; Wed, 20 Sep 2017 10:35:00 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish In-reply-to: Date: Wed, 20 Sep 2017 10:34:57 -0700 Cc: Udit Kumar , "edk2-devel@lists.01.org" , Vladimir Olovyannikov , "Olivier.Martin@arm.com" , Ard Biesheuvel Message-id: <944AC986-4DE1-4999-B831-A696BBBA7C5A@apple.com> References: <4CC33CC2-86D1-490E-A67E-12D751745121@apple.com> To: Pankaj Bansal X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUiuLohXffIskORBvPeWlr8/7Cb0WLPoaPM FkfXfWG3eLXwAZPFiiWH2CzeLz7O7MDmsWbeGkaPWffPsnncubaHzaN79j8Wj43vdjAFsEZx 2aSk5mSWpRbp2yVwZcx8UVPQoFNx++tT1gbGWcpdjBwcEgImEi8a87oYOTmEBNYzSeyarQ9i g4Tv3z7M3sXIBRQ/zCix5vYnNpAEr4CgxI/J91hAepkF5CUOnpcFCTMLaEl8f9TKAlH/lVFi zv0zzCAJYQFxiXdnNkHZthI/tvSwgNhsAsoSK+Z/YAeZwymQLPHyCiNImEVAVaKp4QYzyBxm gd+MEjdefWeH2Gsj0bh2GyPEgmesElsO/wLrEBHQlDjY1c4CcbWsxK3Zl8C6JQR2sElMPHSd fQKj8Cwkh89COHwWksMXMDKvYhTOTczM0c3MMzLUSywoyEnVS87P3cQIjg8m0R2M818ZHmIU 4GBU4uENsDoYKcSaWFZcmXuIUZqDRUmcd/c/oJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG 9s0XE62+8y1v/1AufeCUVMe0ZINlEcmMvw3YTPidxXwzhPfMeb7t7vdgbol8vS8Cy2PcH/5k dhUVljXZ3LH049LX2mq89kuOlWU/bVRh+JBi881l6q8gVqEtNXfLKr5s1WEvfXn5xNUDkVPr Xc0UPp3os2WOyOfIuiZkdUHm3unD12LfTfqpxFKckWioxVxUnAgAgWZRvnACAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUiuLphqu6RZYciDZYsNLb4/2E3o8WeQ0eZ LY6u+8Ju8WrhAyaLFUsOsVm8X3yc2YHNY828NYwes+6fZfO4c20Pm0f37H8sHhvf7WAKYI3i sklJzcksSy3St0vgypj5oqagQafi9tenrA2Ms5S7GDk5JARMJO7fPszexcjFISRwmFFize1P bCAJXgFBiR+T77F0MXJwMAvISxw8LwsSZhbQkvj+qJUFov4ro8Sc+2eYQRLCAuIS785sgrJt JX5s6WEBsdkElCVWzP/ADjKHUyBZ4uUVRpAwi4CqRFPDDWaQOcwCvxklbrz6zg6x10aice02 RogFz1glthz+BdYhIqApcbCrnQXialmJW7MvMU9gFJiF5NZZCLfOQnLrAkbmVYyCRak5iZVG RnqJBQU5qXrJ+bmbGCEhnb6D8chNs0OMAhyMSjy8AVYHI4VYE8uKK3MPMUpwMCuJ8AovORQp xJuSWFmVWpQfX1Sak1p8iFGag0VJnFd4JlC1QHpiSWp2ampBahFMlomDU6qBMeXw/Yt3l587 OydJ5UvEVZ1UhykbtvJwHwo5nbr7vOnB674v1c7d1RDvY3TgN2yV/e+s7Ne/a0bcn5APO9bP Nbx/+vf/qIUhO9imROucLo8qic5OW744Lql8asDiQy2rbLuYd2QkBLAvee+2/I0lJz+rr1Ga JKOhqcTpFbkfluYFa/daVonyKLEUZyQaajEXFScCAJh8r59lAgAA 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:58 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Pankaj, We understand the use cases. We just don't have a good solution for the spec that is OS, Firmware, and hardware agnostic. Thanks, Andrew Fish > On Sep 20, 2017, at 7:51 AM, Pankaj Bansal wrote: > > This use case also arises for single-board systems like raspberry-pi, which 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/ > > Thanks & Regards, > Pankaj Bansal > > -----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 > > >> 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 part 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 between 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). >> > > Udit, > > Sorry I'm a little swamped on my email right now and might be a little behind on the thread.... > > Yea the only way to realistically Implement an EFI runtime service in UEFI is to have UEFI own the hardware device. There is no architecture for sharing the device, and the type of device is not really relevant. > > Thanks, > > Andrew Fish > >> 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 > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel