[coreboot] GeodeLX RAM initialisation issue

Marc Jones marcj303 at gmail.com
Wed Nov 11 00:07:53 CET 2009

On Tue, Nov 10, 2009 at 1:26 PM, Nathan Williams <nathan at traverse.com.au> wrote:
> Marc Jones wrote:
>> On Fri, Nov 6, 2009 at 7:57 AM, Nathan Williams <nathan at traverse.com.au>
>> wrote:
>>> Another observation I made was that by setting the debug_level to
>>> instead of dying at the usual spot in disable_car() and stopping,
>>> coreboot
>>> would reset continuously (cycling every 1-2 seconds)
> Since I needed to have a BIOS that didn't have much debugging enabled for a
> customer sample, I looked a bit deeper to find the cause of this continuous
> reset behaviour.  Even changing the debug level from BIOS_SPEW to BIOS_DEBUG
> caused the reset.  I tracked it down to a single  printk and my attached
> patch means it works at BIOS_CRIT now, just with a few extra debug lines.
>  Without the printk, the code gets to "missing phase4_read_resources" (just
> a few lines down from my patch) before restarting.

This sounds like it is probably blowing the stack or the stack hits
memory that isn't working correctly.

>>> 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.
>> Your second problem might explain the first. You should look closely
>> at the detection problem. It depends on the reset and the state of the
>> rstpll flags. There could be a corner case or something unusual going
>> on. How did you set the boot strap bits with hardware (straps)? You
>> should use pll_reset(ManualConf) settings to change it with hardware.
>> Marc
> Sorry, I should have explained that we set the boostrap bits in hardware:
> Bit 7: PW1 pad - active high when the PCI clock is 66 MHz, low for 33 MHz.
> Bit 6: IRQ13 pad - active high for stall-on-reset debug feature, otherwise
> low.
> Bit 5: PW0 pad - part of CPU/GLIU frequency selects.
> Bit 4: SUSPA# pad - part of CPU/GLIU frequency selects.
> Bit 3: GNT2# pad - part of CPU/GLIU frequency selects.
> Bit 2: GNT1# pad - part of CPU/GLIU frequency selects.
> Bit 1: GNT0# pad - part of CPU/GLIU frequency selects.
> We have pulled these pins up or down to be "0010110", which corresponds to
> CPU 500MHz, GLIU 333MHz in table 6-87.  This should also mean that the on
> reset, the value of GLCP_SYS_RSTPLL should be 0000049C_0300182Ch (except
> that SWFLAGS (GLCP_SYS_RSTPLL[31:26]) is only reset to 0 on Power On Reset
> (POR).  So I should be using pll_reset(ManualConf)?  I'll try it later today
> and see if I can get some debugging output.

If it is set by straps, it should be doing the right thing and you
don't need to use the ManualConf. There could still be a corner case
and you should try trace through the soft reset that is causing the
problem. Also, have you diff'd the MC settings between the BIOS and
coreboot. I would be interested in discrepancies.



More information about the coreboot mailing list