On Wed, Oct 21, 2020 at 4:00 PM Nico Huber <nic...@gmx.de> wrote: > On 21.10.20 21:19, Tim Wawrzynczak via coreboot wrote: > > Currently there are 3 different "strapping" entries in the coreboot > tables, > > and with the recent addition of fw_config ( > > https://review.coreboot.org/c/coreboot/+/41209), we would also like to > add > > the 64-bit fw_config field (updated here > > https://review.coreboot.org/c/coreboot/+/45939) to the coreboot table as > > well. > > > > In this patch (https://review.coreboot.org/c/coreboot/+/46605), I am > > proposing to deprecate the 3 current "strapping" entries (board ID, ram > > code and SKU ID), and add them all to 1 entry, containing board ID, ram > > code, SKU ID as well as fw_config. This saves the overhead of parsing 4 > > different entries to obtain board configuration information. > > > > Would like to hear any thoughts on this, > > I'm actually very confused about these things and how they are supposed > to be used. Is it correct to say that there are / would be coreboot > table entries with board-specific encodings?
There already are :) Board ID, SKU ID, and RAM Code are inherently mainboard (family) or vendor specific conventions. I see FW_CONFIG as yet another one of these strapping fields. > Wouldn't it be better to > decode the infos first and put that into tables so generic drivers can > consume them? That's an interesting thought, Nico. Can I assume you're talking about the coreboot table here? What I'm trying to accomplish here is to be able to pass the FW_CONFIG value from coreboot to the payload, in my case, obviously depthcharge. You can see some of our uses for fw_config in coreboot already, in mb/google/volteer for example. Some of the fields are distinguishing which daughterboard or audio device is on a given mainboard, which in these cases is not enumerable information, hence my thought to pass the fw_config value to the payload. This alleviates needing the payload to know where this information came from, as coreboot has already done the work to figure that out. > 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. > Sorry if I completely misunderstood the intention of these entries. > I just hope I have explained myself well enough for others to understand :) > > Nico > _______________________________________________ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org >
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
