On 03/07/2018 17:24, Grant Likely wrote:
On 03/07/2018 16:58, Daniel Thompson wrote:
On Tue, Jul 03, 2018 at 04:46:38PM +0100, Grant Likely wrote:
On 03/07/2018 10:08, Nicolas Dechesne wrote:
On Mon, Jul 2, 2018 at 11:59 PM Alexander Graf agraf@suse.de wrote:
On 02.07.18 20:40, William Mills wrote:
[...]
I am still trying to figure out if a real issue exists or will soon exist. If this issue is real, I think it should be addressed in UEFI but if not there then in EBBR. We move "disks" around a lot more than other people do.
Yes, let's double check with Hannes :).
On Dragonboard 820c, that has on board UFS disk:
Found valid GPT with protective MBR; using GPT. Disk /dev/sda: 6335488 sectors, 24.2 GiB Model: THGBF7G8K4LBATRB Sector size (logical/physical): 4096/4096 bytes
Hmmm. That's interesting. I had assumed that on UFS devices, device partitions would be used and the GPT would be omitted. Evidently that is not done on the 810c.
I might be missing something but can EFI run on top of raw hardware device partitions? I didn't think EFI provided any means to locate an ESP except when they are described in one of the three supported ways (GPT, MBR or El Torito).
It looks like UFS models partitions after iSCSI LUN. I suppose it is reasonable to assume that each LUN used to store an ESP or OS partitions will need also have a GPT.
At some point in the future it may make sense to explicitly define how to find the LUN that contains the ESP, but that would be in the scope of the UEFI spec, not EBBR.
It would be reasonable for one or more LUNs to be dedicated to firmware which gets us out of the shared ESP scenario and the OS can do what it wants with the GPT in the 'general-purpose' LUN.
Actually reading the UFS spec helps a lot! :-)
https://www.jedec.org/system/files/docs/JESD220D.pdf
Right, so UFS seems to support up to 128 partitions, or LUNs. It appears that each LUN can be treated as an separate block device. Up to 2 can be configured as boot LUNs (boot A and B), and one can be an RPMB. Size of the boot and RPMB regions is not fixed, so as much space as needed for firmware could be allocated.
I'm going to rework the text to talk about shared storage in terms of a single device or LUN. If firmware is contained in a separate LUN (one of the boot partitions), then it is outside the scope of EBBR.
It would be possible for separate LUNs to be allocated for each OS partition, but I don't think EBBR needs to tackle that. In that scenario each LUN would probably still need to have a GPT partition table, (or at the very least the LUN containing the ESP would). Each LUN would show up as a separate block device in Linux (I think). Yet I don't think that affects EBBR if EBBR treats each LUN as a separate block device. I imagine UEFI behaviour in that case would possibly to search each LUN for an ESP if the boot variables are not set.
I've also learned that removable UFS cards exist. If the platform strictly requires a UFS boot partition on the removable media, then that could be an issue for the firmware for multiple platforms on a single card use case. We could mitigate this by recommending a filesystem be used on the boot partition. I'm concerned about overreaching though.
g. 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.