Closed danh-arm closed 10 years ago
I've got an updated patch for this - it cuts out 40KB of RAM usage, half from BL1 and half from BL2.
Just to make a note of things we discussed face to face...
Some platforms may still need stacks for each CPU if they have the situation where secondary CPU's are released from reset at the same time as the primary CPUs and they need to boot further than a simple holding pen, and all the way into BL31; e.g. because they need to make use of run-time services like PSCI to power themselves off again.
As Andrew pointed out, even in this case, there is no reason for BL2 to have more than one CPU stack.
And thinking about it more, and I can't remember whether this was discussed, I guess it is possible for secondary CPU to stay in a holding pen in BL1 until BL31 release's then, and they can jump straight into BL3 anyway.
So perhaps there is no legitimate reason for secondary CPUs to have there own stacks in running BL1 or BL2 code after all, and this enhancement issue faces no obstacle to implementation.
I'm trying to get some internal feedback on this patch before posting it on GitHub for review.
I agree that the holding pen scenario should not need extra stacks in BL1 or BL2 - you probably wouldn't want to release these cores into BL3-1 to issue a PSCI shutdown until PSCI is initialised anyway.
If necessary in future, it wouldn't be difficult to modify for individual BLs or to make the selection more flexible.
On the FVPs, all components currently use the FVP plat_common.c and common plat_helpers.S source to allocate the normal and coherent stacks. These create one stack per CPU, which results in significant additional RAM usage in BL1 and BL2, which only run on the primary CPU.
BL1 and BL2 should only allocate stacks for the primary CPU.
The below patch is a proof-of-concept that showed a 36KB reduction in SRAM requirements (the stacks are now larger and this could be an under-estimate).
Note - the patch is now out of date and will not apply cleanly.