Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Linux Boot Process: From Power Button to Kernel

0xkato.xyz

Post reply on HN
Print view View original

81–90 of 96 posts

Re: The Linux Boot Process: From Power Button to Kernel

#81

Post by caycep »

1oooqooq wrote: post #64
nickelpro wrote: post #16

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 mo…

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.

at least from whatever's been published, a good chunk of NSA's tools exploit low level firmware bugs like this...

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)

Re: The Linux Boot Process: From Power Button to Kernel

#82

Post by II2II »

7bit wrote: post #60
nickelpro wrote: post #16

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 mo…

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…

You use the toggle switches on the front panel to set the address to the reset vector and the data to the jump instruction, press a button to load the jump instruction into that address in memory, the press a button to reset the CPU.

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

Re: The Linux Boot Process: From Power Button to Kernel

#84

Post by samat »

dgrin91 wrote: post #35

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?

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.

Re: The Linux Boot Process: From Power Button to Kernel

#85

Post by anthomtb »

tonetegeatinst wrote: post #69
1oooqooq wrote: post #64

Earlier quoted context omitted.

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.

Worse is how little information exists on firmware or how development for firmware works. Its certainly not something regularly taught in higher education.

In a past life I held the title Firmware Engineer. The day-to-day development process did not differ from subsequent positions as a Software Engineer. Write-Compile-Test-Repeat. Then put it up for review so your colleagues can skewer it, or, on rare occasion, offer considerate and thorough feedback.

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.

Re: The Linux Boot Process: From Power Button to Kernel

#86

Post by monegator »

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.

Re: The Linux Boot Process: From Power Button to Kernel

#87

Post by whitehexagon »

rramadass wrote: post #50
hamasho wrote: post #14

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

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 rep…

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

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.

Re: The Linux Boot Process: From Power Button to Kernel

#88

Post by tonetegeatinst »

anthomtb wrote: post #85
tonetegeatinst wrote: post #69

Earlier quoted context omitted.

Worse is how little information exists on firmware or how development for firmware works. Its certainly not something regularly taught in higher education.

In a past life I held the title Firmware Engineer. The day-to-day development process did not differ from subsequent positions as a Software Engineer. Write-Compile-Test-Repeat. Then put it up for review so your colleagues can skewer it, or, on rare occasion, offer considerate and thorough feedback. Firmware development is indeed taught in higher education. But not under the name "Firmware". It will be an "embedded s…

As someone in the security field, who is currently in a security degree program...I have a major overlap with the EE and computer engineering degree requirements.

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.

Re: The Linux Boot Process: From Power Button to Kernel

#89

Post by mbac32768 »

anthomtb wrote: post #85
tonetegeatinst wrote: post #69

Earlier quoted context omitted.

Worse is how little information exists on firmware or how development for firmware works. Its certainly not something regularly taught in higher education.

In a past life I held the title Firmware Engineer. The day-to-day development process did not differ from subsequent positions as a Software Engineer. Write-Compile-Test-Repeat. Then put it up for review so your colleagues can skewer it, or, on rare occasion, offer considerate and thorough feedback. Firmware development is indeed taught in higher education. But not under the name "Firmware". It will be an "embedded s…

How do you test stuff that's deployed to firmware? At least when it comes to normie software your Linux or Mac box resembles the server you deploy to. And you can close the distance quite a bit with Docker.

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.

Re: The Linux Boot Process: From Power Button to Kernel

#90

Post by gosub100 »

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

Post reply on HN