On Wed, Feb 27, 2013 at 12:33:45PM -0600, Bill Gatliff wrote: > Thing is, by the time you make a bootloader that intelligent, you are > well on your way to reinventing the things Linux+initramfs can already > do better---and that's even before you consider the device driver > implications. That's why I tend to go that route, rather than making > a super-bootloader.
I much prefer what openfirmware does. The firmware that comes with the system has functions to access disk, allocate memory, discover devices, etc. Then the bootloader (like grub) can use those functions to boot the system. Grub needs not know anything about the system, it just uses what is there. Just like it does on a PC with a BIOS or EFI. Sure grub needs to understand filesystems to load kernels, but that's OK. Something has to load your kernel+ramdisk from somewhere too before it can do the same job. Having to get device drivers for a given system and build a linux kernel that can deal with that certainly is far from universal and needs to be redone for every new system. What a pain in the ass. It is going the wrong way entirely. uboot happens to be both the firmware that initializes the hardware, and the bootloader, which is a bit of a mess as far as making things nice and clean. What is needed is for a standard interface like openfirmware to be done for arm systems, which the board maker then implements to provide the basic building blocks needed by a boot loader (and to initialize and detect the hardware). Then the boot loader becomes generic like it already is on a number of other systems. What you are doing is to me a terrible idea that I hate and have always hated. I hated it on the netwinder in the late 90s, I hated it on the alpha in the form of MILO. They were always getting out of date and would be unable to boot newer kernels and they were difficult if not impossible to get the full source code for in many cases (A problem I hope you are at least avoiding). -- Len Sorensen -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
