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

[Stefan Roese <sr@denx.de>]

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?

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

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

One simple idea is to add :

#define CONFIG_PRAM	1

to your U-Boot config file.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================