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.
next 'snowden leaks' will have that word on every page.
also wondering how great my Asrock firmware is vs. say the bog standard Lenovo (i assume Apple is the one company that's expended significant thought into locking this process down)
Its certainly not something regularly taught in higher education.
Firmware development is indeed taught in higher education. But not under the name "Firmware". It will be an "embedded systems" course or series of courses. At least in my experience, those courses are run by the Electrical Engineering department and the average Computer Science student stays far away from them.
But firmware? Totally different. FreeRTOS does have a POSIX backend, which helps some. Maybe you can run it under a hardware emulator. But it seems like lots of the stuff you want to test isn't really testable from the perspective of what a typical dev knows.
A lot of firmware dev iteration seems to be build -> flash -> watch serial connection for debug prints.
Serial port? Maybe for the fancy folks. Us lunch-pail types would find an unused GPIO, blue-wire an LED, and blink out a code of your choosing.
Okay, I never actually had to blink an LED but it was in my bag of tricks. The real golden-ticket to debugging embedded devices was a development kit with JTAG. JTAG, coupled with expensive additional hardware and equally expensive software license, gave you a gdb-like interface for debug. Breakpoints, stack traces, all the good stuff you take for granted when working with Windows, Linux, or those ugly abominations we call web browsers.
Emulators were also a thing, especially if your product had a custom ASIC and you needed pre-silicon development. But I didn't use them a lot myself and it seemed like by the time you had your emulation environment setup, there was 1st gen silicon and a debug board sitting at your desk.
Not to say it isn't a valid way to debug, but there are definately better options available.
Iv dabbled in some basic MIPS assembly and some microcontroller programming but don't consider that as complicated as boot level firmware or say the firmware that controls complex stuff.
I view embedded as the closest I will ever get to actual hardware engineering and it shocks me how complex everything is.
Example, start with bl1 (first stage boot loader) for a Rasberry Pi here:
https://github.com/raspberrypi/arm-trusted-firmware
The Pi's hardware (register map, etc) is well documented so it's a good way to learn this stuff.
There’s quite a lot of info out there on UEFI, and tiano core is open source. I taught myself enough to implement a small game you had to solve to be able to boot your machine, for example :)
The ost2.fyi courses are all high quality
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.
More seriously, at least for modern systems: the engineers who designed the computer created a memory map that defined which hardware can be found where. They simply ensured that the reset vector would point to an area of non-volatile memory that can be read directly (e.g. an EEPROM would work since you feed it an address and it returns data, much like RAM). That jump would be to somewhere else in non-volatile memory, an area that would have enough space for the code to continue the initialization process. You would have to ask someone more familiar with CPU architecture why they use an indirect approach. My guess is that many CPU architectures define a vector table, which is a list of places the CPU will jump to when various contditions are met (e.g. an interrupt, or reset).
<body>
<!-- Femboy Mode Button - Hidden on Mobile -->
<button class="rave-button" id="raveButton" onclick="toggleRaveMode()" title="Femboy Mode" style="display: none;">
<span class="button-text">uwu</span>
</button>
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.
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?
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.
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.
- 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.
Here are some details: https://www.pixelbeat.org/docs/disk/
physical_address = (segment << 4) + offset
These blog posts really annoy me because I feel like with 20% more effort you could have something worth reading.
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
What's your issue with this? Would you prefer it mentioned the x86 register doesn't always correspond to the same place in the register file?
But hey what the heck, it's fine. An LLM can rewrite it to whatever level of knowledge you like so the deepest level is optimal.
> 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.
There is a well praised post on HN: https://www.nan.fyi/database, built with the framework: https://github.com/nandanmen/NotANumber
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.
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.
Thankfully, pretty much everyone else just uses U-Boot.
edit: Apparently it's a desktop motherboard firmware thing. Ubiquitous but not technically a requirement for POSTing a computer.
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...
Also, in 2000 when Windows crashed you could get a serial debugger. Wonder if they still do that?
https://www.amazon.com/-/he/Developing-32-Bit-Operating-Syst...
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.
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.
https://chromium.googlesource.com/chromiumos/platform/ec/+/H...
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.
https://webaim.org/resources/contrastchecker/
(this is the site: https://webaim.org/resources/contrastchecker/?fcolor=D0D0D0&...)
Thank you to the author:
Anyway I should have moved to Dublin and something something surveillance capitalism so the grape wasn't ripe enough anyway.
The author of any technical blog post should be using an LLM to vet things before posting to find gaps or inconsistencies.
* The Linux Boot Process: From Power Button to Kernel
* The Journey Before main()
* How programs get run: ELF binaries (2015) (lwn.net)
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.
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
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.
My introduction to this subject was through Harald Welte's work on OpenMoko (i still have an old one lying around somewhere) but after the explosion of iPhones/Android phones have not kept apace. Here is Harald's old but still informative presentation Anatomy of smartphone hardware: Dissecting contemporary cellphone hardware - https://media.ccc.de/v/25c3-3008-en-anatomy_of_smartphone_ha...
Also you might find Roger Ye's old book Embedded Programming with Android: Bringing Up an Android System from Scratch pretty useful.