[U-Boot-Users] problems with BDI2000 / u-boot / Linux on IBM 440GX Ocotea refere nce board

[Bill Hargen]

I have been trying to get u-boot and Linux running on the IBM 440GX
"Ocotea" reference board and I have been hitting some weird problems.
I'm hoping that someone might have been down this path or have a
suggestion on something else to try or check.  I got u-boot and Linux
working on a 405EP reference board in December, so I've got some
experience with this.

I'm using the ELDK 3.0 package for the tools and Linux kernel, and am
using u-boot version 1.1.1 from the FTP site.  I am able to build,
install, and run u-boot from flash.  And I am able to load a kernel via
TFTP and run it (sort of).  Right now, I don't have a root file system
provided, so I'm getting a panic as expected at that point.  My
questions are about a few of the quirks that I've hit along the way.

The first problem is if I try to run u-boot from flash with a BDI2000
connected (i.e. do "reset" and "go" commands), then u-boot starts
running but hangs in the SDRAM init.  Specifically, it hangs waiting
for the MRS Command Complete status bit to be set.  If I power-up
without the BDI2000 connected, it starts just fine.  With the BDI2000
connected, I can confirm that the bit isn't going true.  I've also tried
clearing and setting the DCEN enable bit, but the status bit still never
goes true.  The BDI config file that I am using is a minor modification
of the one included with the BDI2000 for the 440GX eval board.  And also,
with the BDI2000 disconnected, the system reset switch doesn't work.  It
kills the system, but it doesn't restart - I have to power cycle.  It did
work when IBM's PIBS code was in flash.

The second problem is with Linux startup.  I get a number of pages of
output on the serial port, including seeing the IDE drives connected to
an IDE controller that I have plugged into the PCI bus.  It finally stops
with a panic due to no rootfs, as expected.  But there were a number of
other problems along the way:

  - It reports that the RTC "seems stuck".

  - It reports about 37 BogoMIPS, which seems way to low for a 440GX
    running at 533MHz.

  - It gets read timeouts trying to find the Ethernet PHYs.  (And this
    works from u-boot - I'm booting from emac0!)

  - It isn't getting the boot command line from u-boot.  And this is
    where it gets very strange.  It seems that the kernel is not
    expecting the register set and data structure that is passed by
    u-boot.  No problem - I've hit that before.  So I added the
    appropriate logic to platform_init() to check the registers and do a
    strcpy(cmd_line, (char *)(r6 + KERNELBASE)).  But that seems to kill
    the system.  Even adding strcpy(cmd_line, "foo") kills it!  Yet the
    calling function copied the default command line into that buffer.
    But if I change that code to copy it twice then it dies.  I have
    absolutely no clue as to what could cause such behavior!  (I'd poke
    around with the BDI2000, but I can't get past u-boot's SDRAM init
    when it is connected.)

I don't know if the BDI2000 quirk, the reset switch quirk, and the Linux
strcpy(cmd_line... quirks are connected or not.

Improper SDRAM initialization is usually blamed for such things, but I'm
using the existing OCOTEA port which gets the parameters from the SPD chip
on the memory DIMM.  And yes, I tried two different DIMMs, one of which
was the 256MB DIMM that came with the board.

Any ideas, suggestions, sample BDI config files, or pointers to a patch
that I missed would be welcome!  It's probably something simple, just
not obvious.

Thanks.

--Bill