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

[Zoran Stojsavljevic]

> kernel also is unable to produce any kind of backtrace over all (easily)

available channels,

[1] Platform T2400/i945 ->
http://ark.intel.com/products/27235/Intel-Core-Duo-Processor-T2400-2M-Cache-...
... Am I correct?
[2] What is GEODE in this context? 500 Mhz *i486*AMD Geode processor
(Single HW threaded, one core, no HT)?
[3] And what are the Linux distro and the distro kernel you are using
(version and size ? 32 : 64, please)?
[4] Am I reading that you are not able to produce dmesg? If YES, please,
post failing dmesg here!
[5] I assume that you have SeaBIOS as payload, don't you?
[6] Are you booting via GRUB?
> 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 have also other ideas how to debug this all, but lets go with these for
starters, shall we??? ;-)

Thank you,
Zoran

On Wed, Jul 5, 2017 at 7:01 PM, Andrey Korolyov  wrote:
> Hi,
>
> since I`ve got em100 few days ago, I decided to test it against one of
> my x86 devices and try to put coreboot on it at once. The selection
> was Z61m (T2400 CD/i945/82801). After fixing few things in i945 code
> borrowed from t60, I noticed severe problem when I tried to use SMP
> kernel, because most times I try stuff against non-smp i486 which is
> common denominator for Geode. It looks like that all SMP boot-ups will
> hang quite soon, just after a few seconds after jumping into
> initrd/driver initialization stage.
>
> There are few points:
> sometimes video memory is corrupted, screen displaying periodical
>
> flickering pattern (even if almost all late-stage linux drivers are
> disabled),
> the hang itself is not accompanied by any SMI assertion or event
>
> otherwise visible in the coreboot log,
> kernel also is unable to produce any kind of backtrace over all
>
> (easily) available channels,
> usb port with an active usb stick may become unusable until entire
>
> device is power-cycled with external switch,
> SMI poweroff handler is not responsive after the failure event.
>
> 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?
>
> Thanks.