Writing a Bootloader

Modern processors just thermal throttle to the extreme if the heat can’t be dissipated, no?

On computers where `efivars' is mounted read-write, you can possibly brick your UEFI by deleting the contents of that “file system” https://github.com/systemd/systemd/issues/2402

I've always been told that there is risk of irreversible hardware damage. I haven't any idea where this claim comes from, and I've never been offered an explanation. It's one of the things that has always made me wonder, and why I've never tested any of my own code on real hardware. I'd be curious to see this claim expanded, or debased.

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.

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.

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

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)

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

> 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 don't feel like the person you're responding to suggested that the OS should be responsible for it; he/she just wondered if it is possible to have the CPU not have to jump through 16-bit real mode and 32-bit protected mode just to get to 64-bit.

I see no fundamental reason why it should be impossible for the BIOS to do its initialization work in 64-bit mode. There's the issue of paging and the page-table perhaps, but it seems trivial enough to suggest that the CPU could initialize with a very basic 1:1 mapping between virtual memory and RAM.

That said, I don't know if such a thing would ever actually happen, since I imagine that it would suggest re-writing a lot of code.

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

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