[coreboot] GeodeLX RAM initialisation issue

Nathan Williams nathan at traverse.com.au
Fri Nov 6 15:57:05 CET 2009

Marc Jones wrote:
> When linux does the reset, is the coreboot output the same? Does it do
> the "Resetting the processor"?

Yes, it does "Resetting the processor after PLL configuration for the 
changes to take effect"

I captured an example of my issue:


I made some more observations today:

 From Linux, a reboot from the command line works fine.  It only seems 
to  die when a fsck check fails on boot and forces a reboot.  The 
motherboard doesn't have a RTC backup battery at the moment, so to test 
I have been setting the clock in Linux, shutdown, remove the power 
supply for a few seconds, then boot up again.  Because the default time 
is in 1999, Linux runs a fsck which causes it to restart and die in 

Once coreboot crashes, a hardware reset doesn't fix it.  Coreboot will 
always stop at the same point.  Even removing power from the motherboard 
doesn't help.  However, I did find that by swapping the SODIMM to a 
different RAM module would boot.  I know it doesn't sound very 
scientific but it's what appeared to happen.

Is it possible that coreboot or maybe SeaBIOS is using incorrect values 
from non-volatile ram?

Another observation I made was that by setting the debug_level to 
BIOS_CRIT, instead of dying at the usual spot in disable_car() and 
stopping, coreboot would reset continuously (cycling every 1-2 seconds)

Another issue that's partly related is the ability for coreboot to set 
  the GeodeLink speed depending on the detected RAM speed.  As a 
work-around, we are only using 333MHz SODIMMs and have set the bootstrap 
bits for GLCP_SYS_RSTPLL[7:1] (section of LX databook) to 
500Mhz CPU, 333MHz GLIU instead of bypass mode.  In bypass mode, the 
GLIU is 266MHz and some of our 333MHz RAM will fail in disable_car(). 
As a test, I have experimented with
pll_reset(MANUALCONF, PLLMSRHI, PLLMSRLO) in initram.c in an attempt to 
change the GLIU to 333MHz.  I probably didn't have the correct bits set, 
so even though I managed to set GLIU, it failed the last test (DLL) in 
sdram_enable() and would reset.


More information about the coreboot mailing list