Repository navigation
ap bringup util #343
Description
I'm using the new bootloader+bootloader_api for my OS (huge fan, love how easy it is to use!), and currently banging my head on SMP. I was thinking a nice feature to have would be a util for bringing up application processors, using all of the existing work/code that's already in the bootloader for the boot processor. I don't know exactly what such a util api would look like... maybe each AP uses the same entrypoint but there's info in BootInfo to differentiate?
Activity
Freax13 commentedon Feb 12, 2023
Related to #74
jasoncouture commentedon Mar 5, 2023
I, personally, don't think this is a good idea.
Here's why:
The bootloader already has a lot to do, with limited support and system resources (Especially in the case of bios). There are also different gotchas with various hardware iterations stretching back to the initial MP spec by intel. (IE: It's hard to get right across a variety of hardware). Beyond that, it requires reading and parsing the ACPI tables, and setting up the APIC to do IPI. Could it be done? Yes. But it would be less of a bootloader, and more of a kernel. It's also more information the kernel needs to take into account, how IPI was setup as an example.
Perhaps a better way to go about this would be to provide a no_std library that made it easy to start CPUs instead, and people could drop that into their kernel. Similar things exist for ACPI, Serial, and a few more things.
And one more thought, each architechture has it's own method of doing SMP. ARM's process requires i2c communication to the other CPUs. Much different from INIT/SIPI on x86(_64) see docs here: https://developer.arm.com/documentation/102337/0000/Functional-description/System-Boot/Boot-flow-overview?lang=en
This makes it much harder to port the bootloader to other architectures, such as ARM and RISC-V, as you now need to implement SMP on for that hardware as well.