Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes: > On 16.07.2008 20:12, Eric W. Biederman wrote: >> Segher Boessenkool <[EMAIL PROTECTED]> writes: >> >> >>>> I just figure the default should be the current behavior. >>>> >>> Remind me, what _is_ the current behaviour? >>> >> >> Have one default SSVID/SSDID per motherboard, if that default >> value is not set I think we assume 0. >> >> The proposal was to have SSVID/SSDID programmed individually for >> each part on the motherboard. >> >> >>> I see two options: >>> >>> a) Don't program it, leave it at 0. >>> b) Program it the same as the factory BIOS does. >>> >> c) Program it to the proper value for a native LinuxBIOS board. >> > > The big problem with that is that we either have to get subsystem device > IDs from the board vendor (unlikely) or we allocate a vendor ID for > coreboot and start our own numbering (painful).
We just copy the vendor id and the subsys id that the board vendor uses. Or if it a pure LinuxBIOS board then ask the board maker for a pci vendor id, and device id for the board. I don't expect that to be too difficult for a company that is making it's own boards. > Indeed. The place for this is in the dts. > > >>> -- Every chip is programmed differently, so we need a driver for every >>> chip, even if coreboot doesn't care about any other chip specifics; >>> >> >> Assuming we even get the option. For anything not designed to be integrated >> on a motherboard you need a mechanism that programs the SSVID/SSDID before >> the firmware runs. Generally we would also need a driver if it is >> possible to disable that chip. I don't believe this is unreasonable >> overhead. >> > > I think doing this exactly the same way as a vendor BIOS is important. > Does the vendor BIOS really set the subsystem IDs before the option ROM > is run or does this happen afterwards? It is a PCI requirement that the SSVID/SSDID are set before software can read them, as running the option rom is optional. For onboard devices there is enough wiggle room they can ask firmware to program it. >>> -- OS drivers using this subsystem ID might use it to decide the chip >>> is configured in a certain way. >>> >> >> Then they are either (a) broken if it is software configuration or >> will (b) break if they are reasonably looking for hardware configuration >> and we don't provide it. Which argues for properly setting the SSVID/SSDID. >> > > We need to mirror that sonftware configuration anyway if we don't want > to change the drivers in every possible OS as well. > And "proper" values are very difficult to define if our device > configuration doesn't match what the drivers expect. Yep. >>> What are the downsides to not programming an SSID/SSVID? >>> >> >> The goal when the code was added was to correctly support the SSID/SSVID. >> With an ultimate goal of identifying a motherboard by looking at them. >> >> If someone is doing a quick port or a hack I agree ignoring the issue >> is better than doing the wrong thing. If you are doing a production >> quality port it isn't an especially hard thing to get right, and so >> if we have the opportunity we should set it. >> > > What about a global default which can be overridden per device? Most > boards I have use the same subsystem device ID for over 50% of the > devices on a given board, so this proposal would reduce the effort to > zero for reasonable motherboards. That is what I would implement. A global default. And if we don't specify the global default the global default is 0. Eric -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot