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 <[email protected]>; Udit Kumar <[email protected]>; edk2- > [email protected] > Cc: Vladimir Olovyannikov <[email protected]>; > [email protected]; Ard Biesheuvel <[email protected]> > 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:[email protected]] On Behalf Of > Andrew Fish > Sent: Wednesday, September 20, 2017 10:48 AM > To: Udit Kumar <[email protected]> > Cc: [email protected]; Vladimir Olovyannikov > <[email protected]>; [email protected]; Ard > Biesheuvel <[email protected]> > Subject: Re: [edk2] Storing Non volatile variables on SD/NAND > > > > On Sep 19, 2017, at 10:09 PM, Udit Kumar <[email protected]> wrote: > > > >>> On Sep 19, 2017, at 9:27 PM, Udit Kumar <[email protected]> wrote: > >>> > >>> > >>>> On 18 September 2017 at 22:28, Udit Kumar <[email protected]> > 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 > >>> [email protected] > >>> https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
