[coreboot] GeodeLX RAM initialisation issue

[Nathan Williams]

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 BIOS_CRIT,
>> 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.

>>
>> 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 6.14.2.13 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.

Regards,
Nathan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: device_SPEW.patch
Type: text/x-patch
Size: 454 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20091111/fc60497d/attachment.patch>