Tom-
I can't be sure on this at all, but I ran into an SDRAM problem recently on a different board than yours and figured out the following solution.
In the meantime, take a look at the flow of the platform.S (or equivalent) file in your board directory. I've been working with a board that is similar to the Innovator, but the memory map was a little different, and found that I could fix an SDRAM configuration problem in that file.
In the platform.S code, which is assembly that gets run right away when the board powers up, there is initialization for external memory configuration registers. This particular file, and probably the code for many more boards, detects if the code is currently running from SDRAM or elsewhere. If running from SDRAM, it skips reconfiguring the SDRAM registers, as that would likely mess things up in a bad way.
The decision structure was originally based on comparing the program counter to the SDRAM base address. If PC was greater than SDRAM base, then skip SDRAM reconfigure. This worked well when flash memory started at 0x0, and SDRAM at 0x10000000, but I was running the code out of 0x20000000 (internal SRAM). The assembly code thought it was in SDRAM and skipped configuring the registers, even though it would have been okay to reconfigure them.
The solution to the problem was to take the PC, mask off the don't care bits, and then check the equality of the result to the SDRAM base address. This precisely determines if SDRAM is the current execution address, no matter if code ran higher or lower in the memory map than SDRAM.
In summary, check to make sure that when you set a register configuration value, that it actually makes it to that register. Hopefully this information has been helpful and not just completely unrelated.
-Michael Bendzick
-----Original Message----- From: Thomas Laman To: U-Boot-Users (E-mail) Sent: 7/29/2004 8:06 PM Subject: [U-Boot-Users] Software emulation exception on entry into RAM
I am implementing u-boot 1.0.2 on a custom 860P board and am getting a Software Emulation Exception (as reported by BDI2000) at the first access of RAM after code is copied
to RAM.
The SDRAM setup was copied from a working PSOS+ load running on this board. Successful burst reads have been verified with a logic analyzer. I can't easily get access to the logic analyzer for debugging u-boot.
I have defined SRAM to be at 0x0 and I get the same results.
I know I am not using the CVS version of u-boot, I am using what was supplied w/ ELDK 3.0.
I have searched the list and have found cases where SDRAM initialization/burst read configurations have been blamed. Based on success w/ PSOS+, I don't think this is my problem.
Any ideas?
-Tom Laman
------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users