On 2017/2/23 3:06, Ard Biesheuvel wrote:
On 22 February 2017 at 18:59, Alex Elder elder@linaro.org wrote:
On 02/22/2017 03:08 AM, Ard Biesheuvel wrote:
[...]
I don't think it is mandatory to use a GPT partition table. Did you try using MS-DOS format instead?
Unless I'm reading the spec wrong, I think you're right. It says that firmware adhering to the spec must support GPT partitioning (description of section 5 in table 1 in section 1.2). But later (section 12.3.2) it describes handling of media when there is *no* GPT header found. In that case, the contents of the MBR is consulted for partition information. http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf So it's OK for media to not use GPT, though UEFI firmware must be able to read GPT format media if it's used.
Section 5.2.3 defines a protective MBR, which is used if a legacy MBR is not used at offset 0. It could *maybe* be abused by using a non-standard value in the StartingLBA field (table 17 says it shall contain value 0x00000001). I don't want us to pretend to follow the spec but then not follow it exactly.
I have only just scanned through the GPT spec to collect this information. My feeling now is that we should plan to use a legacy (MS-DOS) MBR for the Poplar eMMC media.
If we simply put an MBR in sector 0 that does not cover sector 1 at all (or any subsequent sectors that are part of the primary boot image), I don't think we need to bother at all with GPTs or protective MBRs or anything else that is specific to UEFI. Let's just start the first partition at the next eraseblock boundary, and make it around 128 MB in size, so we can use it as the EFI System Partition (ESP).
I read some specs about MBR and GPT today. And I have a doubt about the number of partitions that MBR can support. The MBR only can support four primary partitions which maybe not enough for AOSP platform. So I don't know if it is a problem in Aspen project?