On Fri, Nov 6, 2009 at 7:57 AM, Nathan Williams nathan@traverse.com.au wrote:
Marc Jones wrote:
When linux does the reset, is the coreboot output the same? Does it do the "Resetting the processor"?
Yes, it does "Resetting the processor after PLL configuration for the changes to take effect"
I captured an example of my issue:
http://coreboot.pastebin.com/m7f5ed367
I made some more observations today:
From Linux, a reboot from the command line works fine. It only seems to die when a fsck check fails on boot and forces a reboot. The motherboard doesn't have a RTC backup battery at the moment, so to test I have been setting the clock in Linux, shutdown, remove the power supply for a few seconds, then boot up again. Because the default time is in 1999, Linux runs a fsck which causes it to restart and die in coreboot.
Once coreboot crashes, a hardware reset doesn't fix it. Coreboot will always stop at the same point. Even removing power from the motherboard doesn't help. However, I did find that by swapping the SODIMM to a different RAM module would boot. I know it doesn't sound very scientific but it's what appeared to happen.
Is it possible that coreboot or maybe SeaBIOS is using incorrect values from non-volatile ram?
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)
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