> 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. _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
