> -----Original Message----- > From: [email protected] [mailto:arm.ebbr-discuss- > [email protected]] On Behalf Of Leif Lindholm > Sent: Thursday, May 3, 2018 10:20 PM > To: Chang, Abner (HPS SW/FW Technologist) <[email protected]> > Cc: Architecture Mailman List <[email protected]>; arm.ebbr- > [email protected] > Subject: Re: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent > variables > > On Mon, Apr 30, 2018 at 02:26:22PM +0000, Chang, Abner (HPS SW/FW > Technologist) wrote: > > > > I guess it would be possible to implement this in code. The > > > > problem is that the UEFI spec does not cover any of this, and so > > > > there is no way for the OS to find out whether it can call > > > > SetVariable() as the spec permits, or whether it should switch > > > > into this 'special' mode where it can only call SetVariable() when > > > > none of the other cores are executing completely some completely > > > > unrelated piece of code (i.e, the SPI controller driver) that > > > > happens to touch the same hardware on this particular platform. > > > > No sure how other OSes like Windows or ubuntu make this happen. But > > they do call SetVariable during runtime such as to set OsIndications > > or BootNext to reboot to BIOS system utility. > > Sorry, just noticed no one responded to this. > > The simple answer is that machines that run Windows always have a storage for > the sole use of firmware - so the conflict of ownership between firmware and > operating system never occurs.
Draft specs says EBBR is OS neutral, I hope we will follow the same. Then shouldn't we say use *dedicated* storage for firmware. or we are going to say, use this for windows and that for Linux. If we talk about device sharing (not now) but later it should be OS neutral. > / > Leif > _______________________________________________ > Arm.ebbr-discuss mailing list > [email protected] _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
