Kurt Kennett <kurt_kennett@...>
My understanding of ARM secondary core startup is that the stacks for all the cores live at the top of UEFI memory.
The secondary core stacks sit at the top, with the primary core stack just under them.
The PrePi code for ARM runs on those stacks, and the cores enter a WFI loop waiting to be released to do useful work.
The problem I have seen is that the UEFI stacks are set at EfiBootServicesData memory type.
This memory is reclaimed by the OS from the EFI memory map when it starts.
This is a problem because the secondary cores will execute code ON THOSE STACKS when they are released. This means they
1) can corrupt that (physical) memory by writing to it before they jump to the OS entry point for those cores
2) crash because of stack contents for their local variables being garbage.
Can anyone confirm this is a problem? If it isn't i want to know what i'm missing.
Is the OS-specific bootloader expected to release those cores and put them into an OS wait loop on 'safe' stack memory and code prior to launching the OS?