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 <[email protected]> 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:[email protected]] On Behalf Of Andrew > Fish > Sent: Wednesday, September 20, 2017 10:48 AM > To: Udit Kumar <[email protected]> > Cc: [email protected]; Vladimir Olovyannikov > <[email protected]>; [email protected]; Ard Biesheuvel > <[email protected]> > Subject: Re: [edk2] Storing Non volatile variables on SD/NAND > > >> On Sep 19, 2017, at 10:09 PM, Udit Kumar <[email protected]> wrote: >> >>>> On Sep 19, 2017, at 9:27 PM, Udit Kumar <[email protected]> wrote: >>>> >>>> >>>>> On 18 September 2017 at 22:28, Udit Kumar <[email protected]> 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 >>>> [email protected] >>>> https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
