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.olovyanni...@broadcom.com] > Sent: Monday, September 18, 2017 10:22 PM > To: Ard Biesheuvel <ard.biesheu...@linaro.org>; Udit Kumar > <udit.ku...@nxp.com> > Cc: grant.lik...@linaro.org; edk2-devel@lists.01.org; olivier.mar...@arm.com > Subject: RE: [edk2] Storing Non volatile variables on SD/NAND > > > -----Original Message----- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Ard Biesheuvel > > Sent: Monday, September 18, 2017 8:43 AM > > To: Udit Kumar > > Cc: grant.lik...@linaro.org.; edk2-devel@lists.01.org; > > olivier.mar...@arm.com > > Subject: Re: [edk2] Storing Non volatile variables on SD/NAND > > > > On 18 September 2017 at 06:52, Udit Kumar <udit.ku...@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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
