Marc Jones wrote:
On Tue, Nov 10, 2009 at 1:26 PM, Nathan Williams nathan@traverse.com.au wrote:
Marc Jones wrote:
On Fri, Nov 6, 2009 at 7:57 AM, Nathan Williams nathan@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.
Nathan