Will Haines writes:
Yuli> The attached patch adds support for EmbeddedPlanet EP88x Yuli> boards. It was tested on EP88xC board with MPC885 processor, Yuli> 64MB RAM, and 16MB flash.
Will> Thank you for the patch. The code should help me a lot. Will> However, when I tried to test it with my board and EP885C,
What is your board? This code is intended for EP88x ONLY. Don't expect it to run unchanged on any other board.
Will> I got no output to the terminal. When I try to step through Will> it, everything goes fine until it appears to go into an Will> infinite loop in sdram_table. The point where it loops looks Will> like this in the debugger:
Will> 0xfc01b410 in sdram_table () (gdb) 0xfc01b348 in sdram_table Will> () (gdb)
Will> Do you have any idea why it would be doing this?
Will> Also, because it may solve the problem, what version of u-boot Will> did you write the patch against? I am using the stable 1.1.2 Will> build, but I guess you may have used some CVS version.
The patch is (as always) against top of CVS. Version 1.1.2 is too old to be used in any new project.
Will> I think that that specific error stemmed from my BDI Will> configuration file; however, I still cannot get the port to Will> even print anything to the terminal. My steps for putting to Will> the board are as follows:
Will> make distclean make EP8xx_config make all
Will> Then with the BDI: erase 0xfc000000 erase 0xfc020000 prog Will> u-boot.bin bin reset
Will> When I reboot the board there is no output to the console.
Will> When I try to run this using the debugger it appears that Will> things work correctly until the intialization gets trapped in Will> speed.c's function: init_pll_866. I have no idea why a Will> function with no loops in it would seem to loop forever. My Will> only idea is that something is going wrong with Will> plprcr_write_866's return jump.
Will> Any suggestions at all to get this port running on my board Will> would be much appreciated!
There are too many possible reasons. First of all, EP885C exists in several different configurations. If your SDRAM is different from mine, U-Boot can fail. I haven't got all possible configurations to test. PLL can get stuck if init_pll_866 has to change bus division factor (EBDF), so check the default CPU frequency and the requested one. There also can be a toolchain-related problem. I discussed it with Wolfgang almost a year ago but we were not sure what the fix should be so I fixed it locally in my repository. For some reason, nobody else reported such a problem so it was not urgent. The problem is as follows: GCC 3.3 (and newer) put variables explicitly initialised to zero to .bss section. Older GCCs put them to .data section. This means that with newer compilers, until U-Boot is copied to RAM, these variables contain junk and not zero. This caused terminal output problems on several MPC8xx boards I worked with, due to the following definitions in common/serial.c:
static struct serial_device *serial_devices = NULL; static struct serial_device *serial_current = NULL;
I changed these to
static struct serial_device *serial_devices __attribute__ ((section (".data"))) = NULL; static struct serial_device *serial_current __attribute__ ((section (".data"))) = NULL;
and the problem disappeared. I don't think we should/can add such __attribute__ to every zero-initialised variable so I didn't submit patch. I'd suggest using GCC flag -fno-zero-initialized-in-bss which exists exactly for fixing such problems. Any opinions?