[U-Boot-Users] Software emulation exception on entry into RAM

[Thomas Laman <tlaman@rochester.rr.com>]

Mike,

In my board specific code, after initialization of the SDRAM, I have 
code that writes the address as data to that address - write 0x0 to 0x0, 
0x4 to 0x4, etc. After the Software Emulation Exception, I go into the 
SDRAM and the code is copied correctly in the used areas, and my pattern 
is in the other areas.

Because of this, I don't think my SDRAM settings are being changed.

-Tom Laman

Michael Bendzick wrote:

>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 at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
>  
>