8 ms·

The Linux Boot Process: From Power Button to Kernel

482 points by 0xkato 11mo ago

pixelbeat__ 11mo ago
GRUB is mentioned but not detailed. Here are some details: https://www.pixelbeat.org/docs/disk/ https://www.pixelbeat.org/docs/disk/
metabagel 11mo ago
Hard to read on my phone due to faded text.
- Brybry 11mo ago
  The styling is bad on a desktop browser too. If you use Firefox or Firefox Mobile then reader mode is good for cases like this.
- DonHopkins 11mo ago
  The self deprecatingly downvoted look.
superkuh 11mo ago
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.
- megous 11mo ago
  It's not a dependency for Linux boot at all. You can do well with serial port alone, as anyone who brought up eg. an ARM SoC in Linux will attest to. Also it's not very interesting either. At simplest, Linux just needs to take a pointer to a beginning of a framebuffer and some metadata, and will write to the framebuffer whenever there's something to update.
  - superkuh 11mo ago
    Maybe not linux specifically, but POST requires a video device software (BIOS Option ROM or UEFI GOP Drivers) of some sort does it not? That's been my experience with all PCs for 30 years. But maybe there are cases where it doesn't? edit: Apparently it's a desktop motherboard firmware thing. Ubiquitous but not technically a requirement for POSTing a computer.
    - GreenVulpine 11mo ago
      I've found AM4/AM5 boards will still boot Linux without a discrete or integrated GPU, running a GPUless CPU, not an APU.
    - p_l 11mo ago
      It was sorta required by IBM PC compatibles, but is not required by UEFI which supports serial console (or other interfaces). IBM PC assumed existence of graphic output and sometimes Option ROMs did really too crazy things with it, I still have shivers when I hear "intel raid card" because of that one with possibly Win3.x in ROM...
  - edoceo 11mo ago
    Soekris (rip) had an x86 network device. Four 10/100s and the disk was a CF. Could only serial console that thing - or SSH once it's running. Best router I ever had. Also, in 2000 when Windows crashed you could get a serial debugger. Wonder if they still do that?
    - okanat 11mo ago
      People still need to do driver ddvelopement. So you can still set up a Windows PC to expose kernel debug interface over serial port: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-null-modem-cable-connection https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
  - okanat 11mo ago
    If you would like to see an actually "interesting" boot, I recommend checking out how Raspberry Pi's boot. It is a unique monstrosity that boots from the video / GPU core instead of one of the ARM cores. It has an arcane undocumented architecture.
- qingcharles 11mo ago
  If you can find a copy of this on the high seas, it's a great resource. I wrote my own OS by starting with this and the Linux source in the mid-90s: https://www.amazon.com/-/he/Developing-32-Bit-Operating-System-Cd-Rom/dp/0672306557 https://www.amazon.com/-/he/Developing-32-Bit-Operating-Syst...
- phendrenad2 11mo ago
  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.
- p_l 11mo ago
  Only on IBM PC because it essentially always assumed presence of either MDA or CGA, and over time evolved to assume presence of VGA. UEFI does not require at all and supports and UI framework to enable work in both graphical and textual (with so-called VT-UTF8) mode.
pwpwp 11mo ago
Light gray text on white??
nightshift1 11mo ago
The topic is interesting but it seems to be targeted for my grandmother.
- zahlman 11mo ago
  > When power stabilizes, the CPU resets itself to a tiny, old‑fashioned mode called real mode. Real mode dates back to the original 8086 chip. The rules are simple on purpose. Memory addresses are built from two values the CPU keeps in special fast storage called registers. You combine a segment and an offset like this: physical_address = (segment << 4) + offset Your grandmother sounds unusually proficient with this sort of thing.
  - nightshift1 11mo ago
    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.
    - typpilol 11mo ago
      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.
      - munchlax 11mo ago
        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
      - IOT_Apprentice 11mo ago
        I wonder if anyone will actually write their own article/blog providing a much better explanation of the subject matter. Or at least provide links to those articles that are alternatives to this.
