Hacker News Reader

Comment by throwaway889900 | Hacker News Reader

Of all the sections in the tutorial, https://github.com/isometimes/rpi4-osdev/tree/master/part10-... is probably the best one for anyone to read. I don't think a lot of people grasp that all the cores on a system start running immediately on power up and they're all running the same code from memory initially.

View on HN

That depends on the architecture. E.g., Intel uses a wired-OR circuit and the cores race to determine who booted first, then that core becomes the boot core and executes the first instruction from boot ROM.

I'm assuming a simplistic CPU architecture aimed towards beginners, which is generally what a tutorial is aimed at. From there you can learn about all the nitty gritty details that you need to get actual chip to work.

I think the point is that on a standard x86 PC the cores don't all start running from reset; one boots up and the others are halted, waiting for the OS to start them (usually via the APIC.)

What happens when they all race to store to the same memory location? I guess if they all run in lockstep it doesn’t really matter?

I’ve worked with some ARM SoCs from NXP and I could have sworn that one core comes up first and the others get released from reset later, with a “bringing up secondary CPUs” message printed.

The code that runs at startup makes sure they don't all write to the same location :-) A common simple approach goes:

  * read the CPU main ID register
  * if core 0, branch to primary-core bootup code
  * otherwise, go into a loop (eg "read x from known location for this core, if x is non zero branch to x, else keep looping")
  * core 0 releases each secondary from the loop when it is ready -- this is when core 0 prints that "bringing up secondary CPUs" message

(There are a bunch of minor variants on this, eg waking secondaries by sending them an interrupt so they can sleep via wfi insn instead of busy looping, but the basic approach is always the same.)

It is also possible to do this in hardware -- you can have an SoC with a power controller so secondaries start powered off or held in reset, and the primary core prods the power controller to start each secondary.

On 64-bit Arm the common standard is that this is all handled by the firmware (which implements a standard ABI called PSCI), and the OS code just makes SMC calls into the firmware for "power on the secondary". (The firmware does something like the above under the hood.)

The code that runs at reset on the Arm CPU complex for the RPi: https://github.com/raspberrypi/tools/blob/master/armstubs/ar...

This is assuming an asymmetric multiprocessing model. It may be that the hardware is set up as such, but symmetric multiprocessing is also an option which is what the Pi seems to do.

No, this works fine for symmetric configs. The OS can treat all the CPUs the same once they've booted, you just need to pick one of them arbitrarily to run the initial bootup code, which is conventionally the one with ID 0. Calling that one 'primary' and the others 'secondaries' is just convenient terminology when dealing with this kind of bootup code.

This is how the Pi is brought regardless of if you use SMP or AMP.

They don't all store to the same location.

Reply on news.ycombinator.com