On 06/17/2014 04:43 PM, Lennart Sorensen wrote:
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.
I think you all are missing the target...I think the installer on those (not-unified bootstrap method machines/SoC) systems are to be added in the installation procedure. i.e. If I am booting from a sunxi machine I have to deal with their structure __AND__ the choice of the user to define partition for their bootstrap device (SATA or eMMC/MMC/SD SSD whatever).
The same method (with different partition scheme, or MBR code or Partition ID) as to be choosen if I am booting from TI or FSL SoC. What about if I am booting the installer from USB CD then I wish to install Debian on NAND Flash?? The same problem I see.
To me, the __ONLY__ viable solution is to add the special partition/bootloader/spl area to the machine-specific installation procedure, so the user is UNABLE to change the boot-specific-part(itions) just to be sure to have a bootable system after installation.
So those installation methods need to know (and ofcourse provide) the bootloaders, the spl-codes and __maybe__ the specific kernel to deal the installation of Debian for __EACH__ architecture they wish to support.
Looking in the past (just for comparison) try to have a quick look on: - Debian Installation on Amiga m68k machines or - Debian Installation on Amiga PPC machines or - Debian Installation on PReP machines or - Debian Installation on PowerMac or M68k Apple MacIntosh- Debian Installation on AtariST machines or even Medusa Systems or DraCo Systems.
Each installation has the proper installer procedures and pro and cons...
Let me know what do you thinking..
Just my 2 $cent...
Regards,
--
,,,
(o o)
======oOO==(_)==OOo======
Gianluca Renzi
R&D
phone: +39.0542.609120
fax: +39.0542.609212
.oooO Oooo.
======( )==( )=======
\ ( ) /
\_) (_/
===================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(".)_/¯