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 <and...@xdel.ru> wrote: > On Thu, Jul 6, 2017 at 8:20 AM, Zoran Stojsavljevic > <zoran.stojsavlje...@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 >
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
