[coreboot] GeodeLX RAM initialisation issue
marcj303 at gmail.com
Mon Nov 9 21:59:29 CET 2009
On Fri, Nov 6, 2009 at 7:57 AM, Nathan Williams <nathan at 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:
> 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 184.108.40.206 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.
More information about the coreboot