Am 22.09.2011 12:53, schrieb Oskar Enoksson:
Checking out and compiling the latest git-version of
no output whatsoever on the serial console. Something is definitely
very broken and there is no clue.
It's possible that things are _very_ slow.
This sometimes happens if
printk is used before serial is properly setup. In this case, coreboot
sometimes drives some semi-random IO port as serial, waiting for time
outs all the time. Alternatively, the right IO ports are used, but the
wrong configuration (eg. 1200baud, while everything else expects 115200).
It's also possible that things just hang at some point. Do you have a
POST card? It should help you figure out if things move at all, and if
not, where it hangs.
Checking out the version just after my commit
2010-08-20 compiles and
seems to boot, but depending on how much debugging messages I choose
in "make menuconfig" I get different problems such as just one of my
two CPU's initializing, or just strange lockups.
You could try to use git
bisect to figure the revision that breaks for
you. For this, you'll need to find the git commit id for the svn rev of
last year (see commit log, each git commit that was converted from svn
contains the svn rev id there).
r5723 is git commit 37106a762a2158003c6267873fd6ebc1ec5d685e
In general, I think the best approach is to have upstream work at all
again first (even with only one processor or strange lock ups), and then
improve from there.
In general more debugging messages makes it more
That indicates timing problems. The console code should ensure that
side-effects by printk arguments are always executed.
Question1: is there any known version of gcc/binutils
that is known to
work well with coreboot?
The one built by "make crossgcc" (or entering
util/crossgcc and running
buildgcc there) is supposed to work.