PPC440Epx Sequoia Flash-based size limitation?
Hi all,
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. 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'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"? ;-)
Thanks,
Dave
Quoted 7 lines · Dave Littell
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?
Quoted 5 lines
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?
Quoted 7 lines
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:
Quoted 16 lines
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
Quoted 8 lines
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
=====================================================================
Quoted 4 lines · Stefan Roese
Quoted 4 lines · Dave Littell
Quoted 3 lines
Quoted 3 lines
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
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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)
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
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.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
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
Quoted 1 line
Quoted 1 line
board. What did you change in the DDR2 setup code? How similar is
your board
Quoted 2 lines
Quoted 2 lines
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.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 22 lines
Quoted 22 lines
Quoted 1 line
Quoted 1 line
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:
Quoted 17 lines
Quoted 17 lines
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
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
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.
Quoted 6 lines
Quoted 6 lines
One simple idea is to add :
#define
CONFIG_PRAM1to your U-Boot config file.
I'll certainly give that a shot.
Thanks very much,
Dave
Stefan Roese wrote:
[deletia]
Quoted 5 lines
Another idea comes to my mind here. It's on my todo list to implement a workaround for the 440EPx errata CHIP 11:
Quoted 1 line
CHIP_11: End of memory range area restricted access.
[deletia]
Quoted 7 lines
One simple idea is to add :
#define
CONFIG_PRAM1to your U-Boot config file.
This seems to have fixed the problem, although I had to juggle the order to get the PRAM trimmed out before the LOGBUFFER memory. I later went back and trimmed only the AMCC-recommended 256 bytes and this also seems to resolved the problem.
Odd timing that CHIP_11 chose to bite, eh? Thanks very much for the help.
Dave
Hi Dave
Quoted 3 lines · Dave Littell
Hi all,
I'm working on an AMCC PPC440EPx platform that is similar to the AMCC
We have also a PPC440EPx based board (HCU5, in the u-boot tree).
Quoted 10 lines
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. 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 toinitdram(). Some boundary or limit is being crossed somewhere...
Recently, (the last few weeks) we did run in a similar problem that loading the vxWorks image hangs in the middle of the tftp transfer. Some boards have it never, newer ones more often and some have it more or less often depending on the physical locatian, e.g. they show the behaviour at my workplace but not at the workplace of my co-worker. Sometimes it has this behaviour just at the beginning and after a few minutes it loads the whole image without problem.
I am investigating the problem. It seems that sometimes I get a IVOR1 (Machine check) -exception. But unfortunatly I do not have at the moment a setup where I can easily reproduce the problem.
This may be a problem which may or may not be related to yours.
Also be warned that the PPC440EPx is a very powerful CPU where a lot of parallelisme exists. We did run into subtle, hard to find problems because the CPU did reorder read/write accesses to different addreses. Therefore if you access somewhere memory based CPLD/MACH or other registers always use the in_/out_<xx> macros.
Best regards
Niklaus