[coreboot] x86: best approach to debug consumer hardware?

[Nico Huber]

On 08.07.2017 15:43, Andrey Korolyov wrote:
>> From git logs it looks like configuring the clockgen was needed for the
>> x60/t60 port for deeper c-states to work. I'd try to dump the clockgen
>> configuration on smbus with block operations ('i2cdump #smbus 0x69 s')
>> and configure it using block write operations either in romstage (look
>> at thinkpad x201 romstage.c) or in ramstage like is done for the x60
>> (might need some tweaking).
>>
> 
> I see, thanks. Previously write to i2c-0/0x69 has been stuck at
> romstage, so I kicked it out without looking at the log and therefore
> not getting reasons why is was there at first place, Now it is obvious
> that C3 is not working correctly without fixing up clock generator.
> Previously, also, I blamed incorrect _CST package generation from
> copy-paste from T60 for a moment - state descriptions has been
> enumerated as 0x1/0x2/0x2 while vendor BIOS has sequentially
> enumerated descriptions, still wondering what was the reason to do so.

I'd expect the clockgen to be the culprit too. But this C-state number
could be a typo and also be the reason for your trouble (though, I'd
wonder why it works on the T60). This number is used to map ACPI C-state
semantics to the states presented in _CST. ACPI knows three C states and
those rarely match the actual C states of the hardware. Basically, a 3
instead of a 2 tells ACPI to flush caches before entering this state.
Also, ACPI C3 is to be avoided if bus-master activity is expected.

Nico