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 <[email protected]> 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.
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
