[coreboot] GeodeLX RAM initialisation issue

[Marc Jones]

On Mon, Nov 23, 2009 at 12:27 AM, Nathan Williams
<nathan at traverse.com.au> wrote:
> Marc Jones wrote:
>> 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
>>>>> 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.
>>
>> 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 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.
>>
>> 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.
>>
>> Marc
>>
>>
>
> I managed to get the commercial BIOS to boot on my board and diffed it with coreboot:
>
> http://coreboot.pastebin.com/m39b22c21
>
> The only differences I can see are related to interrupts, which shouldn't matter in relation to
> my RAM problems.
>
> I have also run a memtest86 with the commercial BIOS (from bootable CDROM) and as a payload in coreboot.
> The commercial BIOS didn't have any errors, but my coreboot did.  So the hardware can't be too bad.

That looks like just the southbridge cs5536 target. The memory
differences would be in the processor geodelx target. Can you send
those results?

Marc




-- 
http://marcjonesconsulting.com