[U-Boot-Users] Re: A call for boot loader IDs

Hi,

in message bqqc9l$qo6$1@cesium.transmeta.com you wrote:

So far only a small number of boot loaders have actually officially registered their IDs, this is the list that I have:

I have to admit that I don't understand why such a registration is useful, but anyway...

type_of_loader:

What exactly is "type_of_loader" and where does it play a role? We never ran over it before...

    If your boot loader has an assigned id (see table below),
    enter 0xTV here, where T is an identifier for the boot loader
    and V is a version number.  Otherwise, enter 0xFF here.

    Assigned boot loader ids:
    0  LILO
    1  Loadlin
    2  bootsect-loader
    3  SYSLINUX
    4  EtherBoot
    5  ELILO

    Please contact <hpa@zytor.com> if you need a bootloader ID
    value assigned.

Please assign a bootloader ID for U-Boot, the "universal bootloader".

I would really appreciate if other boot loaders -- especially GRUB, which is widely used -- would let me know (a) what they are currently doing, and (b) whether or not they need an official allocation. It's probably unwise to not do so, at least for the ones which have a significant user community.

(a) U-Boot supports PowerPC, ARM, MIPS, NIOS, and x86 systems. The "official" source tree (http://sourceforge.net/projects/u-boot) has standard configurations for more than 160 boards (PowerPC: MPC5xx, MPC8xx, MPC5xxx, MPC824x, MPC826x, MPC85xx, PPC4xx, 7xx, 74xx; StrongARM; ARM7; ARM9; Xscale; MIPS 4kc, 5kc, au1x00; i486).

(b) I have no idea if we need a bootloader ID value assigned; please decide yourself.

The purpose of this ID is so we can work around individual boot loader issues if we should have a need to adjust or change the boot protocol. Not reporting a unique ID makes this impossible.

Please explain what you mean by "adjust or change the boot protocol". Sorry if I'm asking stupid questions, but all of this sounds a bit x86-centric to me, while U-Boot is mostly dealing with other architectures where things are more straight-forward than on x86.

Best regards,

Wolfgang Denk