Bug#751704: sunxi MMC boot SPL vs. GPT partition (Re: Bug#751704: partman-base 173: partman overwrites parts of u-boot)
On Tue, Jun 17, 2014 at 07:44:36PM +0200, Karsten Merker wrote:
> Unfortunately the problematic part in this case is the SPL which
> is the only part of u-boot that cannot be relocated because its
> sector address is hardcoded in the SOC's BROM.
>
> I see two possible approaches to solve the conflict between SPL
> and GPT, although I do not know whether they are achievable with
> the currently available partman/libparted codebase:
>
> a1) Make partman only write a classic BIOS bootsector and ignore the
> GPT area when working on /dev/mmcblkX on sunxi-based systems.
> I suppose that writing to the GPT area happens only to make
> sure there are no remains of old GPT partition data
> contradicting the contents of the BIOS bootsector, so when
> taking this approach, the user would have to make sure that
> there are no GPT remains on the card.
>
> a2) Wipe the GPT header but not the whole GPT partition table.
> AFAICS if there is no valid header, the actual partition
> table is ignored, so just wiping the 512 bytes of the header
> block should be enough and would not impede the SPL. This
> solution would work even with "unclean" cards.
>
> c ) If we want to use GPT on the SD card, we could try to write
> the GPT in such a way that it does not impede u-boot.
>
> The layout of the first MB on a bootable sunxi MMC/SD card
> looks like follows:
>
> Offset Function
> ====== ========
> 0x00000000 MBR/partition table
> 0x00002000 SPL
> 0x00008000 u-boot code
> 0x00088000 u-boot environment data
> 0x000A8000 reserved space
> 0x00100000 start of the first partition
>
> The default GPT layout looks like follows (assuming a device
> with a blocksize of 512 bytes - the GPT layout is dependent
> on the blocksize):
>
> Offset Function
> ====== ========
> 0x00000000 MBR
> 0x00000200 GPT header
> 0x00000400 start of partition table
> 0x00004400 end of partition table
>
> -> the SPL area and the GPT partition table overlap.
>
> If I understand the GPT structure correctly, this is the
> default layout, but it is not the only valid layout. The GPT
> header contains a pointer to the start of the actual
> partition table and while it is common to put it directly
> after the GPT header, it AFAICS does not _have_ to be there.
> So it might be possible to use GPT and u-boot on the same
> device by putting the partition table (which has to be at
> least 16kB large) into the region between 0x000A8000 and
> 0x00100000. The GPT header has to stay at 0x00000200, but
> that does not matter as the header itself does not conflict
> with the SPL.
Well according to wikipedia the value of start is ALWAYS 2 (meaning
right after the header) in the primary table. It is wikipedia though
so it could be wrong.
Apple's documentation says it is 2. diskinternals.com says it is 2.
The linux efi partition parser uses what the header says. I do wonder
though if there isn't a very high chance of breaking compatibility
with some OSs if you don't use 2 as the LBA for the partition entry
start point.
> I would appreciate very much if somebody who is knowledgeable
> with regard to the internals of partman/libparted could take
> a look into these options.
--
Len Sorensen
Reply to: