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

[Zoran Stojsavljevic]

OK, both Andrjusas,

I am a bit ignorant, and I read beginning of the Coreboot log:

DIMM 0 side 0 = 1024 MB
DIMM 0 side 1 = 1024 MB
DIMM 2 side 0 = 1024 MB
DIMM 2 side 1 = 1024 MB
tRFC = 43 cycles
Setting Graphics Frequency...
FSB: 667 MHz Voltage: 1.05V Render: 250MHz Display: 200MHz
Setting Memory Frequency... CLKCFG = 0x00010023, CLKCFG = 0x00010043, ok
Setting mode of operation for memory channels...Dual Channel Interleaved.
Programming Clock Crossing...MEM=667 FSB=667... ok
Setting RAM size...
C0DRB = 0x40404020
C1DRB = 0x40404020
*TOLUD = 0x00d0 <<==========???*

4GB (two channel) memory, in two slots out of 4... ?!

Top of Low Usable RAM 00d0h??? Any explanation for that?

Andy (Korolev),

Did you manage to get to Linux emergency mode called Dracut?

Zoran

On Thu, Jul 6, 2017 at 6:50 AM, Andrey Petrov <andrey.petrov at intel.com>
wrote:

>
>
> On 07/05/2017 10:01 AM, Andrey Korolyov wrote:
>
> The fourth/fifth points has very high likeness for the fact that the
>> regular kernel debugging would not help at all and I hardly imagine
>> myself spending few more days to manage firewire memory 'sniffer' to
>> work, though this method has highest successful potential among other
>> approaches, excluding (unavaiable due to pricing of the counterparting
>> LA) memory interceptor. What could be a suggestion to move on with
>> least effort at this point?
>>
>
> So you are after memory contents? Freeze DIMMS, turn off memory scrambling
> and flash firmware that dumps memory contents. In essence, cold boot attack.
>
> Andrey
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170706/a74e03ae/attachment.html>