(seems like I didn't actually CC linux-sunxi when I said I would, oh
well, I may post a summary to that list later)
On Tue, 2014-06-17 at 19:44 +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.
Right :-/
> 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:
Looking at ./partman-partitioning/lib/disk-label.sh I see:
arm|armeb|armel|armhf)
echo msdos;;
which is overridden to GPT only if the device is >2TB. I think it is
unlikely that you are using an MMC >2TB so perhaps GPT is a red-herring?
Are you actually getting a valid GPT partition table after installing or
is that region just cleared/corrupted?
I suppose it is possible that something somewhere is wanting to zero the
GPT even in msdos mode (as you say below, perhaps to wipe any remains of
a GPT). I've a vague recollection of something like this affecting
another platform in Debian some time ago but I can't for the life of me
remember what it was or find a reference to it.
I think we could probably live with only supporting <2TB MMC so long as
>2TB SATA works (I've no reason to think it wouldn't), so we just need
to figure out what is changing those sectors.
Is there a size limit inherent in the MMC hardware?
http://en.wikipedia.org/wiki/MultiMediaCard suggests they max out at
128GB and mention a "MiCard" (never heard of that) variant which has a
"theoretical maximum size" of 2TB (but wikipedia mentions 8GB in
practice).
> 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.
I think this would be preferable to a1. And given the lack of 2TB MMC
cards in the world I think this would be acceptable overall.
(there was no b? I guess it became a2)
> 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.
As Lennart says this would risk incompatibilities with other OSes,
although I'm not sure how worried we are about preserving dual boot from
DI on these sunxi platforms though.
In any case those other OSes would have exactly the same problem with
GPT vs SPL that we are having...
One *really* ugly thing we could do is create a fake partition in
whichever entry happens to overlap the SPL entry point whose GUID etc
happen to look like a valid SPL + branch instruction to the full SPL at
a safer location. Really ugly, yukk...
Ian.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1403077426.18646.15.ca...@dagon.hellion.org.uk
