Marc Jones wrote:
On Fri, Nov 6, 2009 at 7:57 AM, Nathan Williams <nat...@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
--- a/device/device.c
+++ b/device/device.c
@@ -282,7 +282,7 @@ void read_resources(struct bus *bus)
/* Walk through all devices and find which resources they need. */
for (curdev = bus->children; curdev; curdev = curdev->sibling) {
int i;
- printk(BIOS_SPEW,
+ printk(BIOS_CRIT,
"%s: %s(%s) dtsname %s enabled %d\n",
__func__, bus->dev ? bus->dev->dtsname : "NOBUSDEV",
bus->dev ? dev_path(bus->dev) : "NOBUSDEV",
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
