[U-Boot-Users] Re: PATCH: Add support for EmbeddedPlanet EP88x boards

[Yuli Barcohen]

>>>>> 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?

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================