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

[Michael Bendzick]

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