Gregory's Server@a1ba what are these stupid bootloaders even doing, what do they need to do past load the linux kernel into memory
|
12 comments
  @niconiconi @a1ba thanks for the informative reply to my snark haha. I wrote my own bootloader 22 years ago in one sector that could boot a raw payload from disk, and I forgot about things like serial drivers for keyboard where it's on an addon card or something like that.
@Moon @niconiconi @a1ba Writing bootloaders was fun back in the day. I wrote one for PDP-11 with 8-inch floppy, with the limiting factor it needing to fit into a 128-byte sector. Would not want to do anything in the area today.
https://people.redhat.com/zaitcev/d22_pub/dx_boot.p11  @niconiconi @Moon >You may as well just use a Linux kernel with kexec() as the bootloader. This is exactly the motivation of recently launched projects like LinuxBoot.
As far as I know, the reason why newer Elbrus machines has a 64 MB of on-board flash memory is to replace their bootloader with just Linux, that will do kexec(). @zaitcev @niconiconi @Moon Baget is the earliest computer on R500, right? I think I saw it mentioned somewhere once. I'm not sure if they maintain Solaris port for their SPARC machines nowadays.
@a1ba @Moon @niconiconi Here's a photo that I found. My note says "New spin of Baget-S after original version missed its clock target. 2.8M transistors, 150MHz, 0.35um CMOS process with 4 layers of metal.
1999-2001". I can't believe we could not crack 200 MHz. I thought we did, but that's how I wrote it down. @Moon @a1ba @niconiconi And the previous one was
"100 MHz (Actually - only 60) 0.5 um 3-layers CMOS ~2 M transistors 2 W Late 1997" |
@Moon@shitposter.club @a1ba@suya.place
> "what are these stupid bootloaders even doing, what do they need to do past load the linux kernel into memory"
GRUB 2 supports:* A complete I/O library memory management subsystem, to allow people to write extensions, just like kernel modules. An early demo was parting the entire Lua interpreter to GRUB (not part of the repo)
* Hardware-specific devices, such as serial port, PS/2, USB, and video / graphics. Because GRUB needs to work equally on all platforms, it mostly uses its own drivers instead of delegating the task to the boot firmware (on some embedded targets, GRUB itself can even be used as boot firmware).
* Graphics User Interface for boot theming, including decoders for custom images such as PNG, JPEG, and TGA.
* Localization to 20+ languages, with custom Unicode font support.
* Booting from a network, including PXE, HTTP, TFTP, so it has a TCP/IP stack and drivers for network providers such as OpenFireware, UEFI, and U-Boot.
* Parsing and listing partition tables.
* 20+ Filesystem drivers
* A basic sh-like command-shell that support sturctured programming, with ~50 built-in commands, such as ls, grep, cat, lspci, md5sum, hdparm, etc,.
All of these are arguably very useful features to many users. The shell is essential for troubleshooting, network boot is used for many diskless machines, almost all mainstream distros heavily use boot theming and localization, etc.
I think the real problem is that it's doing too much duplicate work. You may as well just use a Linux kernel with kexec() as the bootloader. This is exactly the motivation of recently launched projects like LinuxBoot.
@Moon@shitposter.club @a1ba@suya.place
> "what are these stupid bootloaders even doing, what do they need to do past load the linux kernel into memory"
GRUB 2 supports:* A complete I/O library memory management subsystem, to allow people to write extensions, just like kernel modules. An early demo was parting the entire Lua interpreter to GRUB (not part of the repo)
* Hardware-specific devices, such as serial port, PS/2, USB, and video / graphics. Because GRUB needs to work equally on all platforms,...