Hi (again) coreboot:
My original question got lost in the list probably because of a bad
subject, so I'm asking again with a better one.
I read that after 4.7 we are going to drop older platforms without
"cbmem support in romstage", and that includes one that I brought into
coreboot. I am
>
> 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
>
Nico Huber wrote:
> > 0x42D3B3000 - working integrated graphics ROM !!!
> >
> > 0x42D305020 - working discrete graphics ROM (first working copy, the same)
> > 0x42E40DCD0 - working discrete graphics ROM (second working copy, the same)
>
> nice work! If these are physical addresses, dumping from
Hi,
On 07.07.2017 20:03, Mike Banon wrote:
> === ROM locations examples for 0x0 - 0x42F00 dump made while 16GB RAM:
>
> 0x000512000 - broken integrated graphics ROM, first "ghost"
> 0x3250D9020 - broken integrated graphics ROM, second "ghost"
> 0x3578FB000 - broken integrated graphics ROM,
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
> 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
6 matches
Mail list logo
