Live data from Hacker News

Realmode Assembly – Hello World Bootloader

0x00sec.org

11–13 of 13 posts

Re: Realmode Assembly – Hello World Bootloader

#11
post #7

Earlier quoted context omitted.

How much more complex would it be to set up protected mode and use it in assembly? Genuinely curious.

Actually it depends on how far you want to go. You can jump to protected mode with a few lines more. But you won't have a very interesting exercise. Basically, one would have to setup multiple registers like the GDT which sets the protection on different memory ranges (hence protected mode). Once you have your GDT setup, set a few bits in CR registers and execute a long jump to the code segment of the GDT (provided y…

The traditional ARM answer is that at a low level and at bootup the details are all very board specific -- what kind of BIOS equivalent you have (if any), where it starts you off, whether there's a bootloader like u-boot involved, where devices like the serial port are: all these things vary by board. For 64-bit ARM things are moving a bit more towards a standard setup with UEFI. In general, ARM assumes that the initial boot code will be customised for the specific chip, so unlike x86 which starts out looking like an 8086 until you flip it into protected mode, a 64-bit ARM CPU will start out in 64-bit and you can get at the backwards-compatibility 32-bit support by dropping down from 64-bit to 32. Back-compat is for applications, not OSes and bootloaders :-)

Re: Realmode Assembly – Hello World Bootloader

#12
post #7

Earlier quoted context omitted.

How much more complex would it be to set up protected mode and use it in assembly? Genuinely curious.

Actually it depends on how far you want to go. You can jump to protected mode with a few lines more. But you won't have a very interesting exercise. Basically, one would have to setup multiple registers like the GDT which sets the protection on different memory ranges (hence protected mode). Once you have your GDT setup, set a few bits in CR registers and execute a long jump to the code segment of the GDT (provided y…

this is a terrible hack, but if you leave the bios areas alone, you can make a system call like machine that downshifts back into real mode, makes the call, and shifts back up into protected mode (or all the way back up into 64 bit mode)

its not _really_ worth it, but if you're just noodling around and want to send packets or write to disks you don't have to write drivers. of course you have to have dedicated buffers visible in both spaces.

the only other reason i can think of to use real mode is to actually explore the segment model rather than just treating it as trash you have to walk over to get something up from reset...but it would probably be better just to invent some kind of segmented virtual machine

Re: Realmode Assembly – Hello World Bootloader

#13
post #4

A lot of people today dismiss realmode as being old and irrelevant for writing OSes, but IMHO the constraints of the environment are not going to be relevant if you're just starting out, and especially if you're working in Asm --- even if you stay within a single segment and ignore segmentation etc., you're "limited" to "only" 64KB of RAM, but that's already quite plenty to experiement with; keep in mind that the ori…

Because that's like teaching perl cgi in a web dev course. Sure you can do a lot, but that's not relevant to today's tech, does not give them any practical experience on real world architectures, and is very limited as to what they can achieve if they want to go further. As a final note, I find it rather annoying that the web is flooded of articles on how to create a basic bootloader/kernel in real mode and using the…

Because that's like teaching perl cgi in a web dev course.

"perl cgi" can be not used at all, but today's x86 machines still boot in realmode and you can already do a lot of interesting things there.

while there is a clear lack of good introductory articles on how to create minimalistic kernels using a stack like Core boot, uefi, TianoCore

That could be explained by the massive increase in complexity that UEFI entails compared to BIOS. Presumably it is only after you have gotten everything working with the BIOS that will prepare you to tackle UEFI; but speaking as someone with many years of experience with the former, and even read the BIOS source listings from the original IBM manuals, the UEFI spec was still ridiculously dense and if I were writing my own OS I would definitely choose the BIOS.

Related reading from someone who has written his own, now rather famous, OS: http://yarchive.net/comp/linux/efi.html

Post reply on HN