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@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@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot