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:
wouldn't assume / want board-specific drivers outside of
coreboot. It seems board-specific table entries would invite people to
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
Yes, payloads contain board-specific drivers.
Did anybody deny that? Your "Yes" seems to imply it.
Isn't that how it's
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
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
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,
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
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