This is old school BIOS boot. EFI bootloaders work very differently.
and with GRUB running under UEFI, it actually uses UEFI load procedures instead of fumbling with 16-bit CS, DS, SS registers
The Linux Boot Process: From Power Button to Kernel
31–40 of 96 posts
Re: The Linux Boot Process: From Power Button to Kernel
#32Video 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.
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...
Re: The Linux Boot Process: From Power Button to Kernel
#33Earlier quoted context omitted.
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.
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?
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/d...
Re: The Linux Boot Process: From Power Button to Kernel
#34Video 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 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.
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.
Re: The Linux Boot Process: From Power Button to Kernel
#35It'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?
Re: The Linux Boot Process: From Power Button to Kernel
#36Seems 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, built with the framework: https://github.com/nandanmen/NotANumber
Re: The Linux Boot Process: From Power Button to Kernel
#37Re: The Linux Boot Process: From Power Button to Kernel
#38ARM 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
Re: The Linux Boot Process: From Power Button to Kernel
#39[flagged]
Re: The Linux Boot Process: From Power Button to Kernel
#40[flagged]
[deleted]