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.
The Linux Boot Process: From Power Button to Kernel
41–50 of 96 posts
Re: The Linux Boot Process: From Power Button to Kernel
#42Related 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.
Re: The Linux Boot Process: From Power Button to Kernel
#43UEFI 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…
Where do I read more about this?
Re: The Linux Boot Process: From Power Button to Kernel
#44The topic is interesting but it seems to be targeted for my grandmother.
[dead]
Re: The Linux Boot Process: From Power Button to Kernel
#45As 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.
Re: The Linux Boot Process: From Power Button to Kernel
#46Earlier quoted context omitted.
> 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 Your grandmother sounds unusually proficient with this sort of thing.
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.
>A register is a tiny slot inside the CPU. It holds a number the CPU is using right now
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?
Re: The Linux Boot Process: From Power Button to Kernel
#47UEFI 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…
Where do I read more about this?
Here's one source: https://depletionmode.com/uefi-boot.html
Re: The Linux Boot Process: From Power Button to Kernel
#48Earlier 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.
>A register is a tiny slot inside the CPU. It holds a number the CPU is using right now 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?
There's nothing wrong with it but most people striving to do this would make each bit clickable to detail or something so that you can read at your level. I imagine this was a constraint of the site framework or the author's writing style.
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.
Re: The Linux Boot Process: From Power Button to Kernel
#49Reading this just reinforces how much of the x86/Linux boot chain is fossilized ceremony glued together for backward compatibility.
Re: The Linux Boot Process: From Power Button to Kernel
#50Funny 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
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.