Bootloader design

[8infy]

How I plan on doing it is kind of complex, but here we go. The MBR code loads up stage 2. Stage 2 is two files concatenated with the cat command. The first one enters Protected Mode, and enables A20. It also relocates the second one, which is directly after. It then jumps to it. It is a C executable. When calling the BIOS, it will drop to real mode and call it, and then bounce back to PMode. Disk buffers will be put in a low memory temporary buffer, and then copied to the permanent buffer, which can be anywhere. Hopefully that makes sense and is of help.

Yeah that sounds good, what do you use to compile the C file? Thanks.

[nexos]

My OS is more Windows like, so MinGW for Linux, and it loads a PE. You could use a GCC cross compiler and load an ELF, or you could output a flat binary or MZ with Smaller C.

[Schol-R-LEA]

One thing I will suggest is that you need to think beyond just the bootloader itself, and consider how you are going to install the loader onto a given system (even if it is just a disk image for a VM). Especially if you intend to make your system installable onto different media, or onto systems which use UEFI. A good OS installer is in some ways as much a code generator and editor as it is an image writer.

[PeterX]

One thing I will suggest is that you need to think beyond just the bootloader itself, and consider how you are going to install the loader onto a given system (even if it is just a disk image for a VM). Especially if you intend to make your system installable onto different media, or onto systems which use UEFI. A good OS installer is in some ways as much a code generator and editor as it is an image writer.

I don't understand this.
Can't you just copy stage2 and the kernel to /boot/efi/ (or /boot/ or whatever your Linux distro uses to mount the ESP)? And doesn't Windows allow the user to copy files to the ESP?

And why is the installer a generator? An editor?

Greetings
Peter

[bzt]

I don't understand this.

Me neither, but I might have a clue what he could meant.

Can't you just copy stage2 and the kernel to /boot/efi/ (or /boot/ or whatever your Linux distro uses to mount the ESP)? And doesn't Windows allow the user to copy files to the ESP?

Yes, if your loader is smart enough. But there are other things, like being multiplatform or userland for example to beconsidered. How will you create a partition for those data in the first place? How would you access those? For a kernel that's fine to copy to ESP, but you can't put everything on the ESP (well, you can, but you probably shouldn't). If your OS uses ext2, then how would you use it under Win? These are not unsolvable problems, but definitely things to be sorted out.

And why is the installer a generator? An editor?

I believe what he meant is, you'll never need all the things all the time. For example there's no point in putting the AArch64 version of "ls" into an x86-only bootable image.

Cheers,
bzt

[Schol-R-LEA]

I had something a bit more immediate in mind: a first-stage boot loader designed for a BIOS system loading from a floppy will be different from one loading from a fixed drive, which in turn would differ from one booting from an El Torito CD (despite the latter's emulation functions). A BIOS system boots in a different way from a UEFI system, which realistically doesn't really need a first-stage loader at all in most cases, but does have its own way of interfacing with the kernel which the kernel needs to know about and handle sensibly. That sort of thing.

There's also the matter of tuning the boot process for the existing hardware, though that can be an open-ended sink for time and effort.

I'll admit that this is something of a gripe I have with a lot of loader designs, in that they stick to something very generic and as a result under-perform for most hardware. But then, I also favor source-based package management (in principle) for much the same reason, despite the fact that none of the existing ones are really usable (which is why I switched from Gentoo to Manjaro for my preferred Linux distro), so perhaps I am the crazy one here (I mean, I am crazy anyway, but... you know what I mean).

[bzt]

I had something a bit more immediate in mind: a first-stage boot loader designed for a BIOS system loading from a floppy will be different from one loading from a fixed drive, which in turn would differ from one booting from an El Torito CD

Ok, maybe for floppies, but if you move them out of the equation to solely rely on LBA, all the rest can use the same boot record (see my bootloader's boot.asm).

A BIOS system boots in a different way from a UEFI system, which realistically doesn't really need a first-stage loader at all in most cases, but does have its own way of interfacing with the kernel which the kernel needs to know about and handle sensibly. That sort of thing.

First part is true, but the second isn't. You can write a bunch of bootloaders in a way that they interface with the kernel exactly the same way, therefore the kernel doesn't need to know about the firmware at all. Actually that's the whole point of BOOTBOOT Protocol. Write your kernel once, and don't care on which platform it's booted on and how. (Being binary compatible on platforms with the same CPU, and source compatible for platforms with different CPUs.)

I also favor source-based package management (in principle) for much the same reason, despite the fact that none of the existing ones are really usable (which is why I switched from Gentoo to Manjaro for my preferred Linux distro), so perhaps I am the crazy one here (I mean, I am crazy anyway, but... you know what I mean).

Nope, I totally agree with you. And I also had to gave up on Gentoo, a change in emerge created a circular dependency hell with fast Furier transformation library. And I said: a) why on earth does a package manager need fast Furier transform in the first place? b) if I have to reinstall my entire system because of this stupid issue, do I really want to go with Gentoo again? Which is sad, because when there was no issues with emerge I really really liked that distro. It was comfortable (for me) and everything run lightning fast, perfectly tuned to my computer. Booted in less than a sec from turn on to X11 logon Do that with Bugbuntu!

Cheers,
bzt

[Octocontrabass]

I had something a bit more immediate in mind: a first-stage boot loader designed for a BIOS system loading from a floppy will be different from one loading from a fixed drive, which in turn would differ from one booting from an El Torito CD (despite the latter's emulation functions).

Floppy and hard drive bootloaders will be different, but El Torito emulation allows you to use both unmodified (provided they use BIOS calls to access the disk). I wouldn't say it's a good idea, but it will work.

There's also the matter of tuning the boot process for the existing hardware, though that can be an open-ended sink for time and effort.

I'll admit that this is something of a gripe I have with a lot of loader designs, in that they stick to something very generic and as a result under-perform for most hardware.

What exactly do you have in mind here?