Forgot to add coreboot@coreboot.org in cc.
---------- Forwarded message --------- From: Arthur Heymans arthur@aheymans.xyz Date: Wed, Nov 9, 2022 at 6:41 PM Subject: Re: [coreboot] Re: [RFC] POC: Use FDT as payload handoff instead lb_tables To: ron minnich rminnich@gmail.com
I think it is possible that, over a few years, we might see fdt replace
coreboot tables. It might be a natural evolution. If you go with the stage approach, it will never happen. We'll always need coreboot tables as input to the fdt stage.
I'm not seeing a natural evolution happening anytime soon. There really
isn't a good enough technical reason to replace coreboot tables. If those 2 solutions live side by side in the same stage it will 100% end up in a case of https://xkcd.com/927/
I think the stage is the wrong way to go. I want it to be possible to have the option to build without coreboot tables.
This is more messy than you might think. A lot of code that is used in creating data structures to create coreboot tables would need to be rewritten to fit the needs to just generate FDT. https://review.coreboot.org/c/coreboot/+/68768 is one example. In the end it also boiled down to parsing a coreboot table entry struct into FDT.
So if creating an FDT handoff boils down to parsing coreboot table structures even when implemented in ramstage, I don't see good arguments why it cannot live in a separate stage, as you effectively end up needing both data structures. Or is avoiding consuming a few 100's of bytes for the coreboot tables really worth it? Creating FDT handoff == parsing coreboot tables anyway, whether it lives in ramstage or separate stage...
To some extent I think the stage mechanism is overused. In fact, in oreboot, we removed stages.
I agree and I removed some from coreboot ( https://review.coreboot.org/c/coreboot/+/55068), but in this case I could see a separate payload/stage as a good way to separate 2 things trying to achieve the same purpose. Maintaining both solutions in the same program is messy and something I'd like to avoid. Another advantage is that you don't need to rebuild coreboot to generate your needed handoff if you change payloads. If I want to change out the EDK2 FDT payload with a LinuxBoot added with cbfstool, that will just work. With FDT/coreboot tables behind Kconfig it won't.
Arthur
On Wed, Nov 9, 2022 at 5:07 PM ron minnich rminnich@gmail.com wrote:
I think it is possible that, over a few years, we might see fdt replace coreboot tables. It might be a natural evolution. If you go with the stage approach, it will never happen. We'll always need coreboot tables as input to the fdt stage.
I think the stage is the wrong way to go. I want it to be possible to have the option to build without coreboot tables.
To some extent I think the stage mechanism is overused. In fact, in oreboot, we removed stages.
On Tue, Nov 8, 2022 at 11:48 PM Arthur Heymans arthur@aheymans.xyz wrote:
So just to be clear, to make sure we weren't taking different things away from that meeting: I said I'm okay with adding the FDT option as a separate, isolated compile-time option for those that want to try it out. But I care that the coreboot tables continue to be supported on equal footing in the long term, and I don't want there to be some pre-formed understanding that they'll be "deprecated eventually" or that payloads will be slowly pressured to move to the FDT handoff, particularly not with any specific timeline attached.
With this in mind I don't see any reasons why generating the FDT handoff
needs to happen in the coreboot ramstage. A libpayload based payload could just as well generate that FDT handoff and chainload the next payload. All the infrastructure is there in libpayload to cleanly do this. The coreboot code for dealing with FDT is exactly the same as deptcharge code (it comes from that project). This is a better technical solution than to introduce new Kconfig guarded code and maintenance overhead inside the coreboot tree to maintain 2 solutions for the same problem. As a matter of fact that solution is even more 'universal' as you could still swap out payloads without recompiling the coreboot part of things.
Arthur
On Tue, Nov 8, 2022 at 11:55 PM Julius Werner jwerner@chromium.org wrote:
As mentioned by Julius, we had a candid discussion yesterday on this,
while he still reserves his opinions on FDT, he will not block the implementation. For now we will guard it with kconfig and give it a year of trial to see how it turns out.
So just to be clear, to make sure we weren't taking different things away from that meeting: I said I'm okay with adding the FDT option as a separate, isolated compile-time option for those that want to try it out. But I care that the coreboot tables continue to be supported on equal footing in the long term, and I don't want there to be some pre-formed understanding that they'll be "deprecated eventually" or that payloads will be slowly pressured to move to the FDT handoff, particularly not with any specific timeline attached.