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.
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]:
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.
Yes. Not as easily as twenty years ago, but still fairly easily.
In fact, even well-written code can cause hardware-bugs to burn out your hardware. Modern OS's have a ton of hacks to work around limitations of certain hardware.
Example A: Intel's Atom C2000 family. [0] There's quite a few things there, SATA voltages being too high etc., but if we're looking for ultimate destruction then we can't go passed AVR54 from the errata.
> The SoC LPC_CLKOUT0 and/or LPC_CLKOUT1 signals (Low Pin Count bus clock outputs) may stop functioning.
If you lose the LPC clock... The system won't boot anymore.
The whole story isn't in the link, but apparently the cause for this, is that the clock can suddenly stop functioning if you check it "too often", usually failing after 18 months of use.
Cisco has the same problem with some of their routers, from the same hardware.
It's a hardware bug, but with a quick BIOS fix, Cisco and Intel have worked around it, and their devices keep working without a recall... But your own code hasn't, and will eventually brick your device.
Oh, and notice the date on Intel's link. April, 2017.
As recently as 4 years ago there were Samsung laptops that could be bricked by installing Linux. Apparently there was a special physical memory address that you weren't supposed to poke and which Linux did, which resulted in bricking the laptop.
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.
Back in the early days of GNU/Linux, getting X to run could kill your monitor.
Another example, many hard drive controllers used to blindly move their heads to whatever position they were told, even if it was an incorrect position. In the old days you also had to use something like PC Tools to park the heads before moving the computer.
The possibility is small, but with voltages and frequencies under software control, yes. AFAIK even ordinary "non-overclocker" hardware has this capability, despite not being exposed in the BIOS settings, for power management purposes.
This is especially problematic with certain laptops --- I remember hearing about some that would overheat when booted into BIOS or even an alternative OS for an extended period of time, since they depended entirely on a driver to turn on and control the CPU fan...
Yes in the 80s PC monitors had CGA and MONOCHROME mode, and if you switched fast between them in DOS (you could do mode mono, and mode co80 in a loop) and it fried my GPU :)
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.
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.
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 …
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:
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 found 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.
[+] [-] TheDauthi|8 years ago|reply
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|8 years ago|reply
[+] [-] ingve|8 years ago|reply
[0] http://3zanders.co.uk/2017/10/16/writing-a-bootloader2/
[1] http://3zanders.co.uk/2017/10/18/writing-a-bootloader3/
[2] http://3zanders.co.uk/2017/10/13/writing-a-bootloader/writin...
[+] [-] geff82|8 years ago|reply
[+] [-] scandox|8 years ago|reply
Is that actually possible?
[+] [-] shakna|8 years ago|reply
In fact, even well-written code can cause hardware-bugs to burn out your hardware. Modern OS's have a ton of hacks to work around limitations of certain hardware.
Example A: Intel's Atom C2000 family. [0] There's quite a few things there, SATA voltages being too high etc., but if we're looking for ultimate destruction then we can't go passed AVR54 from the errata.
> The SoC LPC_CLKOUT0 and/or LPC_CLKOUT1 signals (Low Pin Count bus clock outputs) may stop functioning.
If you lose the LPC clock... The system won't boot anymore.
The whole story isn't in the link, but apparently the cause for this, is that the clock can suddenly stop functioning if you check it "too often", usually failing after 18 months of use.
Cisco has the same problem with some of their routers, from the same hardware.
It's a hardware bug, but with a quick BIOS fix, Cisco and Intel have worked around it, and their devices keep working without a recall... But your own code hasn't, and will eventually brick your device.
Oh, and notice the date on Intel's link. April, 2017.
[0] https://www-ssl.intel.com/content/dam/www/public/us/en/docum...
[+] [-] ianopolous|8 years ago|reply
https://arstechnica.com/information-technology/2013/02/booti...
[+] [-] perbu|8 years ago|reply
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.
[+] [-] pjmlp|8 years ago|reply
Back in the early days of GNU/Linux, getting X to run could kill your monitor.
Another example, many hard drive controllers used to blindly move their heads to whatever position they were told, even if it was an incorrect position. In the old days you also had to use something like PC Tools to park the heads before moving the computer.
[+] [-] superflyguy|8 years ago|reply
https://m.slashdot.org/story/306621
[+] [-] d33|8 years ago|reply
[+] [-] dividuum|8 years ago|reply
[+] [-] userbinator|8 years ago|reply
This is especially problematic with certain laptops --- I remember hearing about some that would overheat when booted into BIOS or even an alternative OS for an extended period of time, since they depended entirely on a driver to turn on and control the CPU fan...
[+] [-] coworkerblues|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] yipopov|8 years ago|reply
...& blow your family to smithereens!
[+] [-] korethr|8 years ago|reply
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|8 years ago|reply
> 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.
[+] [-] raverbashing|8 years ago|reply
I wonder how this changes by booting from UEFI (and not using any 'emulation mode')
[+] [-] josteink|8 years ago|reply
It's pretty damn easy:
1. You don't write a bootloader since UEFI is that bootloader.
2. You write a portable executable which gets executed by the UEFI bootloader. This executable runs directly in long-mode without any nonsense.
3. You have to link against some different C-libraries, not the standard ones, but that's about it.
Here's an example: http://x86asm.net/articles/uefi-programming-first-steps/
[+] [-] eadmund|8 years ago|reply
[+] [-] 4lch3m1st|8 years ago|reply
[+] [-] current_call|8 years ago|reply
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....
I tried to email the author, but I couldn't find his email anywhere.
[+] [-] zanders3|8 years ago|reply
[+] [-] jhallenworld|8 years ago|reply
https://github.com/jhallen/joes-sandbox/tree/master/boot
[+] [-] robotjosh|8 years ago|reply
[+] [-] tatoalo|8 years ago|reply
[+] [-] pmoriarty|8 years ago|reply
[+] [-] exikyut|8 years ago|reply
--
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)
--
I found 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
--
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 - 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...) 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
[+] [-] bootcat|8 years ago|reply