On Mon, Nov 23, 2009 at 12:27 AM, Nathan Williams <[email protected]> wrote: > Marc Jones wrote: >> On Tue, Nov 10, 2009 at 1:26 PM, Nathan Williams <[email protected]> >> wrote: >>> Marc Jones wrote: >>>> On Fri, Nov 6, 2009 at 7:57 AM, Nathan Williams <[email protected]> >>>> 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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
