> (along those lines) > > 6 - Build an emulated disk controller as well as NV region in el3 (or > el2) and export them to UEFI & the OS as real devices. Then trap/forward > requests to the actual storage device, which is "hidden". This AFAIK was the > basic idea behind the PS/2 emulation in x86/SMM. Again, probably not a high > performance option.
You mean, have a driver in el3 or el2 and UEFI or OS is doing smc call to get things done. On this line, some sort of permission manager could reside in el3 or el2. Either UEFI or OS driver needs to make a call, if they are allowed to access this specific controller or other driver is accessing it. With this performance issue could be ironed out . Regards Udit > -----Original Message----- > From: Jeremy Linton [mailto:jeremy.lin...@arm.com] > Sent: Friday, October 27, 2017 11:16 PM > To: Ard Biesheuvel <ard.biesheu...@linaro.org>; Udit Kumar > <udit.ku...@nxp.com> > Cc: edk2-devel@lists.01.org; Andrew Fish <af...@apple.com>; > olivier.mar...@arm.com; Vladimir Olovyannikov > <vladimir.olovyanni...@broadcom.com> > Subject: Re: [edk2] Storing Non volatile variables on SD/NAND > > On 09/20/2017 12:39 PM, Ard Biesheuvel wrote: > > On 20 September 2017 at 10:34, Udit Kumar <udit.ku...@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. > > (along those lines) > > 6 - Build an emulated disk controller as well as NV region in el3 (or > el2) and export them to UEFI & the OS as real devices. Then trap/forward > requests to the actual storage device, which is "hidden". This AFAIK was the > basic idea behind the PS/2 emulation in x86/SMM. Again, probably not a high > performance option. > > > > > > 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. > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01 > .org%2Fmailman%2Flistinfo%2Fedk2- > devel&data=02%7C01%7Cudit.kumar%40nxp.com%7Cfe11f07ea67a4efa7d1b08 > d51d629deb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63644723 > 1755528994&sdata=FYnH3ItGhXmqxNr%2BnaJBFMcKKduf%2FcS06JEA6dT6ZQA > %3D&reserved=0 > > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
