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:
> CCing the linux-sunxi group.
> > 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?
>
> Hrm, that is rather unfortunate.
>
> 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.
>
> (I'm not all that hopeful, but worth checking)
TI, Freescale, etc all have this problem.
TI wants the boot loader either in a FAT partition that is flagged
bootable in a DOS partition table, or they want it to start at offset
512 bytes from the start. Fortunately they do support emmc boot partition
for boot code too, but that doesn't help for SATA or SD or anything else.
Hybrid partition table setup is about the only solution with using the
FAT partition to store the boot code.
Freescale's i.MX line puts the boot code at offset 1024 bytes from
the start and I don't beleive support any other method. My theory on a
work around though is that since GPT puts the header at 512 byte and the
first partition entry is at 1024 bytes and the partition entry starts
with a 16 byte UUID, the first partition entry could be used to create
a reserved area for the boot code after the GPT and the UUID could be
used to write jump code to jump to the real boot code just after the GPT.
Would probably need minor linking changes to u-boot to handle being
moved a tiny bit.
Of course another option is to have the boot code on SD or eMMC,
and have the boot code read the kernel and everything else from a SATA
drive or somethign else which does use GPT. Just a bit annoying to need
multiple devices.
--
Len Sorensen
Reply to: