-----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.