zahlman 11mo ago
In the page source: <body>  <button class="rave-button" id="raveButton" onclick="toggleRaveMode()" title="Femboy Mode" style="display: none;"> <span class="button-text">uwu</span> </button> OwO what's this?
- 0xkato 11mo ago
  Its a working progress.
  - juggerl 11mo ago
    [flagged]
  - juggerl 11mo ago
    [dead]
  - deleted 11mo ago
    [deleted]
  - HansardExpert 11mo ago
    The expression is "work in-progress"
    - munchlax 11mo ago
      The author of the work can call it whatever he wants
  - Melonai 11mo ago
    Hey us mobile readers want the Femboy Mode Button, too! :(
hamasho 11mo ago
Funny how those three posts are in hacker news top 5 now. I guess today is the low level appreciation day. * The Linux Boot Process: From Power Button to Kernel * The Journey Before main() * How programs get run: ELF binaries (2015) (lwn.net) edit: format
- kuekacang 11mo ago
  Oh hey, a fellow noticing person!
  - nightshift1 11mo ago
    yes, and the bar is not at all at the same level.
- adtac 11mo ago
  weekend hackernews best hackernews
- rramadass 11mo ago
  Very much overdue, i would say! Lately HN was turning into just adware for AI news. Does anybody have pointers to similar low-level details specific to iOS/Android systems? Given that most of us by now have a few of these lying around the house gathering dust, they can make a nice DUT to hack/study/learn a few technical things. I would be quite interested in knowing more about how the RF subsystem works and maybe repurposed as an SDR for example.
  - whitehexagon 11mo ago
    Agreed, a very refreshing change. I cant reccomend anything apple or android based, but the PinePhone has some reasonable low-level documentation on itś SoC (Allwinner A64). And there are a great series of tutorials of how Apache Nuttx was ported to the PP. Here's one of the earlier ones: https://lupyuen.org/articles/uboot https://lupyuen.org/articles/uboot I've been working through them myself but still dont understand the boot process, and a long way from radio chip functionality. But I suspect you'll find radio chips quite locked down, since they are licensed for connection to mobile networks. Often there is just a unknown binary blob running the show.
nickelpro 11mo ago
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 mode. There's no need for the journey through real and protected.
- MonaroVXR 11mo ago
  Where do I read more about this?
  - heromal 11mo ago
    Here's one source: https://depletionmode.com/uefi-boot.html https://depletionmode.com/uefi-boot.html
  - ghostpepper 11mo ago
    https://www.youtube.com/playlist?list=PLUFkSN0XLZ-ltETI20mpXOCdqC8rdven6 https://www.youtube.com/playlist?list=PLUFkSN0XLZ-ltETI20mpX... The ost2.fyi courses are all high quality
- 7bit 11mo ago
  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.
panny 11mo ago
I'm probably going to read this, but who thought putting light grey text on a white background was a good idea?
- kps 11mo ago
  It's 2025. Respect `:prefers-color-scheme` or don't specify colours at all.
zzzeek 11mo ago
I'm going to save this guys blog in one step https://webaim.org/resources/contrastchecker/ https://webaim.org/resources/contrastchecker/ (this is the site: https://webaim.org/resources/contrastchecker/?fcolor=D0D0D0&bcolor=FFFFFF https://webaim.org/resources/contrastchecker/?fcolor=D0D0D0&...)
neoattikos 11mo ago
Nice to see the good old hacker energy & independent blogs explaining things showing up on top of hacker news. Welcome change from insufferable agent this and vibe that
jiveturkey 11mo ago
fascinating how it's all over the place wrt level of detail. and absolutely unreadable. luckily the layout is simple and reader mode works. > Hex is base 16 i would argue that someone that understand bases (in the first place), understands what the << operator does (context where base 16 is explained), but doesn't understand what base 16 is, doesn't exist. this is the kind of haphazard approach of this article i'm talking about. even the author's name, 0xkato, is an example of this. as to the content, i wish it had touched on TPM, PCRs, UEFI secure boot, and ME pre-boot. i'm forgiving all the actual errors since it is a pretty broad overview. i'm guessing first-year uni student. rather amazed a post like this can make it to the #1 spot.
gmueckl 11mo ago
This is old school BIOS boot. EFI bootloaders work very differently.
- okanat 11mo ago
  and with GRUB running under UEFI, it actually uses UEFI load procedures instead of fumbling with 16-bit CS, DS, SS registers
dgrin91 11mo ago
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?
- vixen99 11mo ago
  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.
  - 7bit 11mo ago
    It's fine to explain things to people that are not into that topic. But I also wonder what the target audience is. On one hand, he explains what a hexadecimal ist, but then jumps over essential information needed to understand the boot process. It's like: "Learning to swim: This is water, it is wet, if you jump in you sink and in water you cannot breath. Then you start moving your body parts and then you swim."
- samat 11mo ago
  I think it’s an artifact of AI being used to write it. I spotted a few more down the page and stopped reading. I trust the judgment (and curation) of a person who invested significant time into learning stuff and then took even more time to write it down. I don’t trust people who use AI to generate text. If I want to read AI slop — I can generate one myself. I want some soul in texts. It is a sad day for the internet.
liqilin1567 11mo ago
Seems like there are many useful suggestions for the author. Here is mine: maybe an interactive style would work much better for educational content. There is a well praised post on HN: https://www.nan.fyi/database https://www.nan.fyi/database, built with the framework: https://github.com/nandanmen/NotANumber https://github.com/nandanmen/NotANumber
e-dant 11mo ago
ARM and lots of non-x86 architectures often use a series of bootloaders to kick up ram, wake up parts of the hardware, blah blah, and read devicetree blobs to know what the hardware looks like
kgasser88 11mo ago
[flagged]
- deleted 11mo ago
  [deleted]
zaxioms 11mo ago
Does anyone have a similar article with more detail? I don't quite want to read the datasheet of your favorite microprocessor, but I would like a decent amount more detail than what's provided. Especially before UEFI/BIOS.
- tremon 11mo ago
  At a very high level, the processor initialization procedure is similar to most microcontrollers: - processor is powered up with RESET pin asserted, making sure that all circuits are in a known-safe state. - when RESET is deasserted, all autonomous circuits (e.g. core control units, cache controllers, ALUs) go through a hardware setup phase. - the processor accesses the boot firmware according to the platform design. There's many options here, but the three most common are 1) the boot ROM is permanently mapped to a dedicated hardware address, and the processor uses its memory controller to access that memory; 2) the boot ROM is directly connected to the processor via dedicated I/O pins; 3) the initial boot code is located on the processor itself (factory-programmed EEPROM). - if the boot ROM is not mapped to a memory address, the data is loaded into CPU cache (external RAM needs to be initialized first, and that task is usually performed by the firmware). - the primary cpu core starts executing boot code (UEFI/BIOS/etc) from said predefined hardware address. Other cores (and processors) are usually left uninitialized throughout the startup process, and it is left to the operating system to bring up the remaining parts of the system. Specifically for Intel, see https://binarydebt.wordpress.com/2018/10/06/how-does-an-x86-processor-boot/ https://binarydebt.wordpress.com/2018/10/06/how-does-an-x86-... . Or see https://electronics.stackexchange.com/a/726918 https://electronics.stackexchange.com/a/726918 and its comments to get an idea of the differences between platforms.
aborsy 11mo ago
Related to this topic, what is the best way to replace the code involved in the entire boot process? This is useful when sanitizing a system received from a provider that may not be trustworthy, as malware could be hidden at low levels. The disk could be wiped from the BIOS. One could also run “fwupdmgr update” from a live USB to update the motherboard firmware and then reinstall the operating system. However, I’m not sure if this would completely clear the system.
gldrk 11mo ago
As should be clear from the reset vector, the 80286 and its successors actually boot in unreal mode. On the 80386, the base address of the code segment is 0xffff0000, which cannot be obtained by shifting the 16-bit CS register by 4. The descriptor cache simply gets loaded with the correct value at reset. Writing to CS in real mode overwrites the cached value with CS * 16.
- messe 11mo ago
  This isn't quite right either. That's not what unreal mode is. Unreal mode has 32-bit data segments limit, not code segment limits. In this case the code segment still has a 16 bit limit, it's just that its base address in the descriptor cache is outside the bounds typically associated with real mode.
ramanvarma 11mo ago
Reading this just reinforces how much of the x86/Linux boot chain is fossilized ceremony glued together for backward compatibility.
phendrenad2 11mo ago
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.
- rollcat 11mo ago
  This. I haven't seen or touched GRUB or BIOS in about a decade.
deivid 11mo ago
Really nice post, some months ago I also wrote about linux boot, but a bit more focused on the IO side (what's on disk, how is it loaded), here: https://blog.davidv.dev/posts/booting-x86-64/ https://blog.davidv.dev/posts/booting-x86-64/
- Imustaskforhelp 11mo ago
  Oh wow! Combined with the explaination of iso files which can be a single file which can have things like fat and bzimage and rootfs etc. with the bootloader and combined with software like dd / gnome-disks and your article and the HN thread article, this finally makes me understand how Linux starts and how we can install things from https / internet and use software to fundamentally change the operating system Its magic. I was recently trying to build my own linux operating system and I felt so frustrated as to how to build an iso image from bzImage / linux kernel + initramfs but I was able to withstand its pain somehow and it took me a week to actually learn a lot more about the fundamentals of linux which are so fascinating. Now, I was trying to do some mix and matching (imagine tinycorelinux initramfs and buildroot bzImage and merging them) and doing some other shenanigans. Sometimes my computer kernel didn't work or the userspace didn't work in the vm and I guess now WHEN I AM WRITING THIS POST, I realized that it was because of the difference in 32 bit and 64 bit, I think I had 64 bit kernel and 32 bit userspace which had some issues There were some different things as well, which had caused some issues which made me want to scratch my remaining hair but it was so worth it (maybe i used some llm assistance in the end as well), its all just makes sense now, I always wanted to learn how computers work from scratch, now I feel like I have a very basic idea on how things work and they are complex indeed :sob: I was looking for a post like yours yesterday and so I am still glad I found it when the topic is still fresh. I faced so many issues trying to build my own iso but I don't know if it was my skill issue which streched it to a week. But the whole process of building your own iso seems less daunting to me now knowing what it really is I may have skill issues indeed but I fixed those, I feel like that there is a lot to learn from those errors that I missed but maybe that's also because they got too overwhelming. But I now know a path which works and some explainations of why they work. I feel more confident in my ability to make my own custom distro even, but my appreciation for linux grows so much. Its just such a massive rabbit hole and most of linux is literally just "it just works", linux is amazing.
gblargg 11mo ago
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.
- panny 11mo ago
  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/+/HEAD/docs/zephyr/README.md https://chromium.googlesource.com/chromiumos/platform/ec/+/H...
darkwater 11mo ago
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.
a022311 11mo ago
Thanks for the detailed write-up! I'd love to see something like this for ARM too!
ra1231963 11mo ago
Based on all the negative comments, and being a non-expert, I had an LLM generate an article for that same title. I suspect it was more approachable and more technically accurate than this. In fact I asked it to compare its article with this one and the negative comments. The author of any technical blog post should be using an LLM to vet things before posting to find gaps or inconsistencies.
Dwedit 11mo ago
This doesn't cover the things that the CPU secretly does before it finally enters Real Mode, such as loading and validating the microcode.
monegator 11mo ago
Articles like this make me wish i had enough points to downvode them into oblivion. What a waste of time. I'm with the users that argue that if you need a "pretty please" explanation of what HEX values are, you shouldn't even begin to worry about the linux boot process.
gosub100 11mo ago
I'm a bit late to comment on this, but people might find it interesting. The title is "programming in assembly without an operating system", but it gives really good insight to how the early boot process works, and how to begin interacting with it. Thank you to the author: https://www.youtube.com/watch?v=ZFHnbozz7b4 https://www.youtube.com/watch?v=ZFHnbozz7b4

482 points by 0xkato 11mo ago

GRUB is mentioned but not detailed. Here are some details: https://www.pixelbeat.org/docs/disk/ https://www.pixelbeat.org/docs/disk/

metabagel 11mo ago

Hard to read on my phone due to faded text.

Brybry 11mo ago
The styling is bad on a desktop browser too. If you use Firefox or Firefox Mobile then reader mode is good for cases like this.
DonHopkins 11mo ago
The self deprecatingly downvoted look.

superkuh 11mo ago

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.

megous 11mo ago
It's not a dependency for Linux boot at all. You can do well with serial port alone, as anyone who brought up eg. an ARM SoC in Linux will attest to. Also it's not very interesting either. At simplest, Linux just needs to take a pointer to a beginning of a framebuffer and some metadata, and will write to the framebuffer whenever there's something to update.
- superkuh 11mo ago
  Maybe not linux specifically, but POST requires a video device software (BIOS Option ROM or UEFI GOP Drivers) of some sort does it not? That's been my experience with all PCs for 30 years. But maybe there are cases where it doesn't? edit: Apparently it's a desktop motherboard firmware thing. Ubiquitous but not technically a requirement for POSTing a computer.
  - GreenVulpine 11mo ago
    I've found AM4/AM5 boards will still boot Linux without a discrete or integrated GPU, running a GPUless CPU, not an APU.
  - p_l 11mo ago
    It was sorta required by IBM PC compatibles, but is not required by UEFI which supports serial console (or other interfaces). IBM PC assumed existence of graphic output and sometimes Option ROMs did really too crazy things with it, I still have shivers when I hear "intel raid card" because of that one with possibly Win3.x in ROM...
- edoceo 11mo ago
  Soekris (rip) had an x86 network device. Four 10/100s and the disk was a CF. Could only serial console that thing - or SSH once it's running. Best router I ever had. Also, in 2000 when Windows crashed you could get a serial debugger. Wonder if they still do that?
  - okanat 11mo ago
    People still need to do driver ddvelopement. So you can still set up a Windows PC to expose kernel debug interface over serial port: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-null-modem-cable-connection https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
- okanat 11mo ago
  If you would like to see an actually "interesting" boot, I recommend checking out how Raspberry Pi's boot. It is a unique monstrosity that boots from the video / GPU core instead of one of the ARM cores. It has an arcane undocumented architecture.
qingcharles 11mo ago
If you can find a copy of this on the high seas, it's a great resource. I wrote my own OS by starting with this and the Linux source in the mid-90s: https://www.amazon.com/-/he/Developing-32-Bit-Operating-System-Cd-Rom/dp/0672306557 https://www.amazon.com/-/he/Developing-32-Bit-Operating-Syst...
phendrenad2 11mo ago
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.
p_l 11mo ago
Only on IBM PC because it essentially always assumed presence of either MDA or CGA, and over time evolved to assume presence of VGA. UEFI does not require at all and supports and UI framework to enable work in both graphical and textual (with so-called VT-UTF8) mode.

pwpwp 11mo ago

Light gray text on white??

nightshift1 11mo ago

The topic is interesting but it seems to be targeted for my grandmother.

zahlman 11mo ago
> When power stabilizes, the CPU resets itself to a tiny, old‑fashioned mode called real mode. Real mode dates back to the original 8086 chip. The rules are simple on purpose. Memory addresses are built from two values the CPU keeps in special fast storage called registers. You combine a segment and an offset like this: physical_address = (segment << 4) + offset Your grandmother sounds unusually proficient with this sort of thing.
- nightshift1 11mo ago
  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.
  - typpilol 11mo ago
    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.
    - munchlax 11mo ago
      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
    - IOT_Apprentice 11mo ago
      I wonder if anyone will actually write their own article/blog providing a much better explanation of the subject matter. Or at least provide links to those articles that are alternatives to this.

zahlman 11mo ago

In the page source: <body>  <button class="rave-button" id="raveButton" onclick="toggleRaveMode()" title="Femboy Mode" style="display: none;"> <span class="button-text">uwu</span> </button> OwO what's this?

0xkato 11mo ago
Its a working progress.
- juggerl 11mo ago
  [flagged]
- juggerl 11mo ago
  [dead]
- deleted 11mo ago
  [deleted]
- HansardExpert 11mo ago
  The expression is "work in-progress"
  - munchlax 11mo ago
    The author of the work can call it whatever he wants
- Melonai 11mo ago
  Hey us mobile readers want the Femboy Mode Button, too! :(

hamasho 11mo ago

Funny how those three posts are in hacker news top 5 now. I guess today is the low level appreciation day. * The Linux Boot Process: From Power Button to Kernel * The Journey Before main() * How programs get run: ELF binaries (2015) (lwn.net) edit: format

kuekacang 11mo ago
Oh hey, a fellow noticing person!
- nightshift1 11mo ago
  yes, and the bar is not at all at the same level.
adtac 11mo ago
weekend hackernews best hackernews
rramadass 11mo ago
Very much overdue, i would say! Lately HN was turning into just adware for AI news. Does anybody have pointers to similar low-level details specific to iOS/Android systems? Given that most of us by now have a few of these lying around the house gathering dust, they can make a nice DUT to hack/study/learn a few technical things. I would be quite interested in knowing more about how the RF subsystem works and maybe repurposed as an SDR for example.
- whitehexagon 11mo ago
  Agreed, a very refreshing change. I cant reccomend anything apple or android based, but the PinePhone has some reasonable low-level documentation on itś SoC (Allwinner A64). And there are a great series of tutorials of how Apache Nuttx was ported to the PP. Here's one of the earlier ones: https://lupyuen.org/articles/uboot https://lupyuen.org/articles/uboot I've been working through them myself but still dont understand the boot process, and a long way from radio chip functionality. But I suspect you'll find radio chips quite locked down, since they are licensed for connection to mobile networks. Often there is just a unknown binary blob running the show.

nickelpro 11mo ago

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 mode. There's no need for the journey through real and protected.

MonaroVXR 11mo ago
Where do I read more about this?
- heromal 11mo ago
  Here's one source: https://depletionmode.com/uefi-boot.html https://depletionmode.com/uefi-boot.html
- ghostpepper 11mo ago
  https://www.youtube.com/playlist?list=PLUFkSN0XLZ-ltETI20mpXOCdqC8rdven6 https://www.youtube.com/playlist?list=PLUFkSN0XLZ-ltETI20mpX... The ost2.fyi courses are all high quality
7bit 11mo ago
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.

panny 11mo ago

I'm probably going to read this, but who thought putting light grey text on a white background was a good idea?

kps 11mo ago
It's 2025. Respect `:prefers-color-scheme` or don't specify colours at all.

zzzeek 11mo ago

I'm going to save this guys blog in one step https://webaim.org/resources/contrastchecker/ https://webaim.org/resources/contrastchecker/ (this is the site: https://webaim.org/resources/contrastchecker/?fcolor=D0D0D0&bcolor=FFFFFF https://webaim.org/resources/contrastchecker/?fcolor=D0D0D0&...)

neoattikos 11mo ago

Nice to see the good old hacker energy & independent blogs explaining things showing up on top of hacker news. Welcome change from insufferable agent this and vibe that

jiveturkey 11mo ago

fascinating how it's all over the place wrt level of detail. and absolutely unreadable. luckily the layout is simple and reader mode works. > Hex is base 16 i would argue that someone that understand bases (in the first place), understands what the << operator does (context where base 16 is explained), but doesn't understand what base 16 is, doesn't exist. this is the kind of haphazard approach of this article i'm talking about. even the author's name, 0xkato, is an example of this. as to the content, i wish it had touched on TPM, PCRs, UEFI secure boot, and ME pre-boot. i'm forgiving all the actual errors since it is a pretty broad overview. i'm guessing first-year uni student. rather amazed a post like this can make it to the #1 spot.

gmueckl 11mo ago

This is old school BIOS boot. EFI bootloaders work very differently.

okanat 11mo ago
and with GRUB running under UEFI, it actually uses UEFI load procedures instead of fumbling with 16-bit CS, DS, SS registers

dgrin91 11mo ago

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?

vixen99 11mo ago
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.
- 7bit 11mo ago
  It's fine to explain things to people that are not into that topic. But I also wonder what the target audience is. On one hand, he explains what a hexadecimal ist, but then jumps over essential information needed to understand the boot process. It's like: "Learning to swim: This is water, it is wet, if you jump in you sink and in water you cannot breath. Then you start moving your body parts and then you swim."
samat 11mo ago
I think it’s an artifact of AI being used to write it. I spotted a few more down the page and stopped reading. I trust the judgment (and curation) of a person who invested significant time into learning stuff and then took even more time to write it down. I don’t trust people who use AI to generate text. If I want to read AI slop — I can generate one myself. I want some soul in texts. It is a sad day for the internet.

liqilin1567 11mo ago

Seems like there are many useful suggestions for the author. Here is mine: maybe an interactive style would work much better for educational content. There is a well praised post on HN: https://www.nan.fyi/database https://www.nan.fyi/database, built with the framework: https://github.com/nandanmen/NotANumber https://github.com/nandanmen/NotANumber

e-dant 11mo ago

ARM and lots of non-x86 architectures often use a series of bootloaders to kick up ram, wake up parts of the hardware, blah blah, and read devicetree blobs to know what the hardware looks like

kgasser88 11mo ago

[flagged]

deleted 11mo ago
[deleted]

zaxioms 11mo ago

Does anyone have a similar article with more detail? I don't quite want to read the datasheet of your favorite microprocessor, but I would like a decent amount more detail than what's provided. Especially before UEFI/BIOS.

tremon 11mo ago
At a very high level, the processor initialization procedure is similar to most microcontrollers: - processor is powered up with RESET pin asserted, making sure that all circuits are in a known-safe state. - when RESET is deasserted, all autonomous circuits (e.g. core control units, cache controllers, ALUs) go through a hardware setup phase. - the processor accesses the boot firmware according to the platform design. There's many options here, but the three most common are 1) the boot ROM is permanently mapped to a dedicated hardware address, and the processor uses its memory controller to access that memory; 2) the boot ROM is directly connected to the processor via dedicated I/O pins; 3) the initial boot code is located on the processor itself (factory-programmed EEPROM). - if the boot ROM is not mapped to a memory address, the data is loaded into CPU cache (external RAM needs to be initialized first, and that task is usually performed by the firmware). - the primary cpu core starts executing boot code (UEFI/BIOS/etc) from said predefined hardware address. Other cores (and processors) are usually left uninitialized throughout the startup process, and it is left to the operating system to bring up the remaining parts of the system. Specifically for Intel, see https://binarydebt.wordpress.com/2018/10/06/how-does-an-x86-processor-boot/ https://binarydebt.wordpress.com/2018/10/06/how-does-an-x86-... . Or see https://electronics.stackexchange.com/a/726918 https://electronics.stackexchange.com/a/726918 and its comments to get an idea of the differences between platforms.

aborsy 11mo ago

Related to this topic, what is the best way to replace the code involved in the entire boot process? This is useful when sanitizing a system received from a provider that may not be trustworthy, as malware could be hidden at low levels. The disk could be wiped from the BIOS. One could also run “fwupdmgr update” from a live USB to update the motherboard firmware and then reinstall the operating system. However, I’m not sure if this would completely clear the system.

gldrk 11mo ago

As should be clear from the reset vector, the 80286 and its successors actually boot in unreal mode. On the 80386, the base address of the code segment is 0xffff0000, which cannot be obtained by shifting the 16-bit CS register by 4. The descriptor cache simply gets loaded with the correct value at reset. Writing to CS in real mode overwrites the cached value with CS * 16.

messe 11mo ago
This isn't quite right either. That's not what unreal mode is. Unreal mode has 32-bit data segments limit, not code segment limits. In this case the code segment still has a 16 bit limit, it's just that its base address in the descriptor cache is outside the bounds typically associated with real mode.

ramanvarma 11mo ago

Reading this just reinforces how much of the x86/Linux boot chain is fossilized ceremony glued together for backward compatibility.

phendrenad2 11mo ago

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.

rollcat 11mo ago
This. I haven't seen or touched GRUB or BIOS in about a decade.

deivid 11mo ago

Really nice post, some months ago I also wrote about linux boot, but a bit more focused on the IO side (what's on disk, how is it loaded), here: https://blog.davidv.dev/posts/booting-x86-64/ https://blog.davidv.dev/posts/booting-x86-64/

Imustaskforhelp 11mo ago
Oh wow! Combined with the explaination of iso files which can be a single file which can have things like fat and bzimage and rootfs etc. with the bootloader and combined with software like dd / gnome-disks and your article and the HN thread article, this finally makes me understand how Linux starts and how we can install things from https / internet and use software to fundamentally change the operating system Its magic. I was recently trying to build my own linux operating system and I felt so frustrated as to how to build an iso image from bzImage / linux kernel + initramfs but I was able to withstand its pain somehow and it took me a week to actually learn a lot more about the fundamentals of linux which are so fascinating. Now, I was trying to do some mix and matching (imagine tinycorelinux initramfs and buildroot bzImage and merging them) and doing some other shenanigans. Sometimes my computer kernel didn't work or the userspace didn't work in the vm and I guess now WHEN I AM WRITING THIS POST, I realized that it was because of the difference in 32 bit and 64 bit, I think I had 64 bit kernel and 32 bit userspace which had some issues There were some different things as well, which had caused some issues which made me want to scratch my remaining hair but it was so worth it (maybe i used some llm assistance in the end as well), its all just makes sense now, I always wanted to learn how computers work from scratch, now I feel like I have a very basic idea on how things work and they are complex indeed :sob: I was looking for a post like yours yesterday and so I am still glad I found it when the topic is still fresh. I faced so many issues trying to build my own iso but I don't know if it was my skill issue which streched it to a week. But the whole process of building your own iso seems less daunting to me now knowing what it really is I may have skill issues indeed but I fixed those, I feel like that there is a lot to learn from those errors that I missed but maybe that's also because they got too overwhelming. But I now know a path which works and some explainations of why they work. I feel more confident in my ability to make my own custom distro even, but my appreciation for linux grows so much. Its just such a massive rabbit hole and most of linux is literally just "it just works", linux is amazing.

gblargg 11mo ago

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.

panny 11mo ago
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/+/HEAD/docs/zephyr/README.md https://chromium.googlesource.com/chromiumos/platform/ec/+/H...

darkwater 11mo ago

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.

a022311 11mo ago

Thanks for the detailed write-up! I'd love to see something like this for ARM too!

ra1231963 11mo ago

Based on all the negative comments, and being a non-expert, I had an LLM generate an article for that same title. I suspect it was more approachable and more technically accurate than this. In fact I asked it to compare its article with this one and the negative comments. The author of any technical blog post should be using an LLM to vet things before posting to find gaps or inconsistencies.

Dwedit 11mo ago

This doesn't cover the things that the CPU secretly does before it finally enters Real Mode, such as loading and validating the microcode.

monegator 11mo ago

Articles like this make me wish i had enough points to downvode them into oblivion. What a waste of time. I'm with the users that argue that if you need a "pretty please" explanation of what HEX values are, you shouldn't even begin to worry about the linux boot process.

gosub100 11mo ago

I'm a bit late to comment on this, but people might find it interesting. The title is "programming in assembly without an operating system", but it gives really good insight to how the early boot process works, and how to begin interacting with it. Thank you to the author: https://www.youtube.com/watch?v=ZFHnbozz7b4 https://www.youtube.com/watch?v=ZFHnbozz7b4