Dear coreboot folks,
Arthur pushed the proof of concept *Use FDT as payload handoff instead lb_tables* [1] to pass information to the payload via FDT instead of coreboot tables.
Julius asked for more background, and Arthur replied. I am moving the discussion to the list for broader visibility, and better way of discussing these things than Gerrit comments.
Were there any discussions about this that I missed (if so would you mind linking to them)? Can you explain who needs this and why, what's the overall goal? (I know there have been vague discussions about various new firmware handoff formats from Arm and Intel and others, but if this is related to those I missed the parts where there was suddenly consensus on how it should look, and why that is FDT.)
Most of the discussion happened verbally at osfc, so I can't point to any written communication. There is https://www.osfc.io/2022/talks/collaborative-firmware-payload-handoff-design... if you have the time to listen to a talk. So if I have to summarize the idea's/goals:
- Intel Universal scalable firmware suggested using UEFI HOBs as a handoff structure
- coreboot won't do that as it's no improvement over coreboot tables
- USF won't make coreboot tables a standard either
- Maybe something new can be created that would fit both the needs of payload handoff and other binary information passing between programs (e.g. FSP)?
- USF people suggested using CBOR to encode data to so that serialization/deserialization of data is explicit instead of using structs.
- CBOR is an improvement for the data format, but not what coreboot/(other project) should tell the payload: i.e. what entries are needed
- FDT was suggested as an alternative as it covers both explicit serialization/deserialization + what payload tell each other since the spec already exists, with a lot of existing compatible node strings. (e.g. I reuse simple-framebuffer from Linux here to hand of the framebuffer) Also most payloads and firmware have code for working with FDT.
- (unrelated to payload handof but part of the discussions) Another idea is to also use FDT as an interface between coreboot and FSP.
- a lot of payloads already have code to work with FDT so having FDT as a handoff structure would not be a lot of work
- FDT should make compatibility between coreboot and payload easier when handoff entries are added or changed (plain structs are painful if they are updated as both payload and coreboot definitions need to match)
- debugging the handoff structure is easier with FDT as you can use DTC in the OS userspace or coreboot code can also print out the full structure in human readable format.
What are your thoughts?
- Is it a good idea to use FDT and eventually replace coreboot tables.
- If so, do we keep both for a while to make transitioning easier? I think maintaining two structures is not sustainable long term.
- How should the 'entries' be structured? I made compatible nodes that map somewhat to existing coreboot table structs.
Kind regards,
Paul