eekee wrote:
I don't understand this. Fancy bootloaders can leave parts of the computer in unexpected states, especially on non-PC architectures. Even grub on PCs can leave the text-mode cursor enabled or disabled depending on its configuration. U-Boot on ARM selects seemingly random states for even MMU and CPU features, varying from board to board. Some say "Never use U-Boot," and I believe them. If you are stuck with (users using) U-boot you have to reinitialize everything, just as if there was no fancy bootloader in the first place.
The boot loader has one job: To load everything needed to boot. In the course of doing so, it may have need of the system's hardware in weird ways, yes. However, if U-Boot doesn't muck with the hardware, the firmware will. So you have to reinitialize everything, anyway.
eekee wrote:
Then there's multiboot, which is all touchy-feely "nice", but it's impossible to do right. The ELF standard is vast, no bootloader can implement all of it, so different bootloaders will inevitably implement different parts. If your architecture precludes linking, you don't want ELF object format, or even if you write your own ELF linker, you're in trouble because, when you write the ELF symbols for multiboot into your kernel image, you may not have selected the same parts of ELF as whichever bootloaders your users choose to use.
I have no idea what you mean by "vast" ELF standard. For static executables (which a kernel is, if the developers have any sense), ELF consists pretty much just of the ELF headers and the program headers. No symbol gets used anywhere. Now, the problem is that ELF is pretty much made for MMU systems, which most bootloaders don't set up. Which is why I have a separate loader application to get from multiboot or UEFI entry point to the environment my kernel likes.
eekee wrote:
For example, 9front has a toolchain older than ELF which is perfectly adequate for its own needs. "Multiboot support" is engineered into the kernel so it boots with grub, but it doesn't boot with syslinux. syslinux supports multiboot, so why doesn't it? syslinux's multiboot support must be different to grub's, so where's the "multi" in "multiboot"? pxelinux is part of the syslinux package, what if I want a boot menu on my diskless terminal?
When things like this happen, in my experience it almost always means you aren't following the standard, but rather, your deviations from the standard are tolerable to one implementation and not to another.