flat_boot: A single-stage bootloader with a menu and more

[segfaultdev]

Hello! I have been working on a bootloader easy to use, customizable(via a config file) and full of features, but white fitting on just 512 bytes. This is not my first iteration, last one used a filesystem more like USTAR, this one uses a fully-featured filesystem. Here you have a link with more info: https://github.com/segfaultdev/flat_boot

It was originally made for my own OS, flat_core, but I decided to make it public for everyone to use on their OSes. I would also love to see some feedback about it.

Some screenshots:

[PeterX]

Not neccessary, but anyway an excellent piece! Nice

[bzt]

Your repo does not contain source nor a binary, so it is quite difficult to try it out. Are you planning to provide those? The flat-boot.c in your other repo does not have a menu nor a config parser, so I'm guessing this supposed to be a different flat-boot.

Cheers,
bzt

[segfaultdev]

Your repo does not contain source nor a binary, so it is quite difficult to try it out.

How could I have forgotten it! Now it is fixed.

The flat-boot.c in your other repo does not have a menu nor a config parser, so I'm guessing this supposed to be a different flat-boot.

You are right, that is an old version(that one was made in C and not in NASM, I later switched to the latter as code was too big).

[bzt]

How could I have forgotten it! Now it is fixed.

Cool, thanks! As for the loader, good job! It's amazing how much you could squeeze into 512 bytes!

Cheers,
bzt

[Octocontrabass]

fitting on just 512 bytes.

And without even using REP STOSW for your mem_set function? You just might have room for more features!

Unfortunately, FAT32 and exFAT reserve some space in the boot sector, so you would have even less room for code. You would probably have to split it across two sectors, and then it's not as much fun because you have more than 512 bytes to work with.

[segfaultdev]

And without even using REP STOSW for your mem_set function? You just might have room for more features!

I will find more tricks like the one you mentioned to make it even smaller, and then I could be able to add more features like to continue booting with the next bootable drive or more customization, thanks.

Unfortunately, FAT32 and exFAT reserve some space in the boot sector, so you would have even less room for code. You would probably have to split it across two sectors, and then it's not as much fun because you have more than 512 bytes to work with.

...and that is why I did not do it myself , as I would want to keep it in the first sector but I don't think I could.

[segfaultdev]

I now added a reboot option with F1, and made a release on GitHub.

I may also try to change the reboot key to F2 and add a help menu loaded from a help.txt file to F1, although it seems difficult having only 2 bytes left.

[Octocontrabass]

You might want to add a CLD instruction somewhere.

[segfaultdev]

You might want to add a CLD instruction somewhere.

I may also try to change the reboot key to F2 and add a help menu loaded from a help.txt file to F1, although it seems difficult having only 2 bytes left.

Well, I tried to make both changes by making it smaller to fit them, and I properly implemented the menu which shows the help.txt file on the screen, but now the problem is that my bootloader is 59 bytes too big, and I do not know how to make it smaller(I do not want to start using dirty tricks like writing into the null GDT entry, but it still would not fit). Is it even possible to do it?

This is the link to the new branch: https://github.com/segfaultdev/flat_boo ... evelopment

[bzt]

Well, I tried to make both changes by making it smaller to fit them, and I properly implemented the menu which shows the help.txt file on the screen, but now the problem is that my bootloader is 59 bytes too big, and I do not know how to make it smaller(I do not want to start using dirty tricks like writing into the null GDT entry, but it still would not fit). Is it even possible to do it?

Oh yes, there's still place for lots of optimizations Use the null GDT entry freely, that's common practice to put the GDT value there.

I've inlined some functions and rearranged things (which rendered some set register instructions unnecessary). With these, I've saved you 30 bytes (still 29 to go).

Notes: don't use pusha/popa that much in your internal functions. Instead try to figure out the registers and rely on their values. Your str_cmp could be improved too, not sure why you check 0xA after str_cmd_end label. Try to minimize direct memory addresses in instructions, as they need the most space.

Cheers,
bzt

[segfaultdev]

Oh yes, there's still place for lots of optimizations Use the null GDT entry freely, that's common practice to put the GDT value there.
I've inlined some functions and rearranged things (which rendered some set register instructions unnecessary). With these, I've saved you 30 bytes (still 29 to go).

Thanks a lot for the help, I did not know that you could use the null GDT entry. I managed to fit it by making both the help function and some more functions smaller, which also made me learn about INT 10h AH=13h.

Notes: don't use pusha/popa that much in your internal functions. Instead try to figure out the registers and rely on their values. Your str_cmp could be improved too, not sure why you check 0xA after str_cmd_end label. Try to minimize direct memory addresses in instructions, as they need the most space.

Maybe some day I will fix those things, but not now , as I would have to rewrite almost all of the code. And about str_cmp, you are right, that check is completely useless, cannot imagine what I was thinking of when I wrote it. Also, I learnt about cmpsb, and that made it quite smaller.

At the end I managed to add the help feature, just added it to have more features, as I cannot think of a great reason to use it. I will probably stop improving it for now and continue with my OS. Thanks to everyone who helped me.

Edit: I also made another release on GitHub if anyone wants to try it: https://github.com/segfaultdev/flat_boot.

[nexos]

Warning: dirty hack ahead. Once you've entered PMode and loaded the segment registers, you might could even overwrite other GDT entries, as the CPU caches them for faster access.