[coreboot] Trac reminder: list of new ticket(s)

[Eric W. Biederman]

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
>> 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