3 ms·

UEFI is an interface implemented by firmware (literally, Unified Extensible Firmware Interface), it's not the firmware itself. Saying "it starts the machine" is

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 mode. There's no need for the journey through real and protected.

MonaroVXR 1y ago
Where do I read more about this?
- heromal 1y ago
  Here's one source: https://depletionmode.com/uefi-boot.html https://depletionmode.com/uefi-boot.html
- ghostpepper 1y ago
  https://www.youtube.com/playlist?list=PLUFkSN0XLZ-ltETI20mpXOCdqC8rdven6 https://www.youtube.com/playlist?list=PLUFkSN0XLZ-ltETI20mpX... The ost2.fyi courses are all high quality
7bit 1y ago
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.
- mmh0000 1y ago
  Would love to see the video you're referencing. Mind providing a link?
  - 7bit 11mo ago
    Its the series from Queso Fuego. Too lazy to get the link right now :)
- II2II 1y ago
  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).
1oooqooq 1y ago
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.
- tonetegeatinst 1y ago
  Worse is how little information exists on firmware or how development for firmware works. Its certainly not something regularly taught in higher education.
  - QuiEgo 1y ago
    If you're curious go walk through the bootloaders of an embedded platform, they serve roughly the same role as firmware that implements UEFI on traditional x86 systems. Example, start with bl1 (first stage boot loader) for a Rasberry Pi here: https://github.com/raspberrypi/arm-trusted-firmware 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.
  - jdsnape 1y ago
    Maybe not on compsci? but when I did electronic engineering it was covered as part of our embedded systems course. 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 :)
  - anthomtb 1y ago
    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.

MonaroVXR 1y ago

Where do I read more about this?

heromal 1y ago
Here's one source: https://depletionmode.com/uefi-boot.html https://depletionmode.com/uefi-boot.html
ghostpepper 1y ago
https://www.youtube.com/playlist?list=PLUFkSN0XLZ-ltETI20mpXOCdqC8rdven6 https://www.youtube.com/playlist?list=PLUFkSN0XLZ-ltETI20mpX... The ost2.fyi courses are all high quality

7bit 1y ago

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.

mmh0000 1y ago
Would love to see the video you're referencing. Mind providing a link?
- 7bit 11mo ago
  Its the series from Queso Fuego. Too lazy to get the link right now :)
II2II 1y ago
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).

1oooqooq 1y ago

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.

tonetegeatinst 1y ago
Worse is how little information exists on firmware or how development for firmware works. Its certainly not something regularly taught in higher education.
- QuiEgo 1y ago
  If you're curious go walk through the bootloaders of an embedded platform, they serve roughly the same role as firmware that implements UEFI on traditional x86 systems. Example, start with bl1 (first stage boot loader) for a Rasberry Pi here: https://github.com/raspberrypi/arm-trusted-firmware 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.
- jdsnape 1y ago
  Maybe not on compsci? but when I did electronic engineering it was covered as part of our embedded systems course. 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 :)
- anthomtb 1y ago
  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.