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

Nico Huber nico.h at gmx.de
Wed Jul 5 23:27:52 CEST 2017


I'd start with examining the coreboot console log. Are there resource
conflicts? Are all APs initialized? Was the microcode updated for all
of them? etc... If you don't have it already, you can grab the log from
your running non-smp OS with `cbmem -c` (see util/cbmem/ in the coreboot
tree). Feel free to attach it, if you want somebody else to look through
it.

Nico

On 05.07.2017 19:01, 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.
> 




More information about the coreboot mailing list