Hi Everyone,
We have couple of queries regarding the current support and future direction of arm64 port of coreboot:
1. 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 ? 2. Does the current coreboot/arm64 port allow executing only the ramstage of coreboot (say as a means of reducing the coreboot binary footprint) ?
Best Regards, Sukanto
Am Mi., 20. Okt. 2021 um 11:04 Uhr schrieb Sukanto Ghosh via coreboot < coreboot@coreboot.org>:
Does the current coreboot/arm64 port allow executing only the ramstage of coreboot (say as a means of reducing the coreboot binary footprint) ?
I think that's really the gist of your inquiry, so let me stick to this part: The coreboot project obviously has little interest in "coreboot looking" firmware being made up of other (usually less Free-with-a-capital-F) components.
Regards, Patrick
Am Mi., 20. Okt. 2021 um 11:04 Uhr schrieb Sukanto Ghosh via coreboot < coreboot@coreboot.org>:
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) ? 1. If no, would coreboot community be willing to support such a flow (via a build-time flag) ? 2. 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 ? 2. 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?
Patrick
Hello Sukanto,
welcome to the coreboot mailinglist!
I'm not an expert on the arm64 port of coreboot. But generally the idea of coreboot is that it starts with the first instructions that are loaded from flash (or the reset vector, on platforms where its located in flash).
On 20.10.21 11:04, Sukanto Ghosh via coreboot wrote:
- Does the current coreboot/arm64 execute post BL31 stage (assuming a separate BL2 stage loads BL31 and coreboot) ?
I'm not sure if I understand the question. AIUI, the coreboot ARM ports act like BL2. So what would coreboot do if loaded by a separate BL2?
- Does the current coreboot/arm64 port allow executing only the ramstage of coreboot (say as a means of reducing the coreboot binary footprint) ?
Don't know what "allow" would imply here. It's not expected. Technically, it's possible though. If you prepare everything to look like a coreboot environment, coreboot's ramstage should work ofc. But I don't think it would reduce the overall footprint.
People sometimes want to integrate parts of coreboot with already written code for other frameworks, like you suggested. However in my experience, the effort to design clean interfaces and integrate everything together exceeds the effort to write a native coreboot port (often by an order of magnitude). I wonder, have you evaluated a native coreboot port yet? It might actually reduce your costs. Please consider it :)
Nico
After some more community discussion about what's going on here, a proposal:
Can you link to that discussion? I feel like I'm missing most of what's going on here.
In general, I can second what Patrick and Nico said: the notion of running coreboot "after" BL2 doesn't make any sense, because coreboot is supposed to be what BL1 and BL2 represent in the Trusted Firmware boot stage model. coreboot is not some application that you squeeze in somewhere in your existing firmware stack so you can put a "coreboot support" sticker on the box or whatever... coreboot is the core of the firmware stack that does enough platform initialization to allow other applications (what we call "payloads") to run. If you already have other code (like a traditional TF-A BL1/BL2) that does all platform initialization for you, there's no real point in you running coreboot. If you want to run coreboot, it doesn't really make sense to have another early platform initialization component in the same firmware stack. (At most, some platforms will call into a separate proprietary DDR initialization blob in the middle of coreboot's romstage for platforms that aren't willing to open source their DDR init code... but that should only be done in narrow cases where the responsibilities of that blob are clearly bounded and most of the platform initialization tasks are still handled in coreboot code, we don't want coreboot to just be an empty wrapper for something else.) In particular, I don't think having a "ramstage only" coreboot on an Arm platform makes much sense because the ramstage tends to be pretty empty on Arm platforms anyway (since they usually don't need to enumerate a tree of PCI devices, which is the biggest part of the ramstage on x86).
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.
Again I'm probably missing too much of the context here, but I'm not sure this is a good direction either. Is the goal to have a platform support both a normal Trusted Firmware BL2 and coreboot and somehow reuse the same code for both? That would probably become a pretty big mess in practice, similar to what we have in vendorcode on some platforms. coreboot has a standard way of doing certain things (e.g. the common APIs for GPIOs or SPI/I2C transfers), and you can't just integrate some other bit of code unchanged into it if it would need to use any of these functionalities that coreboot expects to be designed in a certain way. If you try to write a coreboot platform port that doesn't actually use any coreboot conventions or tie into any common coreboot frameworks, you're pretty much losing all the benefits of using coreboot in the first place. I could maybe see this work for some very isolated subsystem (e.g. DDR init), but more than that and you're gonna run into trouble.
-
Julius Werner -
Nico Huber -
Patrick Georgi -
Sukanto Ghosh