Hi Julius,
wasn't sure if you are addressing me personally. I'll assume these questions are meant for me as you replied to my mail.
On 26.10.20 23:27, Julius Werner wrote:
Generally, I wouldn't assume / want board-specific drivers outside of coreboot. It seems board-specific table entries would invite people to write such
I don't think this is encouraging board-specific drivers; just trying to pass information to the payload here, that's all.
Wouldn't that payload then naturally contain a board-specific driver? I mean is it just displaying or storing the information or is it acting on it?
Yes, payloads contain board-specific drivers.
Did anybody deny that? Your "Yes" seems to imply it.
Isn't that how it's always been?
Considering Linux on a PC as the first payload, I think no.
We have always had a split of responsibility between coreboot and the payload -- for example, USB, storage devices, audio devices, etc. have always only been initialized in the payload and coreboot generally doesn't know anything about them.
Let's digest this slowly, as I really don't know anything but x86 well and don't want to make false assumptions. Do you mean initialization as something that needs to be done so the OS can operate the device (this is what Intel would call "silicon init"). Or just so that the payload can operate the device?
How else is the payload supposed to do that other than hardcoding board-specific knowledge?
More generic tables, for instance? On x86 we have ACPI, and you also mentioned kernel device trees. And I assumed so far that the intention of the coreboot tables also was something like this: to explicitly state the information a driver needs, and not implied by an id.
(I wasn't sure if this question was rhetorical. Let me know if you need a more elaborate answer.)
On Arm platforms generally none of these devices are enumerable, so the payload needs to know what address to find the eMMC controller at, needs to have a driver to talk to it and needs to know the maximum speed supported by the eMMC part on that board. We do all of this by hardcoding board-specific information, and occasionally (e.g. when multi-sourcing eMMC parts on what's otherwise the same board) it is convenient to support multiple board SKUs in the same image by looking up this information in a table indexed by a strapping ID. When the device this information belongs to is wholly controlled and initialized by the payload and coreboot doesn't know anything about it, I think it makes sense for that table to also be in the payload.
Thanks, I assumed that you do it like this (with exception of the definition of "initialization"; question above) but never looked.
(Note that on Arm devices we take this even further, and those strapping IDs are also used to look up the right kernel device tree to make sure the kernel can have the right information about those strapping-dependent devices. It's board-specific information all the way down.)
Is it the kernel that looks up the correct device tree or is this still done in the payload?
We've been using this set of strapping IDs for many years, Tim's patch is just more efficiently organizing a set of existing concepts that had been slowly added piece by piece over time. I hope it shouldn't be too controversial.
Sorry if I made the impression. I don't think it's controversial. It seems like the right step for the path taken. I didn't understand why this path was taken and Tim asked for comments, hence I thought it's a good opportunity to discuss that as well. Not to criticize or bike- shed anything, but just to have talked about it and learn from one another :)
Nico