I took an action last week to provide a block of text for how platforms without persistent variable storage should behave. Here's my opening play:
Boot manager behaviour without persistent variable store =======================================================
Platforms that do not implement persistent variable storage must support the Removable Media Boot Behaviour as described by UEFI.
Such platforms can additionally implement support for additional statically[1] defined images to be processed as SysPrep####, Driver#### and Boot### global variable entries. If present, these entries will be processed in the order specified by corresponding statically defined SysPrepOrder, DriverOrder and BootOrder global variables.
Any images referred to by such variables must reside in a vendor-specific subdirectory on the EFI System Partition, as recorded in http://uefi.org/registry. /BOOT must not be used except where explicitly permitted by UEFI.
Where an executable is present in the prescribed Removable Media location, boot of that must be attempted, and only after this fails should any of the Boot#### entries be processed.
Statically configured BootNext, OsRecovery#### or PlatformRecovery#### entries must not be used.
[1] This is worth discussing, but if we were to support dynamic creation of these, we need _very_ strict rules around it.
On 25.04.18 19:54, Leif Lindholm wrote:
I took an action last week to provide a block of text for how platforms without persistent variable storage should behave. Here's my opening play:
Thanks a lot for getting this started!
Boot manager behaviour without persistent variable store
Platforms that do not implement persistent variable storage must support the Removable Media Boot Behaviour as described by UEFI.
Such platforms can additionally implement support for additional statically[1] defined images to be processed as SysPrep####,
What we have right now in U-Boot is partial support for dynamic variable storage. The way it works is that during boot time, variable store exists and is mutable and fully mapped to U-Boot environment variables which may well be stored on the ESP.
We're missing logic to actually persist the variables on exit boot services today.
So yes, statically defining them (via U-Boot enironment variables, but that's an implementation detail) sounds like a great first approximation to me.
Driver#### and Boot### global variable entries. If present, these entries will be processed in the order specified by corresponding statically defined SysPrepOrder, DriverOrder and BootOrder global variables.
Currently the "bootefi bootmgr" command only implements "BootOrder".
Any images referred to by such variables must reside in a vendor-specific subdirectory on the EFI System Partition, as recorded in http://uefi.org/registry. /BOOT must not be used except where explicitly permitted by UEFI.
Where an executable is present in the prescribed Removable Media location, boot of that must be attempted, and only after this fails should any of the Boot#### entries be processed.
Statically configured BootNext, OsRecovery#### or PlatformRecovery#### entries must not be used.
We should also mention that all variable accesses during runtime must return DEVICE_ERROR and that this is the way an OS can determine that persistent variable store is not available.
Alex
[1] This is worth discussing, but if we were to support dynamic creation of these, we need _very_ strict rules around it. _______________________________________________ Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
On 25/04/2018 19:34, Alexander Graf wrote:
On 25.04.18 19:54, Leif Lindholm wrote:
I took an action last week to provide a block of text for how platforms without persistent variable storage should behave. Here's my opening play:
Thanks a lot for getting this started!
Boot manager behaviour without persistent variable store
Platforms that do not implement persistent variable storage must support the Removable Media Boot Behaviour as described by UEFI.
Such platforms can additionally implement support for additional statically[1] defined images to be processed as SysPrep####,
What we have right now in U-Boot is partial support for dynamic variable storage. The way it works is that during boot time, variable store exists and is mutable and fully mapped to U-Boot environment variables which may well be stored on the ESP.
We're missing logic to actually persist the variables on exit boot services today.
So yes, statically defining them (via U-Boot enironment variables, but that's an implementation detail) sounds like a great first approximation to me.
Driver#### and Boot### global variable entries. If present, these entries will be processed in the order specified by corresponding statically defined SysPrepOrder, DriverOrder and BootOrder global variables.
Currently the "bootefi bootmgr" command only implements "BootOrder".
Any images referred to by such variables must reside in a vendor-specific subdirectory on the EFI System Partition, as recorded in http://uefi.org/registry. /BOOT must not be used except where explicitly permitted by UEFI.
Where an executable is present in the prescribed Removable Media location, boot of that must be attempted, and only after this fails should any of the Boot#### entries be processed.
Statically configured BootNext, OsRecovery#### or PlatformRecovery#### entries must not be used.
We should also mention that all variable accesses during runtime must return DEVICE_ERROR and that this is the way an OS can determine that persistent variable store is not available.
That's a pretty big hammer to tell the OS that SetVariable() is not available. That prevents using variables to communicate any information to the OS. Could we instead define a capability variable to pass that information so that the boot configuration can still be passed through for the OS to query?
g.
Alex
[1] This is worth discussing, but if we were to support dynamic creation of these, we need _very_ strict rules around it. _______________________________________________ Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On 04/26/2018 10:51 AM, Grant Likely wrote:
On 25/04/2018 19:34, Alexander Graf wrote:
On 25.04.18 19:54, Leif Lindholm wrote:
I took an action last week to provide a block of text for how platforms without persistent variable storage should behave. Here's my opening play:
Thanks a lot for getting this started!
Boot manager behaviour without persistent variable store
Platforms that do not implement persistent variable storage must support the Removable Media Boot Behaviour as described by UEFI.
Such platforms can additionally implement support for additional statically[1] defined images to be processed as SysPrep####,
What we have right now in U-Boot is partial support for dynamic variable storage. The way it works is that during boot time, variable store exists and is mutable and fully mapped to U-Boot environment variables which may well be stored on the ESP.
We're missing logic to actually persist the variables on exit boot services today.
So yes, statically defining them (via U-Boot enironment variables, but that's an implementation detail) sounds like a great first approximation to me.
Driver#### and Boot### global variable entries. If present, these entries will be processed in the order specified by corresponding statically defined SysPrepOrder, DriverOrder and BootOrder global variables.
Currently the "bootefi bootmgr" command only implements "BootOrder".
Any images referred to by such variables must reside in a vendor-specific subdirectory on the EFI System Partition, as recorded in http://uefi.org/registry. /BOOT must not be used except where explicitly permitted by UEFI.
Where an executable is present in the prescribed Removable Media location, boot of that must be attempted, and only after this fails should any of the Boot#### entries be processed.
Statically configured BootNext, OsRecovery#### or PlatformRecovery#### entries must not be used.
We should also mention that all variable accesses during runtime must return DEVICE_ERROR and that this is the way an OS can determine that persistent variable store is not available.
That's a pretty big hammer to tell the OS that SetVariable() is not available. That prevents using variables to communicate any information to the OS. Could we instead define a capability variable to pass that information so that the boot configuration can still be passed through for the OS to query?
I guess that's possible (and not a bad idea), would render all our current distributions unable to cope with such a system though :).
Alex
On 04/26/2018 08:43 AM, Alexander Graf wrote:
On 04/26/2018 10:51 AM, Grant Likely wrote:
On 25/04/2018 19:34, Alexander Graf wrote:
On 25.04.18 19:54, Leif Lindholm wrote:
I took an action last week to provide a block of text for how platforms without persistent variable storage should behave. Here's my opening play:
Thanks a lot for getting this started!
Boot manager behaviour without persistent variable store
Platforms that do not implement persistent variable storage must support the Removable Media Boot Behaviour as described by UEFI.
Such platforms can additionally implement support for additional statically[1] defined images to be processed as SysPrep####,
What we have right now in U-Boot is partial support for dynamic variable storage. The way it works is that during boot time, variable store exists and is mutable and fully mapped to U-Boot environment variables which may well be stored on the ESP.
We're missing logic to actually persist the variables on exit boot services today.
So yes, statically defining them (via U-Boot enironment variables, but that's an implementation detail) sounds like a great first approximation to me.
Driver#### and Boot### global variable entries. If present, these entries will be processed in the order specified by corresponding statically defined SysPrepOrder, DriverOrder and BootOrder global variables.
Currently the "bootefi bootmgr" command only implements "BootOrder".
Can u-boot (or an EFI app) load a driver and have it persist? If yes, Can it persist just until ExitBootServices or can it persit to runtime time as well?
Any images referred to by such variables must reside in a vendor-specific subdirectory on the EFI System Partition, as recorded in http://uefi.org/registry. /BOOT must not be used except where explicitly permitted by UEFI.
Where an executable is present in the prescribed Removable Media location, boot of that must be attempted, and only after this fails should any of the Boot#### entries be processed.
This is the "priority" statement I think it problematic as discussed on todays call. I think Boot### should be followed if present but boot firmware writers should be cautioned not to hard code stupid stuff into them. (The tricky bit will, of course, be comming up with a definition of stupid stuff. A list of bad examples may be the best way to do this.)
Statically configured BootNext, OsRecovery#### or PlatformRecovery#### entries must not be used.
We should also mention that all variable accesses during runtime must return DEVICE_ERROR and that this is the way an OS can determine that persistent variable store is not available.
That's a pretty big hammer to tell the OS that SetVariable() is not available. That prevents using variables to communicate any information to the OS. Could we instead define a capability variable to pass that information so that the boot configuration can still be passed through for the OS to query?
I guess that's possible (and not a bad idea), would render all our current distributions unable to cope with such a system though :).
Alex
So on the call today I heard that an EBBR.0 OS (after ExitBootServices) should be prepared for: 1) A system that returns ERROR for Gets and Sets 2) A system that returns ERROR for Sets but Gets works 3) A system where Sets and Gets work and are persistent
Support for a platform that does not ERROR Sets but does not do non-volatile persistence will be discussed for EBBR.1 if we still think it has value and platforms that will need it are common enough.
I also heard that all platforms "can persist variables before exit boot services". Is this true today for u-boot based systems that have an env storage defined? What about u-boot based system that do not define any env storage and always rely on uEnv.txt etc?
Thanks, Bill
On Thu, Apr 26, 2018 at 12:52:04PM -0400, William Mills wrote:
Driver#### and Boot### global variable entries. If present, these entries will be processed in the order specified by corresponding statically defined SysPrepOrder, DriverOrder and BootOrder global variables.
Currently the "bootefi bootmgr" command only implements "BootOrder".
Can u-boot (or an EFI app) load a driver and have it persist? If yes, Can it persist just until ExitBootServices or can it persit to runtime time as well?
Any images referred to by such variables must reside in a vendor-specific subdirectory on the EFI System Partition, as recorded in http://uefi.org/registry. /BOOT must not be used except where explicitly permitted by UEFI.
Where an executable is present in the prescribed Removable Media location, boot of that must be attempted, and only after this fails should any of the Boot#### entries be processed.
This is the "priority" statement I think it problematic as discussed on todays call. I think Boot### should be followed if present but boot firmware writers should be cautioned not to hard code stupid stuff into them. (The tricky bit will, of course, be comming up with a definition of stupid stuff. A list of bad examples may be the best way to do this.)
Yes. This statement was based on my incorrect assumption that we were permitting systems without any persistent variable storage in the first revision of the spec. (As opposed to only systems that did not provide persistent variable storage at runtime.)
Statically configured BootNext, OsRecovery#### or PlatformRecovery#### entries must not be used.
We should also mention that all variable accesses during runtime must return DEVICE_ERROR and that this is the way an OS can determine that persistent variable store is not available.
That's a pretty big hammer to tell the OS that SetVariable() is not available. That prevents using variables to communicate any information to the OS. Could we instead define a capability variable to pass that information so that the boot configuration can still be passed through for the OS to query?
I guess that's possible (and not a bad idea), would render all our current distributions unable to cope with such a system though :).
Alex
So on the call today I heard that an EBBR.0 OS (after ExitBootServices) should be prepared for:
- A system that returns ERROR for Gets and Sets
- A system that returns ERROR for Sets but Gets works
- A system where Sets and Gets work and are persistent
Support for a platform that does not ERROR Sets but does not do non-volatile persistence will be discussed for EBBR.1 if we still think it has value and platforms that will need it are common enough.
Well, I was arguing for supporting that in EBBR.0 (since that matches the behaviour of some EDK2 ports), but I don't think that is something we would like to _add_ to EBBR.1 if it is not supported by EBBR.0.
I also heard that all platforms "can persist variables before exit boot services". Is this true today for u-boot based systems that have an env storage defined? What about u-boot based system that do not define any env storage and always rely on uEnv.txt etc?
Yes, this was the reason for my last request for clarification. And the view was that such systems will not be compliant with any version of the spec.
/ Leif
On Fri, Apr 27, 2018 at 09:58:07AM +0100, Leif Lindholm wrote:
This is the "priority" statement I think it problematic as discussed on todays call. I think Boot### should be followed if present but boot firmware writers should be cautioned not to hard code stupid stuff into them. (The tricky bit will, of course, be comming up with a definition of stupid stuff. A list of bad examples may be the best way to do this.)
Yes. This statement was based on my incorrect assumption that we were permitting systems without any persistent variable storage in the first revision of the spec. (As opposed to only systems that did not provide persistent variable storage at runtime.)
To be honest, I'm not sure there was 100% argeement either way on yesterday's call but we're definitely zooming in a bit. If only because there were too many "let's leave aside level 0/1 for the time being" to be sure where this all fits.
However it seems to be me to be *really* beguiling to combine:
1. A LoaderEntryOneShot set variable implementation that survives a warm boot
2. Support persistent variable storage from UEFI applications
3. (Almost) normal handling of boot variables (assume we still want fallback to removeable media mode if the other boot options fail?).
Seems like that would make it relatively easy (or at the least possible) to add special EBBR equivalents of efibootmgr/efivar and allow distro install flows to work like (almost) normal.
However, as I said above, I'm not sure if we are talking level 0 or level 1 here?
Daniel.
On 26.04.18 18:52, William Mills wrote:
On 04/26/2018 08:43 AM, Alexander Graf wrote:
On 04/26/2018 10:51 AM, Grant Likely wrote:
On 25/04/2018 19:34, Alexander Graf wrote:
On 25.04.18 19:54, Leif Lindholm wrote:
I took an action last week to provide a block of text for how platforms without persistent variable storage should behave. Here's my opening play:
Thanks a lot for getting this started!
Boot manager behaviour without persistent variable store
Platforms that do not implement persistent variable storage must support the Removable Media Boot Behaviour as described by UEFI.
Such platforms can additionally implement support for additional statically[1] defined images to be processed as SysPrep####,
What we have right now in U-Boot is partial support for dynamic variable storage. The way it works is that during boot time, variable store exists and is mutable and fully mapped to U-Boot environment variables which may well be stored on the ESP.
We're missing logic to actually persist the variables on exit boot services today.
So yes, statically defining them (via U-Boot enironment variables, but that's an implementation detail) sounds like a great first approximation to me.
Driver#### and Boot### global variable entries. If present, these entries will be processed in the order specified by corresponding statically defined SysPrepOrder, DriverOrder and BootOrder global variables.
Currently the "bootefi bootmgr" command only implements "BootOrder".
Can u-boot (or an EFI app) load a driver and have it persist?
Depends on what your definition of persist is :). U-Boot can run an EFI application that can register protocols. These protocols do not disappear after the application closed.
If yes, Can it persist just until ExitBootServices or can it persit to runtime time as well?
An application can register memory as runtime memory and install something there. I'm not sure what the best way would be to actually make it callable though.
Any images referred to by such variables must reside in a vendor-specific subdirectory on the EFI System Partition, as recorded in http://uefi.org/registry. /BOOT must not be used except where explicitly permitted by UEFI.
Where an executable is present in the prescribed Removable Media location, boot of that must be attempted, and only after this fails should any of the Boot#### entries be processed.
This is the "priority" statement I think it problematic as discussed on todays call. I think Boot### should be followed if present but boot firmware writers should be cautioned not to hard code stupid stuff into them. (The tricky bit will, of course, be comming up with a definition of stupid stuff. A list of bad examples may be the best way to do this.)
Statically configured BootNext, OsRecovery#### or PlatformRecovery#### entries must not be used.
We should also mention that all variable accesses during runtime must return DEVICE_ERROR and that this is the way an OS can determine that persistent variable store is not available.
That's a pretty big hammer to tell the OS that SetVariable() is not available. That prevents using variables to communicate any information to the OS. Could we instead define a capability variable to pass that information so that the boot configuration can still be passed through for the OS to query?
I guess that's possible (and not a bad idea), would render all our current distributions unable to cope with such a system though :).
Alex
So on the call today I heard that an EBBR.0 OS (after ExitBootServices) should be prepared for:
- A system that returns ERROR for Gets and Sets
- A system that returns ERROR for Sets but Gets works
In this case you also want to have an indication to the OS that while variables exist, writes do not work.
- A system where Sets and Gets work and are persistent
Support for a platform that does not ERROR Sets but does not do non-volatile persistence will be discussed for EBBR.1 if we still think it has value and platforms that will need it are common enough.
I also heard that all platforms "can persist variables before exit boot services". Is this true today for u-boot based systems that have an env storage defined? What about u-boot based system that do not define any env storage and always rely on uEnv.txt etc?
U-Boot supports storing its environment in a file on a partition. And since the UEFI environment is part of the U-Boot environment, persistence works the same way.
Keep in mind that the persisting code path does not exist yet today though. U-Boot only knows how to save *all* of its current environment. To persist UEFI variables we would need to add functionality to only save the UEFI variables in the environment, but not the U-Boot ones.
Alex
On 26/04/2018 17:52, William Mills wrote:
On 04/26/2018 08:43 AM, Alexander Graf wrote:
On 04/26/2018 10:51 AM, Grant Likely wrote:
On 25/04/2018 19:34, Alexander Graf wrote:
On 25.04.18 19:54, Leif Lindholm wrote:
I took an action last week to provide a block of text for how platforms without persistent variable storage should behave. Here's my opening play:
Thanks a lot for getting this started!
Boot manager behaviour without persistent variable store
Platforms that do not implement persistent variable storage must support the Removable Media Boot Behaviour as described by UEFI.
Such platforms can additionally implement support for additional statically[1] defined images to be processed as SysPrep####,
What we have right now in U-Boot is partial support for dynamic variable storage. The way it works is that during boot time, variable store exists and is mutable and fully mapped to U-Boot environment variables which may well be stored on the ESP.
We're missing logic to actually persist the variables on exit boot services today.
So yes, statically defining them (via U-Boot enironment variables, but that's an implementation detail) sounds like a great first approximation to me.
Driver#### and Boot### global variable entries. If present, these entries will be processed in the order specified by corresponding statically defined SysPrepOrder, DriverOrder and BootOrder global variables.
Currently the "bootefi bootmgr" command only implements "BootOrder".
Can u-boot (or an EFI app) load a driver and have it persist? If yes, Can it persist just until ExitBootServices or can it persit to runtime time as well?
Any images referred to by such variables must reside in a vendor-specific subdirectory on the EFI System Partition, as recorded in http://uefi.org/registry. /BOOT must not be used except where explicitly permitted by UEFI.
Where an executable is present in the prescribed Removable Media location, boot of that must be attempted, and only after this fails should any of the Boot#### entries be processed.
This is the "priority" statement I think it problematic as discussed on todays call. I think Boot### should be followed if present but boot firmware writers should be cautioned not to hard code stupid stuff into them. (The tricky bit will, of course, be comming up with a definition of stupid stuff. A list of bad examples may be the best way to do this.)
Statically configured BootNext, OsRecovery#### or PlatformRecovery#### entries must not be used.
We should also mention that all variable accesses during runtime must return DEVICE_ERROR and that this is the way an OS can determine that persistent variable store is not available.
That's a pretty big hammer to tell the OS that SetVariable() is not available. That prevents using variables to communicate any information to the OS. Could we instead define a capability variable to pass that information so that the boot configuration can still be passed through for the OS to query?
I guess that's possible (and not a bad idea), would render all our current distributions unable to cope with such a system though :).
Alex
So on the call today I heard that an EBBR.0 OS (after ExitBootServices) should be prepared for:
- A system that returns ERROR for Gets and Sets
- A system that returns ERROR for Sets but Gets works
- A system where Sets and Gets work and are persisten
I've had a bit more of a think about this, and I would like to propose a different list. First, I think we should require that GetVariable() always works, and it should match whatever was in the UEFI variables during boot services. This should not be onerous to implement for anyone as it only requires the variables to be preserved in a UEFI memory region.
I also think I too quickly discounted systems where SetVariable() never works. HiKey for instance falls into that category. Maybe we still need to support that for EBBR.0
New list of systems to be prepared for: 1) SetVariable() never works (return EFI_WRITE_PROTECTED?) 2) SetVariable() only works at boot time (return EFI_WRITE_PROTECTED at runtime?) 3) SetVariable() works at both boot and runtime
Support for a platform that does not ERROR Sets but does not do non-volatile persistence will be discussed for EBBR.1 if we still think it has value and platforms that will need it are common enough
I think that's fair. non-persistant SetVariable() pulls in a lot of questions about what the reboot behaviour needs to be, so I'd like to punt it out to the EBBR.1 (liking the EBBR.# terminology BTW)
I also heard that all platforms "can persist variables before exit boot services". Is this true today for u-boot based systems that have an env storage defined? What about u-boot based system that do not define any env storage and always rely on uEnv.txt etc?
I think this fits into the new list described above. If firmware uses uEnv.txt, then SetVariable() should only work if firmware is able to update that file. Otherwise return an error (again, proposing EFI_WRITE_PROTECTED as above, but open to suggestions).
g.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Fri, Apr 27, 2018 at 11:22:27AM +0100, Grant Likely wrote:
On 26/04/2018 17:52, William Mills wrote:
On 04/26/2018 08:43 AM, Alexander Graf wrote:
On 04/26/2018 10:51 AM, Grant Likely wrote:
On 25/04/2018 19:34, Alexander Graf wrote:
On 25.04.18 19:54, Leif Lindholm wrote:
I took an action last week to provide a block of text for how platforms without persistent variable storage should behave. Here's my opening play:
Thanks a lot for getting this started!
Boot manager behaviour without persistent variable store
Platforms that do not implement persistent variable storage must support the Removable Media Boot Behaviour as described by UEFI.
Such platforms can additionally implement support for additional statically[1] defined images to be processed as SysPrep####,
What we have right now in U-Boot is partial support for dynamic variable storage. The way it works is that during boot time, variable store exists and is mutable and fully mapped to U-Boot environment variables which may well be stored on the ESP.
We're missing logic to actually persist the variables on exit boot services today.
So yes, statically defining them (via U-Boot enironment variables, but that's an implementation detail) sounds like a great first approximation to me.
Driver#### and Boot### global variable entries. If present, these entries will be processed in the order specified by corresponding statically defined SysPrepOrder, DriverOrder and BootOrder global variables.
Currently the "bootefi bootmgr" command only implements "BootOrder".
Can u-boot (or an EFI app) load a driver and have it persist? If yes, Can it persist just until ExitBootServices or can it persit to runtime time as well?
Any images referred to by such variables must reside in a vendor-specific subdirectory on the EFI System Partition, as recorded in http://uefi.org/registry. /BOOT must not be used except where explicitly permitted by UEFI.
Where an executable is present in the prescribed Removable Media location, boot of that must be attempted, and only after this fails should any of the Boot#### entries be processed.
This is the "priority" statement I think it problematic as discussed on todays call. I think Boot### should be followed if present but boot firmware writers should be cautioned not to hard code stupid stuff into them. (The tricky bit will, of course, be comming up with a definition of stupid stuff. A list of bad examples may be the best way to do this.)
Statically configured BootNext, OsRecovery#### or PlatformRecovery#### entries must not be used.
We should also mention that all variable accesses during runtime must return DEVICE_ERROR and that this is the way an OS can determine that persistent variable store is not available.
That's a pretty big hammer to tell the OS that SetVariable() is not available. That prevents using variables to communicate any information to the OS. Could we instead define a capability variable to pass that information so that the boot configuration can still be passed through for the OS to query?
I guess that's possible (and not a bad idea), would render all our current distributions unable to cope with such a system though :).
Alex
So on the call today I heard that an EBBR.0 OS (after ExitBootServices) should be prepared for:
- A system that returns ERROR for Gets and Sets
- A system that returns ERROR for Sets but Gets works
- A system where Sets and Gets work and are persisten
I've had a bit more of a think about this, and I would like to propose a different list. First, I think we should require that GetVariable() always works, and it should match whatever was in the UEFI variables during boot services. This should not be onerous to implement for anyone as it only requires the variables to be preserved in a UEFI memory region.
I also think I too quickly discounted systems where SetVariable() never works. HiKey for instance falls into that category. Maybe we still need to support that for EBBR.0
That sounds rather close to circular logic.
Boards that don't implement working SetVariable() today, do so because there was no really much compelling reason to support SetVariable() from UEFI apps; in other words there were no UEFI apps (that the vendor cared about) that actually needed it.
Based on the what we were talking about a couple of weeks back we don't want EBBR to be aspirational. I agree with this but didn't we define "not aspirational", at least approximately, as only specifying features that:
1. Can be implemented in u-boot before we ship, and realized on a reference platform
2. Can be implemented in EDK2 before we ship, and realized on a reference platform
3. Are not known to be impossible to implement on existing hardware (we might not get this 100% correct... but across the current people involved we have a good deal of experience)
Cataloguing current behaviour (of hikey or any other board) doesn't fit with they above. Looking at this a different way EBBR might be interested in formalizing de-facto standard approachs but IMHO its only a de-facto standard when it is common on firmware side *and* commonly exploited on the distro side.
Support for a platform that does not ERROR Sets but does not do non-volatile persistence will be discussed for EBBR.1 if we still think it has value and platforms that will need it are common enough
I think that's fair. non-persistant SetVariable() pulls in a lot of questions about what the reboot behaviour needs to be, so I'd like to punt it out to the EBBR.1 (liking the EBBR.# terminology BTW)
I agree here, there simply is not much prior art w.r.t. firmware that carries volatile data across a reset, that makes it risky for level 0.
I also heard that all platforms "can persist variables before exit boot services". Is this true today for u-boot based systems that have an env storage defined? What about u-boot based system that do not define any env storage and always rely on uEnv.txt etc?
I think this fits into the new list described above. If firmware uses uEnv.txt, then SetVariable() should only work if firmware is able to update that file. Otherwise return an error (again, proposing EFI_WRITE_PROTECTED as above, but open to suggestions).
Going back to the numbered list above, there is a huge different between not-implemented and not-implementable. We should be careful reasoning from the former. Sure u-boot ports exist without comprehensive driver support... ironically these are likely to be more common for systems that rely heavily on the u-boot distro boot protocol since the protocol gets close to eliminating the need for persistent runtime-modifiable variables.
Daniel.
I am behind this topic and not familiar with embedded system with U-boot. Some dumb questions below. Why there is no persistent storage on platform? I thought at least EEPROM is on platform. Can't EEPROM be the varstore for EFI variable? Or EEPROM is not allowed to write when during runtime? If EEPROM is not possible to be varstore, how about a region from on-board fixed storage? To simulate a partition as EFI varstore from on-platform storage for EFI variable read/write. And what is the problem that U-boot can't support SetVariable invoked by OS in runtime?
One comment to support EFI variable in U-Boot is to refer to the implementation in EDK2 EFI variable. In EDK2 variable design, another protocol "Firmware Volume Block Protocol" which defined in EFI PI (Platform Initialization spec ) is used as the abstract layer to abstract storage mechanism from EFI variable driver. The underlying implementation of FVB protocol could access to any kind of storage, such as non-volatile flash, memory, disk or any, that is platform-specific implementation. We probably can apply the same concept of PI spec and edk2 variable implementation on U-Boot UEFI implementation. U-Boot Just provide the generic EFI Variable complaint driver and leave varstore implementation to platform designer. My two cents.
- Abner
-----Original Message----- From: arm.ebbr-discuss-bounces@arm.com [mailto:arm.ebbr-discuss-bounces@arm.com] On Behalf Of Daniel Thompson Sent: Friday, April 27, 2018 10:41 PM To: Grant Likely grant.likely@arm.com Cc: Architecture Mailman List boot-architecture@lists.linaro.org; Boot@cam-list1.cambridge.arm.com; arm.ebbr-discuss@arm.com; Leif@cam-list1.cambridge.arm.com Subject: Re: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent variables
On Fri, Apr 27, 2018 at 11:22:27AM +0100, Grant Likely wrote:
On 26/04/2018 17:52, William Mills wrote:
On 04/26/2018 08:43 AM, Alexander Graf wrote:
On 04/26/2018 10:51 AM, Grant Likely wrote:
On 25/04/2018 19:34, Alexander Graf wrote:
On 25.04.18 19:54, Leif Lindholm wrote:
I took an action last week to provide a block of text for how platforms without persistent variable storage should behave. Here's my opening play:
Thanks a lot for getting this started!
Boot manager behaviour without persistent variable store
Platforms that do not implement persistent variable storage must support the Removable Media Boot Behaviour as described by UEFI.
Such platforms can additionally implement support for additional statically[1] defined images to be processed as SysPrep####,
What we have right now in U-Boot is partial support for dynamic variable storage. The way it works is that during boot time, variable store exists and is mutable and fully mapped to U-Boot environment variables which may well be stored on the ESP.
We're missing logic to actually persist the variables on exit boot services today.
So yes, statically defining them (via U-Boot enironment variables, but that's an implementation detail) sounds like a great first approximation to me.
Driver#### and Boot### global variable entries. If present, these entries will be processed in the order specified by corresponding statically defined SysPrepOrder, DriverOrder and BootOrder global variables.
Currently the "bootefi bootmgr" command only implements "BootOrder".
Can u-boot (or an EFI app) load a driver and have it persist? If yes, Can it persist just until ExitBootServices or can it persit to runtime time as well?
Any images referred to by such variables must reside in a vendor-specific subdirectory on the EFI System Partition, as recorded in http://uefi.org/registry. /BOOT must not be used except where explicitly permitted by UEFI.
Where an executable is present in the prescribed Removable Media location, boot of that must be attempted, and only after this fails should any of the Boot#### entries be processed.
This is the "priority" statement I think it problematic as discussed on todays call. I think Boot### should be followed if present but boot firmware writers should be cautioned not to hard code stupid stuff into them. (The tricky bit will, of course, be comming up with a definition of stupid stuff. A list of bad examples may be the best way to do this.)
Statically configured BootNext, OsRecovery#### or PlatformRecovery#### entries must not be used.
We should also mention that all variable accesses during runtime must return DEVICE_ERROR and that this is the way an OS can determine that persistent variable store is not available.
That's a pretty big hammer to tell the OS that SetVariable() is not available. That prevents using variables to communicate any information to the OS. Could we instead define a capability variable to pass that information so that the boot configuration can still be passed through for the OS to query?
I guess that's possible (and not a bad idea), would render all our current distributions unable to cope with such a system though :).
Alex
So on the call today I heard that an EBBR.0 OS (after ExitBootServices) should be prepared for:
- A system that returns ERROR for Gets and Sets
- A system that returns ERROR for Sets but Gets works
- A system where Sets and Gets work and are persisten
I've had a bit more of a think about this, and I would like to propose a different list. First, I think we should require that GetVariable() always works, and it should match whatever was in the UEFI variables during boot services. This should not be onerous to implement for anyone as it only requires the variables to be preserved in a UEFI memory region.
I also think I too quickly discounted systems where SetVariable() never works. HiKey for instance falls into that category. Maybe we still need to support that for EBBR.0
That sounds rather close to circular logic.
Boards that don't implement working SetVariable() today, do so because there was no really much compelling reason to support SetVariable() from UEFI apps; in other words there were no UEFI apps (that the vendor cared about) that actually needed it.
Based on the what we were talking about a couple of weeks back we don't want EBBR to be aspirational. I agree with this but didn't we define "not aspirational", at least approximately, as only specifying features that:
1. Can be implemented in u-boot before we ship, and realized on a reference platform
2. Can be implemented in EDK2 before we ship, and realized on a reference platform
3. Are not known to be impossible to implement on existing hardware (we might not get this 100% correct... but across the current people involved we have a good deal of experience)
Cataloguing current behaviour (of hikey or any other board) doesn't fit with they above. Looking at this a different way EBBR might be interested in formalizing de-facto standard approachs but IMHO its only a de-facto standard when it is common on firmware side *and* commonly exploited on the distro side.
Support for a platform that does not ERROR Sets but does not do non-volatile persistence will be discussed for EBBR.1 if we still think it has value and platforms that will need it are common enough
I think that's fair. non-persistant SetVariable() pulls in a lot of questions about what the reboot behaviour needs to be, so I'd like to punt it out to the EBBR.1 (liking the EBBR.# terminology BTW)
I agree here, there simply is not much prior art w.r.t. firmware that carries volatile data across a reset, that makes it risky for level 0.
I also heard that all platforms "can persist variables before exit boot services". Is this true today for u-boot based systems that have an env storage defined? What about u-boot based system that do not define any env storage and always rely on uEnv.txt etc?
I think this fits into the new list described above. If firmware uses uEnv.txt, then SetVariable() should only work if firmware is able to update that file. Otherwise return an error (again, proposing EFI_WRITE_PROTECTED as above, but open to suggestions).
Going back to the numbered list above, there is a huge different between not-implemented and not-implementable. We should be careful reasoning from the former. Sure u-boot ports exist without comprehensive driver support... ironically these are likely to be more common for systems that rely heavily on the u-boot distro boot protocol since the protocol gets close to eliminating the need for persistent runtime-modifiable variables.
Daniel. _______________________________________________ Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
On 28 April 2018 at 15:46, Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com wrote:
I am behind this topic and not familiar with embedded system with U-boot. Some dumb questions below. Why there is no persistent storage on platform? I thought at least EEPROM is on platform. Can't EEPROM be the varstore for EFI variable? Or EEPROM is not allowed to write when during runtime? If EEPROM is not possible to be varstore, how about a region from on-board fixed storage? To simulate a partition as EFI varstore from on-platform storage for EFI variable read/write. And what is the problem that U-boot can't support SetVariable invoked by OS in runtime?
One comment to support EFI variable in U-Boot is to refer to the implementation in EDK2 EFI variable. In EDK2 variable design, another protocol "Firmware Volume Block Protocol" which defined in EFI PI (Platform Initialization spec ) is used as the abstract layer to abstract storage mechanism from EFI variable driver. The underlying implementation of FVB protocol could access to any kind of storage, such as non-volatile flash, memory, disk or any, that is platform-specific implementation. We probably can apply the same concept of PI spec and edk2 variable implementation on U-Boot UEFI implementation. U-Boot Just provide the generic EFI Variable complaint driver and leave varstore implementation to platform designer.
The limitations are not in the software but in the hardware. Embedded or mobile platforms typically only have a single storage device that sits behind a controller that is either owned by the firmware or by the OS, but not by both at the same time. MMC even has boot partitions and RPMB partitions beyond the primary storage area so that boot images, file systems and secure storage can all share the same flash device.
The same applies to EEPROMs on I2C: unless the platform has been carefully architected so that the I2C bus that hosts the EEPROM can be owned by the firmware entirely, you end up in a similar situation where both the firmware and the OS need to access MMIO control registers, and the UEFI spec does not provide any means of arbitration between the two.
Therefore, it makes little sense to try and reason about which piece of software does what and whether it is generic or provided by the platform.
Hi Ard,
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Sunday, April 29, 2018 12:21 AM To: Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com Cc: Daniel Thompson daniel.thompson@linaro.org; Grant Likely grant.likely@arm.com; Architecture Mailman List <boot- architecture@lists.linaro.org>; Leif@cam-list1.cambridge.arm.com; Boot@cam-list1.cambridge.arm.com; arm.ebbr-discuss@arm.com Subject: Re: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent variables
On 28 April 2018 at 15:46, Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com wrote:
I am behind this topic and not familiar with embedded system with U-boot.
Some dumb questions below.
Why there is no persistent storage on platform? I thought at least EEPROM
is on platform. Can't EEPROM be the varstore for EFI variable? Or EEPROM is not allowed to write when during runtime? If EEPROM is not possible to be varstore, how about a region from on-board fixed storage? To simulate a partition as EFI varstore from on-platform storage for EFI variable read/write.
And what is the problem that U-boot can't support SetVariable invoked by
OS in runtime?
One comment to support EFI variable in U-Boot is to refer to the
implementation in EDK2 EFI variable.
In EDK2 variable design, another protocol "Firmware Volume Block
Protocol" which defined in EFI PI (Platform Initialization spec ) is used as the abstract layer to abstract storage mechanism from EFI variable driver. The underlying implementation of FVB protocol could access to any kind of storage, such as non-volatile flash, memory, disk or any, that is platform- specific implementation. We probably can apply the same concept of PI spec and edk2 variable implementation on U-Boot UEFI implementation. U-Boot Just provide the generic EFI Variable complaint driver and leave varstore implementation to platform designer.
The limitations are not in the software but in the hardware. Embedded or mobile platforms typically only have a single storage device that sits behind a controller that is either owned by the firmware or by the OS, but not by both at the same time. MMC even has boot partitions and RPMB partitions beyond the primary storage area so that boot images, file systems and secure storage can all share the same flash device.
The same applies to EEPROMs on I2C: unless the platform has been carefully architected so that the I2C bus that hosts the EEPROM can be owned by the firmware entirely, you end up in a similar situation where both the firmware and the OS need to access MMIO control registers, and the UEFI spec does not provide any means of arbitration between the two.
Therefore, it makes little sense to try and reason about which piece of software does what and whether it is generic or provided by the platform.
Normally firmware doesn’t access to varstore initiatively after ExitBootService. We actually can treat Runtime SetVariable () as part of OS driver. Just make sure the pointers used in runtime variable driver (and in firmware block driver) are translated to OS virtual address correctly. Also OS probably has to invoke SetVriable() in critical section or in higher priority threat. Then it should be ok to access to varstore under OS if low level FVB driver doesn’t reconfigure controller for varstore accesses. But access to varstore in MMC in both boot time and runtime is more complicated though, perhaps cache it in memory is more easier for varstore in partition case.
On 30 April 2018 at 15:57, Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com wrote:
Hi Ard,
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Sunday, April 29, 2018 12:21 AM To: Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com Cc: Daniel Thompson daniel.thompson@linaro.org; Grant Likely grant.likely@arm.com; Architecture Mailman List <boot- architecture@lists.linaro.org>; Leif@cam-list1.cambridge.arm.com; Boot@cam-list1.cambridge.arm.com; arm.ebbr-discuss@arm.com Subject: Re: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent variables
On 28 April 2018 at 15:46, Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com wrote:
I am behind this topic and not familiar with embedded system with U-boot.
Some dumb questions below.
Why there is no persistent storage on platform? I thought at least EEPROM
is on platform. Can't EEPROM be the varstore for EFI variable? Or EEPROM is not allowed to write when during runtime? If EEPROM is not possible to be varstore, how about a region from on-board fixed storage? To simulate a partition as EFI varstore from on-platform storage for EFI variable read/write.
And what is the problem that U-boot can't support SetVariable invoked by
OS in runtime?
One comment to support EFI variable in U-Boot is to refer to the
implementation in EDK2 EFI variable.
In EDK2 variable design, another protocol "Firmware Volume Block
Protocol" which defined in EFI PI (Platform Initialization spec ) is used as the abstract layer to abstract storage mechanism from EFI variable driver. The underlying implementation of FVB protocol could access to any kind of storage, such as non-volatile flash, memory, disk or any, that is platform- specific implementation. We probably can apply the same concept of PI spec and edk2 variable implementation on U-Boot UEFI implementation. U-Boot Just provide the generic EFI Variable complaint driver and leave varstore implementation to platform designer.
The limitations are not in the software but in the hardware. Embedded or mobile platforms typically only have a single storage device that sits behind a controller that is either owned by the firmware or by the OS, but not by both at the same time. MMC even has boot partitions and RPMB partitions beyond the primary storage area so that boot images, file systems and secure storage can all share the same flash device.
The same applies to EEPROMs on I2C: unless the platform has been carefully architected so that the I2C bus that hosts the EEPROM can be owned by the firmware entirely, you end up in a similar situation where both the firmware and the OS need to access MMIO control registers, and the UEFI spec does not provide any means of arbitration between the two.
Therefore, it makes little sense to try and reason about which piece of software does what and whether it is generic or provided by the platform.
Normally firmware doesn’t access to varstore initiatively after ExitBootService. We actually can treat Runtime SetVariable () as part of OS driver. Just make sure the pointers used in runtime variable driver (and in firmware block driver) are translated to OS virtual address correctly. Also OS probably has to invoke SetVriable() in critical section or in higher priority threat. Then it should be ok to access to varstore under OS if low level FVB driver doesn’t reconfigure controller for varstore accesses. But access to varstore in MMC in both boot time and runtime is more complicated though, perhaps cache it in memory is more easier for varstore in partition case.
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.
On 30 April 2018 at 16:00, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 30 April 2018 at 15:57, Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com wrote:
Hi Ard,
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Sunday, April 29, 2018 12:21 AM To: Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com Cc: Daniel Thompson daniel.thompson@linaro.org; Grant Likely grant.likely@arm.com; Architecture Mailman List <boot- architecture@lists.linaro.org>; Leif@cam-list1.cambridge.arm.com; Boot@cam-list1.cambridge.arm.com; arm.ebbr-discuss@arm.com Subject: Re: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent variables
On 28 April 2018 at 15:46, Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com wrote:
I am behind this topic and not familiar with embedded system with U-boot.
Some dumb questions below.
Why there is no persistent storage on platform? I thought at least EEPROM
is on platform. Can't EEPROM be the varstore for EFI variable? Or EEPROM is not allowed to write when during runtime? If EEPROM is not possible to be varstore, how about a region from on-board fixed storage? To simulate a partition as EFI varstore from on-platform storage for EFI variable read/write.
And what is the problem that U-boot can't support SetVariable invoked by
OS in runtime?
One comment to support EFI variable in U-Boot is to refer to the
implementation in EDK2 EFI variable.
In EDK2 variable design, another protocol "Firmware Volume Block
Protocol" which defined in EFI PI (Platform Initialization spec ) is used as the abstract layer to abstract storage mechanism from EFI variable driver. The underlying implementation of FVB protocol could access to any kind of storage, such as non-volatile flash, memory, disk or any, that is platform- specific implementation. We probably can apply the same concept of PI spec and edk2 variable implementation on U-Boot UEFI implementation. U-Boot Just provide the generic EFI Variable complaint driver and leave varstore implementation to platform designer.
The limitations are not in the software but in the hardware. Embedded or mobile platforms typically only have a single storage device that sits behind a controller that is either owned by the firmware or by the OS, but not by both at the same time. MMC even has boot partitions and RPMB partitions beyond the primary storage area so that boot images, file systems and secure storage can all share the same flash device.
The same applies to EEPROMs on I2C: unless the platform has been carefully architected so that the I2C bus that hosts the EEPROM can be owned by the firmware entirely, you end up in a similar situation where both the firmware and the OS need to access MMIO control registers, and the UEFI spec does not provide any means of arbitration between the two.
Therefore, it makes little sense to try and reason about which piece of software does what and whether it is generic or provided by the platform.
Normally firmware doesn’t access to varstore initiatively after ExitBootService. We actually can treat Runtime SetVariable () as part of OS driver. Just make sure the pointers used in runtime variable driver (and in firmware block driver) are translated to OS virtual address correctly. Also OS probably has to invoke SetVriable() in critical section or in higher priority threat. Then it should be ok to access to varstore under OS if low level FVB driver doesn’t reconfigure controller for varstore accesses. But access to varstore in MMC in both boot time and runtime is more complicated though, perhaps cache it in memory is more easier for varstore in partition case.
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.
(apologies, i hit send too quickly)
Also, eMMC controllers (which are more widely used on mobile platforms as the only available storage controller) use DMA under the OS, which complicates things even further when attempting to share such a controller between the OS and the firmware.
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Monday, April 30, 2018 10:02 PM To: Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com Cc: Daniel Thompson daniel.thompson@linaro.org; Grant Likely grant.likely@arm.com; 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 30 April 2018 at 16:00, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 30 April 2018 at 15:57, Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com wrote:
Hi Ard,
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Sunday, April 29, 2018 12:21 AM To: Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com Cc: Daniel Thompson daniel.thompson@linaro.org; Grant Likely grant.likely@arm.com; Architecture Mailman List <boot- architecture@lists.linaro.org>; Leif@cam-list1.cambridge.arm.com; Boot@cam-list1.cambridge.arm.com; arm.ebbr-discuss@arm.com Subject: Re: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent variables
On 28 April 2018 at 15:46, Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com wrote:
I am behind this topic and not familiar with embedded system with U-
boot.
Some dumb questions below.
Why there is no persistent storage on platform? I thought at least EEPROM
is on platform. Can't EEPROM be the varstore for EFI variable? Or EEPROM is not allowed to write when during runtime? If EEPROM is not possible to be varstore, how about a region from on-board fixed storage? To simulate a partition as EFI varstore from on-platform storage
for EFI variable read/write.
And what is the problem that U-boot can't support SetVariable invoked by
OS in runtime?
One comment to support EFI variable in U-Boot is to refer to the
implementation in EDK2 EFI variable.
In EDK2 variable design, another protocol "Firmware Volume Block
Protocol" which defined in EFI PI (Platform Initialization spec ) is used as the abstract layer to abstract storage mechanism from EFI variable driver. The underlying implementation of FVB protocol could access to any kind of storage, such as non-volatile flash, memory, disk or any, that is platform- specific implementation. We probably can apply the same concept of PI spec and edk2 variable implementation on U-Boot UEFI implementation. U-Boot Just provide the generic EFI Variable complaint driver and leave varstore
implementation to platform designer.
The limitations are not in the software but in the hardware. Embedded or mobile platforms typically only have a single storage device that sits behind a controller that is either owned by the firmware or by the OS, but not by both at the same time. MMC even has boot partitions and RPMB partitions beyond the primary storage area so that boot images, file systems and secure storage can all share
the same flash device.
The same applies to EEPROMs on I2C: unless the platform has been carefully architected so that the I2C bus that hosts the EEPROM can be owned by the firmware entirely, you end up in a similar situation where both the firmware and the OS need to access MMIO control registers, and the UEFI spec does not provide any means of arbitration
between the two.
Therefore, it makes little sense to try and reason about which piece of software does what and whether it is generic or provided by the
platform.
Normally firmware doesn’t access to varstore initiatively after
ExitBootService. We actually can treat Runtime SetVariable () as part of OS driver. Just make sure the pointers used in runtime variable driver (and in firmware block driver) are translated to OS virtual address correctly. Also OS probably has to invoke SetVriable() in critical section or in higher priority threat. Then it should be ok to access to varstore under OS if low level FVB driver doesn’t reconfigure controller for varstore accesses. But access to varstore in MMC in both boot time and runtime is more complicated though, perhaps cache it in memory is more easier for varstore in partition case.
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.
(apologies, i hit send too quickly)
Also, eMMC controllers (which are more widely used on mobile platforms as the only available storage controller) use DMA under the OS, which complicates things even further when attempting to share such a controller between the OS and the firmware.
Agree with this. May need other implementations like cache in memory during boot service and write back to partition by OS for this case.
On 04/30/2018 10:26 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
On 30 April 2018 at 16:00, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 30 April 2018 at 15:57, Chang, Abner (HPS SW/FW Technologist)
Also, eMMC controllers (which are more widely used on mobile platforms as the only available storage controller) use DMA under the OS, which complicates things even further when attempting to share such a controller between the OS and the firmware.
**
Agree with this. May need other implementations like cache in memory during boot service and write back to partition by OS for this case.
Strongly agree here. Working out such a procedure is the best option for platforms that do not have a dedicated SPI/I2C storage option that can be dedicated to firmware.
Also, eMMC controllers (which are more widely used on mobile platforms as the only available storage controller) use DMA under the OS, which complicates things even further when attempting to share such a controller between the OS and the firmware.
Agree with this. May need other implementations like cache in memory during boot service and write back to partition by OS for this case.
Do you mean, firmware will treat boot media as read-only. And any write to device should be done by OS itself . few questions on this 1/ Interface between OS and firmware 2/ At run time, if there is any update in UEFI variables, how to trigger OS for update
-----Original Message----- From: Udit Kumar [mailto:udit.kumar@nxp.com] Sent: Wednesday, May 02, 2018 12:31 PM To: Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com; Ard Biesheuvel ard.biesheuvel@linaro.org 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
Also, eMMC controllers (which are more widely used on mobile platforms as the only available storage controller) use DMA under the OS, which complicates things even further when attempting to share such a controller between the OS and the firmware.
Agree with this. May need other implementations like cache in memory during boot service and write back to partition by OS for this case.
Do you mean, firmware will treat boot media as read-only. And any write to device should be done by OS itself .
Yes. during runtime for EFI Variable in media case.
few questions on this 1/ Interface between OS and firmware
The only interface is SetVariable (). However, return meaningful EFI status to tell OS it has to write EFI variable by itself.
2/ At run time, if there is any update in UEFI variables, how to trigger OS for update
There is no way to trigger OS to do the update in EFI Variable driver. This is also the piece I do not have clear idea for EFI variable in media case so far. The only possible solution could be return EFI_UNSUPPORTED (instead of EFI_DEVICE_ERROR) in SetVariable() during runtime. Then somehow OS maintains EFI variable by its own way. However, in order to support unified OS, SFW will have to pass some information of EFI variable to OS. Such as where is the EFI Variable located, what's the protocol to access to EFI Variable and etc.
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.
/ Leif
-----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
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.
On Tue, May 08, 2018 at 11:57:38AM +0100, Daniel Thompson wrote:
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 was certainly not suggesting anything else, merely pointing out why Windows platforms don't have this problem.
If the EBBR is not OS neutral, it is pointless.
/ Leif
boot-architecture@lists.linaro.org
-
Alexander Graf -
Ard Biesheuvel -
Chang, Abner (HPS SW/FW Technologist) -
Daniel Thompson -
Grant Likely -
Leif Lindholm -
Udit Kumar -
William Mills