You should be able to squeeze down the GPT header and entry array to reside in LBAs 1 to 16 and make the boot partition a real GPT partition as well. I didn't see anything in the GPT spec that specifies a minimum entry array size so 14 LBAs may be sufficient.
Is the hardcoded LBA 17 an eMMC specification thing? It seems the 'e' prefix doesn't stand for extensible. :) Eugene -----Original Message----- From: Grant Likely [mailto:grant.lik...@secretlab.ca] Sent: Tuesday, March 19, 2013 3:41 AM To: Olivier Martin Cc: Anmar Oueja; edk2-devel@lists.sourceforge.net Subject: Re: [edk2] Regarding storing Boot Device Config in persistent memory On Tue, Mar 19, 2013 at 9:00 AM, Olivier Martin <olivier.mar...@arm.com> wrote: > Hi Rony, > > on ARM Versatile Express the UEFI variables are stores on NOR Flash > (ArmPlatformPkg/Drivers/NorFlashDxe). > 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. > > I had a quick look to the Arndale features, I saw there is eMMC support. You > could use it as a NVM for your UEFI Variables. > > FYI, I worked on a prototype to store UEFI variables into a file of a file > system supported by UEFI (eg: Fat32 partition). But we should forget this > support. If you want to support Set/Get UEFI Variable from UEFI Runtime > Services, you should not access the file system from the Runtime Services. Hi Rony, This makes sense to me too and matches what we talked about. As far as I can tell, we pretty much have to treat the Arndale eMMC as "special" because the SoC is hardcoded to read the boot image from LBA 17 of the disk. This is already a problem for GPT partitioning as it falls smack in the middle of the GPT partition table[1]. Therefore the disk cannot be formatted as a normal disk. IIRC you brought this issue up when we met in December, but I don't think we settled on a solution. That gives us three choices; 1) don't expose the eMMC as a general purpose disk at all 2) Only allow MBR partitioning on the eMMC and create a special partition to hold eMMC data 3) Figure out how to make the boot code in LBA 17 look like a correct GPT partition #16 entry for a partition that cannot be used. (and possibly more entries that that depending on how large the initial boot code needs to be. The UEFI image would need to be relocated to a different part of the disk. No matter how it is sliced up, this is not going to be easy to solve generically. Is it possible at all to change the boot LBA used by the SoC? The ideal would be if the SoC could read the boot LBA out of a location in LBA0. Then we'd be able to partition the disk as normal and leave partitions aside for the UEFI image and for UEFI variable storage. I think for the time being we should focus support on option 1; dedicate the eMMC for UEFI's use and not try to use it as a real disk. We certainly shouldn't prevent people from using it as a disk, but it needs to be very clear that it is a special device and you cannot do "normal" disk things with it because overwriting LBA17+ will render the system unbootable. [1] http://en.wikipedia.org/wiki/GUID_Partition_Table* * I'm cheating by going to wikipedia instead of the spec > > Best Regards, > Olivier > > ________________________________________ > From: Rony Nandy [rony.na...@linaro.org] > Sent: 19 March 2013 06:35 > To: Olivier Martin > Cc: edk2-devel@lists.sourceforge.net; grant.lik...@linaro.org > Subject: Regarding storing Boot Device Config in persistent memory > > Hi Oliver, > > I am trying to fix a issue related to UEFI on > Arndale(https://bugs.launchpad.net/arndale/+bug/1131141).The Arndale > boards do not store the Boot Device config, meaning that each time the > board boots, it defaults to the config built into the image.Ideally, > the board should store the config in some persistent storage, eg, > flash or SD card. > > Do you have any suggestion as to where I need to work on to fix > this problem.How is this handled in VExpress? > > Regards > Rony > > > -- 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. > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
