The Linux Boot Process: From Power Button to Kernel

The self deprecatingly downvoted look.

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.

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.

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.

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

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.

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

One of the things we were taught in uni was audience analysis. I think about it a lot. What's expected to already be known? What acronyms or phrases need defining? Etc. This is an art I'm far from perfect at and it seems a lot of tech writers are too

Its a working progress.

Oh hey, a fellow noticing person!

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.

weekend hackernews best hackernews

Where do I read more about this?

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.

firmwares are the real IoT nobody talks about that that actually happened. infinite little computers and code churning away from view. and not being updated.

next 'snowden leaks' will have that word on every page.

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

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

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.

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.

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-... . Or see https://electronics.stackexchange.com/a/726918 and its comments to get an idea of the differences between platforms.

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.

This. I haven't seen or touched GRUB or BIOS in about a decade.

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.

I am curious were the differntiation comes between linux, and other unix systems (bsd, etc ..).

Thanks! Nice to see it has plenty of diagrams.

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