Bug#751704: sunxi MMC boot SPL vs. GPT partition (Re: Bug#751704: partman-base 173: partman overwrites parts of u-boot)
On Wed, Jun 18, 2014 at 08:43:46AM +0100, Ian Campbell wrote:
> On Tue, 2014-06-17 at 19:44 +0200, Karsten Merker wrote:
> 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?
No, there is no valid GPT, only a classic MBR, and large parts of the
GPT area are zeroed out.
> 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.
Thanks for the pointer to ped_disk_clobber in the libparted
sources - the source code there fits exactly to what I saw after
partman had overwritten the SPL. From ./libparted/disk.c,
function ped_disk_clobber:
/* How many sectors to zero out at each end.
This must be large enough to zero out the magic bytes
starting at offset 8KiB on a DASD partition table.
Doing the same from the end of the disk is probably
overkill, but at least on GPT, we do need to zero out
the final sector. */
const PedSector n_sectors = 9 * 1024 / dev->sector_size + 1;
In the sunxi case this results in 19 sectors with 512 bytes
each, i.e. exactly the area from offset 0x0000 to 0x25ff we see
zeroed out.
The libparted disk structure has an element "needs_clobber",
which seems to determine whether the first n_sectors of the
device are zeroed out or not by calling ped_disk_clobber upon
writing back the new partition table. I have currently no idea
whether this "needs_clobber" element is only for internal use in
libparted or whether this is intented to be manipulated by the
main program, but that might be a way to handle our problem. I
am very short on time at the moment and will probably not be able
to devote a noteworthy amount of time to the issue before the end
of next week, so I would appreciate very much if somebody else
could look further into this.
> 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.
Ack.
> 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).
The largest SD-card I have actually seen offered to end-users has
256GB and the SDXC spec allows sizes up to 2TB, so capacity-wise
there is no need for GPT on SD-cards (at least for the time
being). My comment
> > 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.
was mainly intended as reply to Lennart's mail about the problems
of getting GPT to work with the hardcoded bootloader addresses of
various SOCs and should not imply that there would currently be a
technical reason that would force us to use GPT on SD-cards.
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: