On Tue, Mar 19, 2013 at 9:00 AM, Olivier Martin <[email protected]> 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 [[email protected]]
> Sent: 19 March 2013 06:35
> To: Olivier Martin
> Cc: [email protected]; [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to