
Writing a Bootloader - ingve
http://3zanders.co.uk/2017/10/13/writing-a-bootloader/
======
TheDauthi
This is deep nostalgia for me. A bootloader and a toy ... kernel ... were the
first things I ever wrote after leaving Apple II BASIC behind.

The local library had no books on anything other than BASIC and assembler. I
didn't know what a higher-level language was - never even heard of C or Pascal
or anything - I just knew that I didn't seem to be able to do a lot of stuff
in BASIC. After a few hours at the library, I thought that assembler was the
only option.

And that's how I spent that entire summer. Going over books on assembler that
for some reason were in the library of a tiny Mississippi town.

Ralf Brown's Interrupt List made me giddy once I understood exactly what it
meant. I still remember that day. It was in some TSR program that I could view
while in EDIT.

Next year, I found out about Pascal, pirated a copy of TP(3? 5?) from my
friend's dad and didn't touch assembler again until college. But I found the
knowledge of how x86 worked useful for many years, even into my first real-
world job.

God, I'm old.

~~~
laythea
You sound like me, except your kernel worked :) Good times.

------
ingve
There's even more from Alex: Part 2 [0] covers getting into 32-bit protected
mode, and part 3 [1] deals with compiling, linking and running C++ code. There
is also a very nice presentation available [2]:

