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