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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ U-Boot-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/u-boot-users
