Re: Storing Non volatile variables on SD/NAND

[Udit Kumar <udit.kumar@nxp.com>]

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), Good 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 data in case of AC power off. 

4- update hardware with dual view (Ard suggestion) 

Thanks to add, if I missed some option here. 

> 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/


Raspberry follow the different boot scheme.  What I think, Linux running on Raspberry/ARM is unware of UEFI boot. 

Copied text 
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 
and bcm2835.dtb If the dtb file exists, it is loaded at 0×100 & kernel @ 0×8000 
If disable_commandline_tags is set it loads kernel @ 0×0 Otherwise it loads kernel @ 0×8000 and put ATAGS at 0×100
Stage 5: kernel.img is then run on the ARM

I think up to stage 4, we have GPU . 
Here SD is exclusivity used by UEFI or OS. Any corrections ?  
 

Thanks
Udit

> -----Original Message-----
> From: Pankaj Bansal
> Sent: Wednesday, September 20, 2017 8:22 PM
> To: Andrew Fish <afish@apple.com>; Udit Kumar <udit.kumar@nxp.com>; edk2-
> devel@lists.01.org
> Cc: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>;
> Olivier.Martin@arm.com; Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Subject: RE: [edk2] Storing Non volatile variables on SD/NAND
> 
> 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 <udit.kumar@nxp.com>
> Cc: edk2-devel@lists.01.org; Vladimir Olovyannikov
> <vladimir.olovyannikov@broadcom.com>; Olivier.Martin@arm.com; Ard
> Biesheuvel <ard.biesheuvel@linaro.org>
> Subject: Re: [edk2] Storing Non volatile variables on SD/NAND
> 
> 
> > On Sep 19, 2017, at 10:09 PM, Udit Kumar <udit.kumar@nxp.com> wrote:
> >
> >>> On Sep 19, 2017, at 9:27 PM, Udit Kumar <udit.kumar@nxp.com> wrote:
> >>>
> >>>
> >>>> On 18 September 2017 at 22:28, Udit Kumar <udit.kumar@nxp.com>
> 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