Hello,
This would fit nicely for POWER9 boards using Skiboot as a payload. I started a discussion related to that some time ago [1], since then we decided to switch to generating FDT in code. Basically, we did some parts of mentioned POC but at SoC level, to not break existing code. Having it as common code would make it much easier to maintain.
What are your thoughts?
* Is it a good idea to use FDT and eventually replace coreboot tables.
I think FDT is widely supported, from embedded platforms to servers, on many different architectures. I've got a feeling that whenever Intel talks about "universal", it usually means "x86-only", or at least "lets make it work for x86 and others can worry about their architectures later".
FDT is usually exposed by kernel so you don't need `cbmem` util for simplest cases, but I guess it would still be nice to have to decode specific tables. However:
* If so, do we keep both for a while to make transitioning easier? I think maintaining two structures is not sustainable long term.
Persuading kernel to parse FDT on x86 platforms and propagating that change to kernels included in distros can take some time. Meanwhile, `cbmem` could be used to read the data instead, but it also would have to be made aware of the transition. IIUC currently it chooses between FDT and coreboot tables based on architecture it is built for. Users would have to update `cbmem` together with firmware, which may not always be the case.
* How should the 'entries' be structured? I made compatible nodes that map somewhat to existing coreboot table structs.
As for standard coreboot tables like timestamps or console, for me existing format looks good. Just make sure to explicitly define endianness of fields :)
Based on experience with POWER9, we need to be able to both create entries specific to given SoC (e.g. XSCOM ranges, which is something between MSR and root complex "PCIe" devices) and to modify entries generated by common FDT code (Skiboot expects chip IDs on some of the entries when there are more CPUs on board). This can be easily done by having callouts to platform- and arch-specific code. Current FIT code doesn't work for the latter case, because call to `fit_update_memory()` happens after platform is allowed to modify the tree.
[1] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/6EZWU...