Thought about this more and flip-flopped again, I think we should just stick with this patch. The other idea was modeling SRAM in the coreboot table so the payload could map it, but the problem remains that for the majority of Arm platforms we have, SRAM isn't accessible in non-secure EL2 after BL31 runs anyway. Mapping inaccessible memory as normal/write-back is dangerous even the program flow never accesses it, so adding that memory type would mean that coreboot has to know exactly what ranges BL31 does or does not protect. That is a hard mapping to maintain manually and not easy to notice if it breaks. When I came up with this I thought that it would also solve an issue of checking that BL31 targets usable memory during selfload(), but I forgot that we had already solved that issue with BM_MEM_BL31 (which is only used in coreboot and not passed on through the coreboot table), so it wouldn't really add anything there. It remains that doing the CBMEM migration here just doesn't cost enough to be worth creating new interfaces that bring their own problems instead.

Patch set 1:-Code-Review

View Change

To view, visit change 33952. To unsubscribe, or for help writing mail filters, visit settings.