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