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

[Andrey Korolyov]

On Thu, Jul 6, 2017 at 8:20 AM, Zoran Stojsavljevic
<zoran.stojsavljevic at gmail.com> wrote:
> 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?
@Zoran

Thanks, that could be the point, though it seem to be same low for
X/T60 [0]. I would check if reading PCI space in Linux would result to
same small address and may be this is the point (also I could quickly
run completely headless kernel to verify that).

>
> Andy (Korolev),
>
> Did you manage to get to Linux emergency mode called Dracut?

I think that you meant dracut-produced initrd and try it against SMP
kernel, right? If I could get your idea, you are possibly suggesting
to cut off every device from being initalized except SuperIO, get to
ramdisk and try to work things out from there? I didn`t tried this
yet, mainly because I don`t want to spend much time with blind efforts
on very old laptop whose support has almost no real value... If I am
wrong, please explain what you`ve suggested in there.

>
> 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
That`s what I meant under 'spending few days', getting memory access
during both cold-boot run and DMA-assisted run is a matter of tens of
minutes, but the analysis of the dump would take much more time. The
main problem is that I am losing dynamic picture for memory contents
if I would do only post-mortem analysis and (with cold-boot attack)
I`ll lose small portion of the memory state anyway, due to
bootloader`s needs to initialize PCI devices (though I could imagine
very slow and boring transfer using CAR and USB debug port and there`s
bit of code need to be written for that). The fastest way to get close
to the point of failure and see at least a dynamic stuff is, probably,
a timer-based non-preemptible hack within ieee1394 driver which would
literally freeze system to allow me to take snapshots without risk of
hitting crash in the middle. Anyway, this closes down to analysis of
what is going on within the dump and with Linux mm it`s not an easy
task if you are not searching for something specific like LUKS key :)

0. https://mail.coreboot.org/pipermail/coreboot/2014-October/078752.html