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 10:20:38AM +0100, Ian Campbell wrote:
> > > The layout itself appears ok as the first partition starts at
> > > sector 2048, i.e. at 1MB offset, but comparing the state of the
> > > first MB of data on the device before and after partman has
> > > written the partition table shows that not only the partition
> > > table has been written, but also the area from offset 0x2000 up
> > > to 0x25ff has been zeroed out. On all Allwinner sunXi-based
> > > systems this area contains the u-boot SPL, without which the
> > > system cannot boot anymore.
[snip]
> > It sure would be nice if CPU makers would stop putting their boot code
> > where the GPT goes. Do none of them EVER think their device will want
> > to use a disk bigger than 2TB?
[snip]
> I think we have some flexibility in positioning for some of the bits
> which need to go onto the mmc. I don't know if the specific bit which
> conflicts with GPT is one of them though, but maybe things can be
> shuffled around.
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.
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.
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: