
Realmode Assembly – Hello World Bootloader - miobrien
https://0x00sec.org/t/realmode-assembly-writing-bootable-stuff-part-2/2992
======
userbinator
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 original Unix, complete with shell,
utilities, kernel, etc., ran on a PDP-11 with a 64KB _total_ address space.

I used to teach an Asm course, and a lot of my students were wondering why we
started with 16-bit, single-segment DOS COM programs --- being used to multi-
KB or MB apps that don't do much, they thought it'd be impossible; and yet
came away with a completely new perspective on how far away that 64KB limit
seems, even if you're writing moderately complex programs.

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

~~~
xor42
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 you have instructions loaded there).

Then once in protected mode, everything changes. The system allows you to set
interrupts habdlndlers through the LIDT, to enable memory paging and you'll
have to reload the GDT again. But no more access to the convenient BIOS
functions.

You also set up the PIC of your system to get a ticking clock for scheduling
your kernel operations. Once you got all that is where the fun begins and you
can start implementing memory managers and allocators, writing a disk
operations layer and implement (or write your own!) filesystem.

OS Dev is truly a fascinating subject because there's so much to learn. Even
more with 64-bit, and multiple core initialization and usage.

I don't know how all of this works on ARM, but I might order myself an
experimentation board to get my hands on.

~~~
pm215
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 :-)

------
BenjiWiebe
This reminds me a little of Broken Thorn's OSDev tutorial series, but that one
is far more in depth.

