3 ms·
Not saying he is wrong or anything,but he seems to have missed how modern machines ship with UEFI which tries to solve this problem on firmware level. That sai
by josteink 10y ago
Not saying he is wrong or anything,but he seems to have missed how modern machines ship with UEFI which tries to solve this problem on firmware level.
That said: if you're curious and want to learn, I have no objections to digging into stuff, even "obsolete" stuff like BIOS boot :)
- joebergeron 10y agoThanks for giving it a look! You're certainly right about UEFI. I figured it would be easier and informative enough in the long run to just write a simple MBR bootloader instead of an EFI-format one. Either way, it was definitely fun.
- jaclaz 10y agoIt surely was fun, and I personally liked the way you detailed and commented the code, but that is not a bootloader, it is a bootload, i.e. something that is loaded at boot, executes some instructions and doesn't actually load anything. In the good ol' days there were tens of similar bootsectors (to be used on non bootable floppies) that could display mesages or draw ASCII art. If anyone wants to play with actual MBR bootloaders, a basic MBR is by Peter Anvin (and Andrea Mazzoleni) in makebootfat: http://www.advancemame.it/doc-makebootfat http://www.advancemame.it/doc-makebootfat and for an example of how much stuff you can actually put inside some 440 bytes, the base reference is mbldr: http://mbldr.sourceforge.net/ http://mbldr.sourceforge.net/
- slim 10y agoWhat would be the equivalent of this in UEFI? I mean is there a one page tutorial on booting with UEFI by writing a few lines of assembly?
- joebergeron 10y agoI actually looked this up after reading this comment. Best I could find after a quick google search was this: http://x86asm.net/articles/uefi-programming-first-steps/ http://x86asm.net/articles/uefi-programming-first-steps/ which is certainly not an easy tutorial to follow. Seems like more robustness tends towards a greater barrier to entry.
- exDM69 10y agoOnce you outgrow your boot sector space, writing a BIOS based bare metal project gets a lot harder as you need to start loading stuff from disk with more BIOS calls. It's a lot easier and nicer to use either UEFI or a Multiboot-protocol bootloader (GRUB, or qemu/bochs built-in bootloader). That also means you will be starting in long mode or protected mode. In order to work with bare metal efficiently, you need to get a debuggable and bootable ELF image up and running as soon as possible. Once you can attach a remote GDB debugger to Qemu, you get things done much faster than using the Qemu/Bochs monitor/debugger. Anything more complex than a hello world example is easier with UEFI or multiboot than BIOS boot sectors. You will need a linker script and a build script but things will be much easier after the first steps. I made this pull request for someone else's bare metal project to add debuggable ELF images. It's a small but practical example: https://github.com/Overv/MineAssemble/pull/5 https://github.com/Overv/MineAssemble/pull/5
- josteink 10y agoI found this article previously on HN: https://news.ycombinator.com/item?id=12238498 https://news.ycombinator.com/item?id=12238498 You may find it interesting. Basically you won't bother writing a bootloader with UEFI, since it already provides that feature. Instead you'll get right at working on your OS.
- deleted 10y ago[deleted]