On 18 September 2017 at 13:47, Jeremy Linton <[email protected]> wrote: > On 09/18/2017 10:43 AM, Ard Biesheuvel wrote: >> >> On 18 September 2017 at 06:52, Udit Kumar <[email protected]> wrote: >>> >>> Hi EDK-2 Experts, >>> I am looking to store NV variables on SD/NAND device. >>> >>> While browsing, I came across some old post at link, >>> >>> http://feishare.com/efimail/messages/20130319-1700-Re__edk2__Regarding_storing_Boot_Device_Config_in_persistent_memory-Olivier_Martin.html >>> >>> Looks like, this is possible easily. >> >> >> That's a bold statement dude :-) >> >>>>> What you need to support Non-Volatile UEFI variables is a Non-Volatile >>>>> Memory. And also a driver that implements the EFI Firmware Volume Block >>>>> protocol for this NVM device. >>> >>> >>> But MdeModulePkg does Copymem from NV variable start memory to some >>> allocated buffers. With SD/NAND Copymem is not possible, Is this something >>> changes since 2013 or there are some other way to use SD/NAND >>> >> >> No, SD/MMC cannot currently be used as the backing store for the EFI >> variable store. The problem is that the variable protocols are >> architectural protocols in PI that need to be present before any >> driver model drivers are dispatched, and so putting the variable store >> on block devices is not something that the PI software architecture >> currently supports (unless you reimplement the whole driver stack as >> DXE drivers). >> >> On top of that, it is almost impossible to share a block device that >> sits behind a controller between the firmware and the OS at runtime >> (i.e., for SetVariable() calls made by efibootmgr under Linux), >> because only a single agent can take ownership of the controller at >> any given time. (You /could/ dedicate the SD/MMC to the firmware >> entirely, and boot from SATA or USB, but this is out of the question >> on most platforms that need to use SD/MMC for that variable backing >> store, i.e., mobile platforms) >> >> The best thing would be for you to convince the hardware architects in >> your company to design and implement dual-ported SD/MMC controllers >> that allow a single SD/MMC to have two logical views that are >> independent (although I'm unsure if that is even possible in the >> context of the SD/MMC specifications) > > > Which still has the problems of selecting "use whole disk" during an OS > install bricking the machine. Or similarly if the emmc layout isn't just > right having gparted automatically "fix" the partition table (as it does > with many of the hikey images) again bricking the machine. > > Having the firmware/variable store and OS root/boot on the same device is > fundamentally flawed. I've went down the path of simply disabling the > hikey/emmc for use beyond the firmware/variable storage on the hikey. Of > course I ran smack into the problem of making the block device DXE's > run-time safe which I've about concluded is far harder than simply writing a > monolithic variablestore->emmc driver. > > The ideal situation for the Hikey, is probably to solder a SPI flash to the > SPI controller and put the firmware/variable store on that, and leave the > eMMC entirely for linux's use. >
Oh, I completely agree that HiKey is a trainwreck in this regard. I asked for a 96boards mezzanine board with a SPI NOR more than 2 years ago so we could prototype this stuff properly, but it never materialized. But eMMC *can* potentially be used in a meaningful way, if we use a MMC boot partition for the UEFI image and the RPMB partition for the variable store (which would arguably be the only way to get a truly tamper proof *and* rollback protected varstore, which is what you minimally need to implement UEFI secure boot) _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
