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.
Writing a Bootloader
21–30 of 55 posts
Re: Writing a Bootloader
#22> QEMU is great because you don’t have to worry about accidentally destroying your hardware with badly written OS code Is that actually possible?
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. https://arstechnica.com/information-technology/2013/02/booti...
Not quite right. The documented interface that was used for firmware control on BIOS systems generated errors if you poked it on UEFI systems, and the kernel logged those errors into UEFI variables. If the UEFI variable storage filled up, the machine stopped booting. It was possible to trigger the failure by filling the variable store, even under Windows.
The workaround was to reserve some variable storage space at all times, but this was made difficult due to the way some UEFI implementations do garbage collection - deleting variables wouldn't free the space. The workaround is to try to create a veritable that's larger than the reported free space in order to trigger garbage collection, but not all implementations will do garbage collection at runtime. So the kernel will check how much free space there is during early boot and try to create an oversized variable in order to trigger gc before it transitions to runtime mode. Last time I checked, Windows did nothing to stop you killing your system.
Computers are bad.
(source: I debugged this and wrote most of the remediation code)
Re: Writing a Bootloader
#23It'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')
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 …
Re: Writing a Bootloader
#24> QEMU is great because you don’t have to worry about accidentally destroying your hardware with badly written OS code Is that actually possible?
Apparently hackers can turn your home computer into a bomb
...& blow your family to smithereens!
Re: Writing a Bootloader
#25Nobody 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.
Re: Writing a Bootloader
#26I've just finished studying the bootloader and JOS Kernel and it's nice to see that people are actually working around this in 2017 :)
Re: Writing a Bootloader
#27Earlier quoted context omitted.
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…
On the Commodore PET you could write a short BASIC program to rapidly change the direction of the tape drive motor, it would fry the transformer that ran it.
I had a coworker who used to be a C64 enthusiast. One day, a very long time ago, he discovered a C64 program on Usenet called "drive music".
He downloaded it and ran it... and his floppy drive started playing music. After playing with it for a while, he heard that using it too much could throw your drive heads out of alignment, so he got rid of it.
Re: Writing a Bootloader
#28It'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')
> I wonder how this changes by booting from UEFI (and not using any 'emulation mode')
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/
Re: Writing a Bootloader
#29It'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')
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 …
> 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
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-...
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.
Re: Writing a Bootloader
#30Earlier quoted context omitted.
On the Commodore PET you could write a short BASIC program to rapidly change the direction of the tape drive motor, it would fry the transformer that ran it.
I had a coworker who used to be a C64 enthusiast. One day, a very long time ago, he discovered a C64 program on Usenet called "drive music". He downloaded it and ran it... and his floppy drive started playing music. After playing with it for a while, he heard that using it too much could throw your drive heads out of alignment, so he got rid of it.
For me, alignment problems on the 1541 were fairly common (there was a lot of head thrashing when trying to read "protected" disks), which ended up with the 1541 cover being easily removable for me, and always a screwdriver nearby to recalibrate.