> > On Sep 19, 2017, at 9:27 PM, Udit Kumar <udit.ku...@nxp.com> wrote: > > > > > >> On 18 September 2017 at 22:28, Udit Kumar <udit.ku...@nxp.com> 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). 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 > > 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
