[coreboot] Trac reminder: list of new ticket(s)
Eric W. Biederman
ebiederm at xmission.com
Thu Jul 17 08:06:08 CEST 2008
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> writes:
> On 16.07.2008 20:12, Eric W. Biederman wrote:
>> Segher Boessenkool <segher at kernel.crashing.org> 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
> 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.
>>> 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.
More information about the coreboot