Live data from Hacker News

The Linux Boot Process: From Power Button to Kernel

0xkato.xyz

51–60 of 96 posts

Re: The Linux Boot Process: From Power Button to Kernel

#51
Kinda missing the point of UEFI if you don't mention that it skips the first 3 sections and allows your kernel to boot directly from 64-bit mode ("long mode") with paging, a framebuffer, and a function to read files from your boot drive, already set up for you. Removes the need for GRUB entirely.

Re: The Linux Boot Process: From Power Button to Kernel

#52
post #4

Video device initialization is intimately intertwined and a dependency for all this early boot stuff. I was hoping to learn more but it's not even mentioned. Still, neat.

It's because on a brief period of old PC hardware (1994-1998), when Linux was starting off, high-resolution video initialization (SVGA+) was easier to do in 16-bit mode, before the bootloader switched the CPU over to 32-bit mode. Because GRUB handled this transition, GRUB became responsible for video initialization. After 1998 GPU manufacturers added 32-bit support for initialization, but the long tail of users with hardware with that limitation really entrenched this responsibility in GRUB.

Re: The Linux Boot Process: From Power Button to Kernel

#53

Earlier quoted context omitted.

I dont know, i just don't like the tone. This is a complex subject where the target audience should probably already know what is an hexadecimal number or an interrupt and the explanation of a cpu register ought to be better than: "A register is a tiny slot inside the CPU. It holds a number the CPU is using right now." If the subject interest you, you deserve better.

Agreed. A lot of these articles leave me with more questions than answers. These blog posts really annoy me because I feel like with 20% more effort you could have something worth reading.

The problem is that your 20% isn't the same 20% as anyone elses 20%.

If you want a more thorough explanation, go read a book. Many are available for free on sites such as archive.org and programming-motherfucker.com

Re: The Linux Boot Process: From Power Button to Kernel

#55
post #35

It's a weird article for me. On one side it is an interesting topic. On the other hand why are we explaining what a hex number is? Who is interested in this level of detail but doesn't know hex? Maybe I'm overanalyzing. At the same time this doesn't address my biggest open question on the topic - how do we get from the physical push to the reset vector? Somehow that magic works in HW, physics and electronics - how?

HN is not just read by IT professionals. And they might be a bit curious about Linux startup without necessarily recalling what they know or never knew about hexadecimals.

Re: The Linux Boot Process: From Power Button to Kernel

#58
post #57

I wonder whether the power button really directly starts the CPU. I wouldn't be surprised if the Intel Management Engine (or AMD equivalent), a CPU that's running all the time, is what gets the power button signal and starts the CPU.

I think that is the job of the embedded controller, which is before the bootloader bringing up CPU. On Chromebooks, that part is open source along with the coreboot bootloader.

https://chromium.googlesource.com/chromiumos/platform/ec/+/H...

Re: The Linux Boot Process: From Power Button to Kernel

#59
This post made me remember the technical interview by phone I had with Facebook circa 2010 for a Production Engineer role (but maybe it wasn't called yet that way back then) where they asked me exactly this. Well, they actually asked "explain me the boot process of a Linux server", with no more hints and "go into the details you feel are important" as the only help.

Anyway I should have moved to Dublin and something something surveillance capitalism so the grape wasn't ripe enough anyway.

Re: The Linux Boot Process: From Power Button to Kernel

#60

UEFI is an interface implemented by firmware (literally, Unified Extensible Firmware Interface), it's not the firmware itself. Saying "it starts the machine" is a bit of a nomenclature faux pas. The firmware starts the machine, you talk to the firmware via UEFI. This post skips all the interesting things in the modern firmware dance. Not the least of which is when you call ExitBootServices() you're already in long mo…

I'm currently trying to learn more about how the boot process works, specifically with UEFI. Yesterday I watched a video on how to program a UEFI bootloader so I was happy when I saw this article this morning.

The article jumps over so many steps and leaves out so many mechanics that I had to stop reading, because it just opened more and more questions without closing any. For example, right at the beginning:

> Right after reset the CPU jumps to a special address called the reset vector at 0xFFFFFFF0. Think of it as a permanent bookmark that says “start here.” There is room for almost nothing at that address, so manufacturers put a short jump there that passes control to the firmware on your motherboard.

What does that even mean? It jumps there means that it executed whatever is at that address, but it failed to explain how the instruction at that location is even put there in the first place.

Reading a little more I truly am confused for who this was even written. It seems you need a lot of prior knowledge to understand what the author talks about and then it also makes me wonder what additional information this article conveys if you already can fill in the gaps.

Post reply on HN