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.
I got the impression that the core discussion in this thread was centered around whether payloads may contain board-specific drivers (or hardcode board-specific information), vs. coreboot having to gather all that information and pass it to the payload in a board-agnostic way. I just tied in to your earlier email to respond to that general question, rather than the more specific details about parsing ACPI tables or whatever that were discussed later. I just wanted to say that I think hardcoding board-specific stuff in payloads is perfectly fine and something we have been doing for a long time (I guess "always" is too long a timeframe for a project as old as coreboot, but at least depthcharge has done this for as long as it existed).
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?
I mean just for allowing the payload to operate the device. I agree that the "silicon init" part has traditionally all been in coreboot, but sometimes you have devices that don't require any "silicon init" (and therefore coreboot doesn't really know or care about it), but the payload may still want to use it, and therefore may need to know chipset- or board-specific details about it.
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.
Using generic tables is fine when they exist, but they don't always and I don't think coreboot needs to invent them wherever they don't. In practice we often use these ID numbers to enable workarounds for some odd and subtle bugs on certain board revisions that we've never quite encountered in that form before -- if we were trying to design a new generic table for each of those cases all the time, we'd be adding three coreboot table entry types per platform that we bring up. These IDs are usually not the first resort for tying things together, we just like to have them available as the last.
Also, you still need to hardcode *some* board-specific information anyway. For example, you can't just bundle every audio codec driver that you support -- you'd be bloating your payload size unnecessarily. You want to only compile in the one this board is actually using, which is a form of hardcoding. If you're going that far already, what difference does it make if you hardcode a little more information (e.g. what I2C bus it's connected on) when there's no good existing mechanism to pass that information through from coreboot?
(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?
The kernel image has a bunch of possible device trees bundled in it and the payload picks the right one from those based on an identifying string containing these IDs (e.g. "google,bob-rev2-sku1"). The payload looks it up but the device tree itself (including that identifying string) is defined in the kernel repo, so the kernel also "knows" about these IDs (at least in its source repository, not in the resulting executable).
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 :)
Okay, fair enough. Angel commented on the CL that this email thread needs to get resolved before the patch can land, so I wanted to try to help resolve it. Sounds like we're all okay with the patch moving forward then.