We have couple of queries regarding the current support and future direction of arm64 port of coreboot:
- Does the current coreboot/arm64 execute post BL31 stage (assuming a separate BL2 stage loads BL31 and coreboot) ?
- If no, would coreboot community be willing to support such a flow (via a build-time flag) ?
- Beyond the direct access of EL3 registers, what are the other assumptions that the current coreboot/arm64 port has that need to be addressed to allow such a NS-EL2 port ?
- Does the current coreboot/arm64 port allow executing only the ramstage of coreboot (say as a means of reducing the coreboot binary footprint) ?
After some more community discussion about what's going on here, a proposal:
TF-A is 3-clause BSD licensed which is compatible with the GPLv2 used by coreboot. We already integrate that source tree in coreboot via git submodules (3rdparty/arm-trusted-firmware).
What we could do to reduce your maintenance burden is to extend the coreboot build system so that it can include sources from TF-A as part of its romstage build. There'd be some work required to paper over the API differences, and the end result (the coreboot-style romstage containing TF-A code) would be a combined work under GPLv2.
This requires that everything becoming part of this amalgamation needs to be GPLv2-compatible (coreboot code: GPLv2, TF-A code: typically 3-clause BSD given their licensing regime).
Is that workable for you?
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado