-----Original Message----- From: arm.ebbr-discuss-bounces@arm.com [mailto:arm.ebbr-discuss- bounces@arm.com] On Behalf Of Leif Lindholm Sent: Thursday, May 3, 2018 10:20 PM To: Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com Cc: Architecture Mailman List boot-architecture@lists.linaro.org; arm.ebbr- discuss@arm.com 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 Arm.ebbr-discuss@arm.com