Re: Storing Non volatile variables on SD/NAND

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

Hi Andrew, 

> The concept of a runtime EFI driver is in the UEFI spec, but the issue is there is no
> way to tell the OS to not bind it's driver for that device that is universal. If you
> boot an unmodified OS it is going to conflict with the EFI runtime service.

In order to bind driver with universal device, OS driver could be modified
and device tree could indicate if this storage is shared with BIOS runtime. (Assuming booting Linux)
 
But I am struggling here, how OS will get services of this driver. 
I assume in Linux, struct efi_runtime_services is fixed  as per specs. 

Will this modified driver, needs to access unsigned long runtime; of struct efi to get 
UEFI run time services ? 


> My gut feel is if the OS has a driver for the device it may be better to make the
> media format the architectural point. That way the OS can read/write it via a
> driver/app. There could be an UEFI Services Table entry that implies what
> scheme is being used. That way there is only every one owner of the hardware
> device. I assume #3 is like this?

Yeah , probably can think of this,  if OS update the runtime variables without
help of UEFI runtime services using some sort of file system.  

Thanks
Udit

> -----Original Message-----
> From: afish@apple.com [mailto:afish@apple.com]
> Sent: Wednesday, September 20, 2017 11:16 PM
> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Udit Kumar <udit.kumar@nxp.com>; edk2-devel@lists.01.org;
> Olivier.Martin@arm.com; Vladimir Olovyannikov
> <vladimir.olovyannikov@broadcom.com>
> Subject: Re: [edk2] Storing Non volatile variables on SD/NAND
> 
> 
> > On Sep 20, 2017, at 10:39 AM, Ard Biesheuvel <ard.biesheuvel@linaro.org>
> wrote:
> >
> > On 20 September 2017 at 10:39, Ard Biesheuvel <ard.biesheuvel@linaro.org>
> wrote:
> >> On 20 September 2017 at 10:34, Udit Kumar <udit.kumar@nxp.com> wrote:
> >>>
> >>> 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)
> >>>
> >>
> >> 5 - abstract direct block device access into a firmware service that
> >> is exposed via a DXE_RUNTIME_DRIVER.
> >>
> >> The UEFI spec allows you to expose entry points into a
> >> DXE_RUNTIME_DRIVER module via a UEFI configuration table, and the OS
> >> can use a driver that uses the abstracted device rather than the real
> >> device. Performance is going to be terrible, probably, and lots of
> >> things that are specific to SD/MMC will no longer work, but it is a
> >> possibility nonetheless.
> >
> > BTW this would go beyond the UEFI spec, and would effectively be a
> > PI/UEFI dependent feature.
> 
> The concept of a runtime EFI driver is in the UEFI spec, but the issue is there is no
> way to tell the OS to not bind it's driver for that device that is universal. If you
> boot an unmodified OS it is going to conflict with the EFI runtime service.
> 
> My gut feel is if the OS has a driver for the device it may be better to make the
> media format the architectural point. That way the OS can read/write it via a
> driver/app. There could be an UEFI Services Table entry that implies what
> scheme is being used. That way there is only every one owner of the hardware
> device. I assume #3 is like this?
> 
> Thanks,
> 
> Andrew Fish
> 
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel