[coreboot] Trac reminder: list of new ticket(s)
c-d.hailfinger.devel.2006 at gmx.net
Thu Jul 17 02:28:54 CEST 2008
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).
>> There is a bunch of problems with b):
>> -- We have to keep a list of mainboards, and the user has to configure
>> for that mainboard, even if that board is essentially identical to
>> a whole host of other boards;
> Of course. This is something that lives in the per mainboard configuration
> and should be done at the time we port to a board. It should not
> be something that a user specifies in Kconfig we deciding to compile
> for a board.
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?
>> -- 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.
More information about the coreboot