Am 22.09.2011 12:53, schrieb Oskar Enoksson:
Checking out and compiling the latest git-version of coreboot yields 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 stable.
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.
Patrick