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

[Andrey Korolyov]

> [1] Platform T2400/i945 ->
> http://ark.intel.com/products/27235/Intel-Core-Duo-Processor-T2400-2M-Cache-1_83-GHz-667-MHz-FSB
> ... Am I correct?

Yup.
> [2] What is GEODE in this context? 500 Mhz i486AMD Geode processor (Single
> HW threaded, one core, no HT)?

Just a remark about how I got warning that late - I went through usual
test routines on a non-SMP kernel because my basic test image does use
it by default, primarily it is designated to a DB800 dev board.
> [3] And what are the Linux distro and the distro kernel you are using
> (version and size ? 32 : 64, please)?

This is 32-bit CPU, so answer is obvious :) I think that I`m hitting
the problem independent of the kernel version I am running, but I`ve
tried few stable versions from 3.2 to 4.9 without spotting any
noticeable difference. Windows hangs as well as soon as it finishes
driver loading procedure, this is visible from safe mode.
> [4] Am I reading that you are not able to produce dmesg? If YES, please,
> post failing dmesg here!

Nope, this is not the case. May be initial text is not clear enough,
but I`m getting a 'dead' hang of the board itself - I mentioned that
SMI handler is not chewing anything after this point, all the
peripherals seem to be pretty dead as well, at least I was unable to
see anything past the failure via usb debug and serial console.
> [5] I assume that you have SeaBIOS as payload, don't you?
> [6] Are you booting via GRUB?

Yes, I am using SeaBIOS and GRUB for local boots. I could share a
successful non-SMP dmesg as well as part of SMP dmesg before hang, but
there are virtually zero points to take on. May be the only difference
between dmesg contents over stock one aside complaining about missing
hard-coded battery slot is the snip below, just because I didn`t fixed
this yet (specific to native gfxinit, but board also happily hangs
with stock vbios and smp kernel, just for the case)

[drm] failed to find VBIOS tables
vgaarb: device changed decodes:
PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[drm] initialized overlay support
[drm] capturing error event; look for more information in
/debug/dri/0/i915_error_state
>
>> - sometimes video memory is corrupted, screen displaying periodical
>> flickering pattern
>> (even if almost all late-stage linux drivers are disabled),
>
> [7] Are you able to produce Xorg.0.log messages? If yes, could you post 'em
> here?

I honestly don`t think that this is the case - for non-SMP boot, the
Xorg log absolutely resembles everything that I`m getting with vendor
bios and for SMP boot system hangs a bit earlier. Video memory
garbling is not a persistent but rather floating effect, forgot to
mention that.
>
> I have also other ideas how to debug this all, but lets go with these for
> starters, shall we??? ;-)

I thought about hidden interrupt storm which could possibly manifest
itself in that way, but I`ve never seen IS being *that* bad. Honestly
I`m out of ideas why turning on SMP results in a horrible memory
corruption/overlap, SMP-ed Memtest was able to pass few rounds without
any warning. Even if all platform and peripheral drivers blacklisted,
the problem still shows up, so it does not limit itself, at least
obviously, to one single device whose DMA region(s) splats over areas
where it shouldn`t be.