On Sat, May 05, 2018 at 10:25:06AM +0000, Udit Kumar wrote:
-----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.
The E in EBBR is embedded... and for some applications embedded implies significant work to reduce the BOM; cents do sometimes matter (and they certainly add up for high volume boards). This makes me very uncomfortable requiring additional storage, even for the relatively well resourced devices EBBR is likely to suit best.
I'm glad to be reminded about OS neutrality and agree its important. Nevertheless I do think that there's a potentially difference in the interpretation of OS neutrality between "implemented" and "implementable" (and doubly so for closed source software where the honour of implementing is heavily restricted).
Right now at lot of what we discuss is not implemented, even by the Linux distros. I think only SuSE has an implementation for tolerating platforms without variable storage and I don't discussions thus far have led to agreement to accept their solution as-is.
Daniel.