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

[Zoran Stojsavljevic]

Andrey (Korolev),

You got all my points. Both of them. It is on you... What you'll do.

But whatever you do, please, post results here. :-)

Zoran

On Thu, Jul 6, 2017 at 2:06 PM, Andrey Korolyov <andrey at xdel.ru> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170706/fd4ac674/attachment.html>