Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a Bootloader

3zanders.co.uk

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Writing a Bootloader

#31

Post by 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.

Re: Writing a Bootloader

#32

Post by duskwuff »

korethr wrote: post #31

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 i…

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.

Re: Writing a Bootloader

#34

Post by eadmund »

josteink wrote: post #29
eadmund wrote: post #23

Earlier quoted context omitted.

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.ycom…

> 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.

Re: Writing a Bootloader

#35

Post by convolvatron »

duskwuff wrote: post #32
korethr wrote: post #31

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 i…

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 perfo…

meh. since the memory controllers are part of the CPU proper this is a pita, but not clearly super magic that only contractors of motherboard manufacturers should touch either.

I worked someplace where we ran AMD chips with no bios. someone who had better uses for his time had to probe the ram modules and configure the controller. it wasn't the end of the world.

same with pci tree discovery (waste of time, not the end of the world)

interacting with EFI is a little more sane than the old bioses, and less proprietary - but i dont think there as clear a line as you imply

Re: Writing a Bootloader

#36

Post by coworkerblues »

scandox wrote: post #2

> QEMU is great because you don’t have to worry about accidentally destroying your hardware with badly written OS code Is that actually possible?

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

Re: Writing a Bootloader

#37

Post by aidos »

mjg59 wrote: post #22
ianopolous wrote: post #10

Earlier quoted context omitted.

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 a…

I love this comment, in part because it's totally outside my area of knowledge but I can still picture the battles and dead ends you must have worked through to make it stable.

Did you kill a lot of hardware figuring it out? What was the purpose of poking that caused the underlying issue?

Re: Writing a Bootloader

#38

Post by wolverine876 »

perbu wrote: post #4
scandox wrote: post #2

> QEMU is great because you don’t have to worry about accidentally destroying your hardware with badly written OS code Is that actually possible?

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…

Tangent, but a good story: Early in my career, in the CRT era, I was working late at a client's office. One of the executives stopped by to chat; he was telling me that his house burned down the past weekend (!) due to a wiring fault in an SUV in the attached garage that somehow ignited something ... whatever caused it, holy shit. His family all got out ok - in the middle of the night - but everything they owned was lost. As we were walking through the darkened office on our way out - the last two to leave - he said, 'do you smell something burning?'

Poor guy; he must smell it everywhere. For all I know there was still smoke residue in his sinuses. Anyway, I have to humor him - I'm tired and really want to get home, but there's no question of trying to talk sense to someone in his state. So I make a show of looking around the office with him - and sure enough, there was a CRT monitor, plugged in, off (or maybe asleep), and literally smoking. I never saw anything like it before or since, in over 20 years in IT. But he must still smells smoke everywhere he goes.

Re: Writing a Bootloader

#39

Post by 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.

Post reply on HN