On 30 April 2018 at 15:57, Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com> wrote: > Hi Ard, > >> -----Original Message----- >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >> Sent: Sunday, April 29, 2018 12:21 AM >> To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com> >> Cc: Daniel Thompson <daniel.thomp...@linaro.org>; Grant Likely >> <grant.lik...@arm.com>; Architecture Mailman List <boot- >> architect...@lists.linaro.org>; l...@cam-list1.cambridge.arm.com; >> b...@cam-list1.cambridge.arm.com; arm.ebbr-disc...@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.ch...@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. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
