[U-Boot-Users] Software emulation exception on entry into RAM
tlaman at rochester.rr.com
Fri Jul 30 11:31:42 CEST 2004
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.
Michael Bendzick wrote:
>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.
>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
>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
>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.
>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
More information about the U-Boot