[0] [http://3zanders.co.uk/2017/10/16/writing-a-
bootloader2/](http://3zanders.co.uk/2017/10/16/writing-a-bootloader2/)

[1] [http://3zanders.co.uk/2017/10/18/writing-a-
bootloader3/](http://3zanders.co.uk/2017/10/18/writing-a-bootloader3/)

[2] [http://3zanders.co.uk/2017/10/13/writing-a-
bootloader/writin...](http://3zanders.co.uk/2017/10/13/writing-a-
bootloader/writingabootloader.pdf)

------
geff82
Great to see someone is doing this in 2017. I was writing my own bootloader in
2003 with together with a little command interpreter in pure assembler. It
taught mena lot about computers, it changed my thinking about what software
really is. I think for instructional purposes, getting back to this basic
level is a great thing.

------
scandox
> QEMU is great because you don’t have to worry about accidentally destroying
> your hardware with badly written OS code

Is that actually possible?

~~~
perbu
The only times I've heard of destroying hardware with software have been: 1)
stopping the ray in a CRT monitor through special purpose registers and using
it to burn through the phosphorous. 2) Early floppy drives where you could
position the head to an impossible position causing the servo to burn.

Haven't heard of anything like what he is describing the last 20 years.
Perhaps you can overheat some stuff - but most likley it'll shut down before
anything bad happends. There are however some worrying notes on OSDEV about
causing potential damage when probing for memory, perhaps the author read this
and got worries. It isn't detailed or likely, imho.

~~~
khedoros1
> The only times I've heard of destroying hardware with software have been

I was trying to find some information to back up my story, but I can't find
anything that does. So I'll describe what I experienced, and maybe someone
will have an idea.

Around 1999, my father gave me the first computer that was "mine" (previous
ones having been "family computers"). I was inexperienced and 15 years old,
with access to filesharing platforms, and learned the hard way about *.jpg.exe
files.

The hard drive started making rhythmic sounds as soon as the OS was booted. A
couple days later, the OS wouldn't boot. A reinstall worked for a short time
(but the drive still did its odd sound). We had some bootable disk scanning
utilities from the drive vendor. They identified the drive as having 100% bad
sectors.

I've always assumed that a virus was crashing or misaligning the read heads
somehow. That was reinforced when the second drive that I got met the same
fate. Although, I guess it's more likely that they were 2 drives from the same
shipment that met early deaths due to manufacturing defects.

~~~
BearOso
Given the year, that sounds suspiciously like the IBM 75gxp Deathstar fiasco.
It probably wasn’t your fault at all.

~~~
ChickeNES
Was about to say the same when I refreshed and saw your comment. For GP:
[https://en.wikipedia.org/wiki/Deskstar#IBM_Deskstar_75GXP_fa...](https://en.wikipedia.org/wiki/Deskstar#IBM_Deskstar_75GXP_failures)

------
korethr
Last line in this article mentions a Part 2, which will cover getting into
Protected Mode. Which implies that x86 boxen are _still_ to this day are
POSTing in 16-bit real mode

What I'm wondering, is whether this is because of the design of the firmware,
hardware or both. Back when protected mode was the new hotness, it made sense
for the CPU to power on in real mode, for backwards compatibilty. But back-
compat w/ DOS is less of a concern today than it was 20 years ago. Is it still
required for back-compat with older versions of Windows, since UEFI wasn't
commonplace in the WinXP or Win7 days? Does UEFI have to lift the CPU from
real-mode to protected mode, or does it leave that to the OS?

Another thing I wonder about, is if it's possible to have the CPU come online
directly in protected mode or long mode after POWER_OK has settled and the
motherboard releases the reset line. I recall reading various datasheets for
tiny specialized controller chips (fan controller, et. al.), wherein by
leaving various pins floating, or asserting them high or low with pull-up/down
resistors, one set the power-on value of the register(s) which controlled
start-up behavior. It'd be cool if you could do that with a modern mobo/CPU.
But even if it were, I suspect it would be a mod reserved for those brave
enough to take a soldering iron their motherboard. I doubt such is a common
enough need that mobo manufacturers are exposing that through jumpers or
firmware config.

~~~
duskwuff
UEFI boot handles the real->protected (and ->long) transitions, so it's no
longer necessary for the OS to handle it. EFI executables run in protected
mode, with a memory mapping set up by the runtime.

> Another thing I wonder about, is if it's possible to have the CPU come
> online directly in protected mode or long mode after POWER_OK has settled
> and the motherboard releases the reset line.

No. The BIOS needs to perform some touchy, hardware-specific initialization --
like detecting and calibrating RAM -- before releasing control to user code.
It's not something you'd want the OS to be responsible for.

~~~
korethr
>> Another thing I wonder about, is if it's possible to have the CPU come
online directly in protected mode or long mode after POWER_OK has settled and
the motherboard releases the reset line.

> No. The BIOS needs to perform some touchy, hardware-specific initialization
> -- like detecting and calibrating RAM -- before releasing control to user
> code. It's not something you'd want the OS to be responsible for.

I think you misunderstood me. I didn't mention, and wasn't even thinking about
the OS yet. As you said, UEFI handles the real->protected->long transitions.
While the OS isn't loaded yet, and hardware initialization is being done, the
CPU is still executing. What I'm talking about is setting the CPU's default
power-on state, how it is _before_ it begins executing even the boot firmware
to initalize hardware and prepare to hand over execution to the OS.

By my understanding, when the power comes on, the motherboard waits for the
PSU to assert POWER_OK. Once the PSU has done so, and POWER_OK has settled,
then the mobo releases the CPU's RESET line, allowing the CPU to begin
executing. At this point, the CPU is in real mode. What I am wondering is if
the hardware can be configured so that once the motherboard releases RESET,
the CPU is already in long mode, and begins executing the boot firmware. Is
there something about the nature of pre-OS hardware initializtion that
requires the CPU to be in real-mode to do this?

If CPUs could be coming online directly in long-mode, then perhaps the UEFI
firmware could be simplified, since it doesn't need to handle the
real->protected->long transitions anymore.

------
raverbashing
It's a great write-up (follow the next parts if you've only seen the 1st one)

I wonder how this changes by booting from UEFI (and not using any 'emulation
mode')

~~~
eadmund
Yeah, I really want to write a hobbyist OS atop UEFI & amd64, but … the
learning curve is daunting. BIOS is too simple, but UEFI is hyper-complex.
There's probably a reason most hobbyist OSes seem to be using BIOS …

~~~
josteink
> Yeah, I really want to write a hobbyist OS atop UEFI & amd64, but … the
> learning curve is daunting. BIOS is too simple, but UEFI is hyper-complex.

That doesn't really seem very representative of reality. UEFI basically takes
care of all the terrible legacy stuff for you, so you don't have to.

You can just focus on the OS, built on a modern architecture.

See my other comment regarding BIOS vs UEFI:
[https://news.ycombinator.com/item?id=15517300](https://news.ycombinator.com/item?id=15517300)

If you also try to compare UEFI vs BIOS on a deeper technical level, UEFI also
seems to come out in a favourable way:
[https://www.happyassassin.net/2014/01/25/uefi-boot-how-
does-...](https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-
actually-work-then/)

The only "complex" part about it, is that you already know and have come to
terms with all those terrible & complex things which booting a OS from legacy
BIOS-mode entails, but UEFI while simplifying a million things is still
_different_ and something you haven't learned yet.

~~~
eadmund
> That doesn't really seem very representative of reality … You can just focus
> on the OS, built on a modern architecture.

But that means complexity. E.g. BIOS just loads the first 512 bytes from a
volume into memory; UEFI requires FAT filesystems, with paths &c. BIOS
routines can easily be called from assembly; I don't know if UEFI routines
can, or if the EFI Development Toolkit is required (I could find out, of
course — but that's part of the learning curve).

I have no doubt that once I learn it all I'll prefer UEFI. But, as I said, the
learning curve is daunting.

------
current_call
_It’s probably easiest to download boot3.asm directly._

This is kind of funny, since this is the only link that's broken.
[http://3zanders.co.uk/2017/10/13/writing-a-
bootloader/boot3....](http://3zanders.co.uk/2017/10/13/writing-a-
bootloader/boot3.asm)

I tried to email the author, but I couldn't find his email anywhere.

~~~
zanders3
Hello - author here :) A silly mistake I've fixed it now!
[http://3zanders.co.uk/2017/10/13/writing-a-
bootloader/boot3....](http://3zanders.co.uk/2017/10/13/writing-a-
bootloader/boot3.asm)

------
jhallenworld
The challenge is to fit the FAT or EXT2 filesystem in single-block bootloader
itself. Also it should read a track at time so that booting from old floppy
drives is fast:

[https://github.com/jhallen/joes-
sandbox/tree/master/boot](https://github.com/jhallen/joes-
sandbox/tree/master/boot)

------
robotjosh
Nobody knows how to do this anymore. About half the projects I got when I
freelanced were projects that were finished but "just needed" a boot loader.

------
tatoalo
I've just finished studying the bootloader and JOS Kernel and it's nice to see
that people are actually working around this in 2017 :)

------
pmoriarty
Any good articles about doing this in Forth?

~~~
exikyut
I guess Open Firmware is the canonical answer. This of course compiles for
x86. But it's massive and sprawling and not really designed for "can be easily
grasped while leaving mental room to actually learn something" but rather for
wide-spectrum support.

\--

You of course already know about ColorForth (confident guess), which of course
fits the bill here. Not quite "build an OS" and more "finished thing", but
certainly hits the mark of "rapidly bring up new hardware functionality".

\--

I just found 4os (article:
[https://news.ycombinator.com/item?id=12709802](https://news.ycombinator.com/item?id=12709802))

\--

I found [http://forthos.org/drive.html](http://forthos.org/drive.html) a
little while ago but completely failed to get it going in QEMU (the CD image
boots GRUB, but promptly hangs on loading). I haven't yet tested it with any
other emulator, and haven't fed it to any actual hardware yet either.

HN article:
[https://news.ycombinator.com/item?id=2973134](https://news.ycombinator.com/item?id=2973134)

\--

There's also gfxboot, SuSE's approach to bootloader management.

This is a scary pile of assembly language
([https://github.com/openSUSE/gfxboot/blob/master/bincode.asm](https://github.com/openSUSE/gfxboot/blob/master/bincode.asm)
\- warning: 16k lines, large webpage) that parses an equally scary script
grammar (see .bc files in
[https://github.com/openSUSE/gfxboot/blob/master/themes/openS...](https://github.com/openSUSE/gfxboot/blob/master/themes/openSUSE/src/))
that is heavily inspired by Forth (the stack/RPN grammar is right there) but
also reminds me of Tcl as well (it uses a { } block syntax).

AFAIK this ships on the install media, and I also vaguely recall building it
from scratch being very easy (I used SYSLINUX to bootstrap it).

\--

This isn't quite an OS-dev thing, but I think it's fun:
[http://phrack.org/issues/53/9.html](http://phrack.org/issues/53/9.html)

------
bootcat
Simple and nice article !!

