Re: Storing Non volatile variables on SD/NAND

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

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

Thanks
Udit 

> -----Original Message-----
> From: Vladimir Olovyannikov [mailto:vladimir.olovyannikov@broadcom.com]
> Sent: Monday, September 18, 2017 10:22 PM
> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Udit Kumar
> <udit.kumar@nxp.com>
> Cc: grant.likely@linaro.org; edk2-devel@lists.01.org; Olivier.Martin@arm.com
> Subject: RE: [edk2] Storing Non volatile variables on SD/NAND
> 
> > -----Original Message-----
> > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> > Ard Biesheuvel
> > Sent: Monday, September 18, 2017 8:43 AM
> > To: Udit Kumar
> > Cc: grant.likely@linaro.org.; edk2-devel@lists.01.org;
> > Olivier.Martin@arm.com
> > Subject: Re: [edk2] Storing Non volatile variables on SD/NAND
> >
> > On 18 September 2017 at 06:52, Udit Kumar <udit.kumar@nxp.com> wrote:
> > > Hi EDK-2 Experts,
> > > I am looking to store NV variables on SD/NAND device.
> > >
> > > While browsing, I came across some old post at link,
> > > http://feishare.com/efimail/messages/20130319-1700-
> > Re__edk2__Regarding
> > > _storing_Boot_Device_Config_in_persistent_memory-Olivier_Martin.html
> > >
> > > Looks like, this is possible easily.
> >
> > That's a bold statement dude :-)
> >
> > >>> What you need to support Non-Volatile UEFI variables is a
> Non-Volatile
> > Memory. And also a driver that implements the EFI Firmware Volume
> > Block protocol for this NVM device.
> > >
> > > But MdeModulePkg does Copymem from NV variable start memory to
> > some
> > > allocated buffers.  With SD/NAND Copymem is not possible, Is this
> > > something changes since 2013 or there are some other way to use
> > > SD/NAND
> > >
> >
> > No, SD/MMC cannot currently be used as the backing store for the EFI
> > variable store. The problem is that the variable protocols are
> architectural
> > protocols in PI that need to be present before any driver model
> > drivers
> are
> > dispatched, and so putting the variable store on block devices is not
> > something that the PI software architecture currently supports (unless
> you
> > reimplement the whole driver stack as DXE drivers).
> >
> > On top of that, it is almost impossible to share a block device that
> sits behind
> > a controller between the firmware and the OS at runtime (i.e., for
> > SetVariable() calls made by efibootmgr under Linux), because only a
> single
> > agent can take ownership of the controller at any given time. (You
> /could/
> > dedicate the SD/MMC to the firmware entirely, and boot from SATA or
> > USB, but this is out of the question on most platforms that need to
> > use
> SD/MMC
> > for that variable backing store, i.e., mobile platforms)
> >
> > The best thing would be for you to convince the hardware architects in
> your
> > company to design and implement dual-ported SD/MMC controllers that
> > allow a single SD/MMC to have two logical views that are independent
> > (although I'm unsure if that is even possible in the context of the
> SD/MMC
> > specifications)
> >
> > Thanks,
> > Ard.
> Udit,
> Ard is absolutely right.
> 
> Following design I had to implement variable store on the EMMC boot partition
> 1 (not exactly SD card, but close; the same is applied to NAND I guess).
> To do that I forked VariableRuntime driver and changed it to do cache writes
> into the store (just modifying store memory) at runtime.
> This is because you cannot share eMMC store between OS (Linux)  and the UEFI
> service at the same time, and you cannot predict when OS writes/reads to/from
> the EMMC device.
> So I do cache writes at runtime (just modifying store in memory), and flush the
> store on reboot/shutdown.
> For this purpose my ResetSystemLib calls into the Variable service and forces
> flush. Variable service reinitiates eMMC controller and really writes into the
> store on the eMMC. Real flush is also performed on ExitBootServices().
> 
> As a big drawback an OS should either reset or shutdown (get into UEFI
> ResetSystemLib) in order for variable store to be updated physically; Physical
> flush is also forced on ExitBootServices - be it a reset command, or booting an
> OS.
> Just pressing a reset button (example: Linux Kernel panic with no reset) would
> cause variable changes for this session to get lost.
> 
> Thank you,
> Vladimir
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel