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.