[U-Boot-Users] PPC440Epx Sequoia Flash-based size limitation?

[Dave Littell <littelld@verizon.net>]

Stefan Roese wrote:
> > On Friday 14 March 2008, Dave Littell wrote:
>> >> I'm working on an AMCC PPC440EPx platform that is similar to the AMCC
>> >> Sequoia under U-Boot 1.3.1.  I've copied the Sequoia board and
>> >> configuration as a starting point, but I've run into a problem
with the
>> >> size of the flash-based portion of U-Boot.  I've added code to
>> >> initdram() that results in the addition of 3-4 dozen assembly
>> >> instructions.  Now the board hangs after a very few tftp (or even
ping)
>> >> commands.
> >
> > Does it really hang, or do you get an exception?
> >

Hi Stefan,

Thanks very much for the reply - I very much appreciate any help you can
offer.

No exception appears.  It hangs to the point where a JTAG debugger is
unable to regain control of the processor.

>> >> However, if I remove the code I added, there's no problem
>> >> with tftp, etc.  I've narrowed it down to the point where I can
make the
>> >> difference between a working and non-working load by adding just a few
>> >> instructions to initdram().  Some boundary or limit is being crossed
>> >> somewhere...
> >
> > I don't think so. It could be a problem with the DDR2 Denali setup
for your
> > board. What did you change in the DDR2 setup code? How similar is
your board
> > design to the Sequoia regarding DDR2 chips, termination etc?
> >

From a hardware design perspective, much of the physical layout was
copied directly from the Sequoia (so I've been told), but it does use
memory from a different manufacturer.  The changes I added to initdram()
were to use the DDR Controller register values suggested by the AMCC DDR
Configuration Tool spreadsheet for two different PLB speeds.  I felt the
parameters were different enough to warrant using get_bus_speed() and a
simple if() to determine which set of parameters were loaded to the DDR
Controller.

If I instead use #ifdef's to determine at compile time which set of
parameters are loaded, the board runs and I can tftp (or ping) all day.
 However, if I replace that with my if() logic and both sets of
parameters (in the correct branch path - verified with the JTAG), the
board will hang after only a few tftp's (or pings).

Hm.

>> >> I'm sure I've overrun something somewhere but I'm afraid I'm not
>> >> literate enough in the magic of the .lds file (which is unmodified
from
>> >> the Sequoia platform) to understand what adding so few instructions to
>> >> the flash-based portion of U-boot might have broken.
>> >>
>> >> I've searched the FAQ and mailing list archives, all to no avail.
 Does
>> >> anyone have any suggestions other that "write tighter code"?   ;-)
> >
> > Another idea comes to my mind here. It's on my todo list to implement a
> > workaround for the 440EPx errata CHIP 11:
> >
>> >> CHIP_11: End of memory range area restricted access.
>> >> Category: 3
>> >> Overview:
>> >> The 440EPx DDR controller does not acknowledge any
>> >> transaction which is determined to be crossing over the
>> >> end-of-memory-range boundary, even if the starting address is
>> >> within valid memory space. Any such transaction from any PLB4
>> >> master will result in a PLB time-out on PLB4 bus.
>> >> Impact:
>> >> In case of such misaligned bursts, PLB4 masters will not
>> >> retrieve any data at all, just the available data up to the
>> >> end of memory, especially the 440 CPU. For example, if a CPU
>> >> instruction required an operand located in memory within the
>> >> last 7 words of memory, the DCU master would burst read 8
>> >> words to update the data cache and cross over the
>> >> end-of-memory-range boundary. Such a DCU read would not be
>> >> answered by the DDR controller, resulting in a PLB4 time-out
>> >> and ultimately in a Machine Check interrupt. The data would
>> >> be inaccessible to the CPU.
>> >> Workaround:
>> >> Forbid any application to access the last 256 bytes of DDR
>> >> memory. For example, make your operating system believe that
>> >> the last 256 bytes of DDR memory are absent. AMCC has a patch
>> >> that does this, available for Linux.
> >

Yes, I saw that and implemented the Linux kernel patch that AMCC
provides.  However, I didn't think that U-Boot ran up against the upper
boundary of RAM.

> > One simple idea is to add :
> >
> > #define CONFIG_PRAM	1
> >
> > to your U-Boot config file.
> >

I'll certainly give that a shot.


Thanks very much,
Dave