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

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

[Thomas Laman]

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

[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

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

[Thomas Laman]

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
>
>  
>

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

[Wolfgang Denk]

In message <41099EFD.7060702@rochester.rr.com> you wrote:
> 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 

...whbich is most probably caused by incorrect initialization of the SDRAM.

> 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.

Did you verify with the LA which data  was  actually  read  from  RAM
after relocation?

> I have defined SRAM to be at 0x0 and I get the same results.

I don't understand what you mean here. 

> 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.

I still think it is. I have seen  PSOS  systems  running  happily  on
systems  where  a  real  OS  would  reliably  crash because of memory
problems.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
You Don't Have To Be 'Damned' To Work Here, But It Helps!!!
                                             - Terry Pratchett, _Eric_

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

[Wolfgang Denk]

In message <31ADFA827355984B9E2A161514595B561C3321@lpdsrv04.logicpd.com> you 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

You are talking about  a  completely  different  architecture,  which
cannot be compared to a MPC8xx.

> 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.

Sorry, but it does not apply at all for MPC8xx.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Everyting looks interesting until you do it. Then you find it's  just
another job.                     - Terry Pratchett, _Moving Pictures_

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

[Wolfgang Denk]

In message <410A157E.5060307@rochester.rr.com> you wrote:
> 
> 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.

And which data are you RADING from SDRAM? 

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

You wrote you are using a BDI2000 - you can use  it  to  single  step
into  the  code  in  SDRAM.  What  does  this give? And if you get an
exception - where does it happen? What was the incorrect data?

You got the tools - use it to analyze your problem [or just save  the
time   and  re-check  your  SDRAM  initialization  against  the  chip
manufacturer's manual; at least this is what I would do if I  was  in
your position.]

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"Why waste negative entropy on comments, when you could use the  same
entropy to create bugs instead?"                        - Steve Elias

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

[Thomas Laman]

Wolfgang Denk wrote:

>In message <410A157E.5060307@rochester.rr.com> you wrote:
>  
>
>>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.
>>    
>>
>
>And which data are you RADING from SDRAM? 
>  
>
The data that was copied prior to the branch to SDRAM.

>  
>
>>Because of this, I don't think my SDRAM settings are being changed.
>>    
>>
>
>You wrote you are using a BDI2000 - you can use  it  to  single  step
>into  the  code  in  SDRAM.  What  does  this give? And if you get an
>exception - where does it happen? What was the incorrect data?
>
>  
>
I get an exception on the first access of SDRAM (the address branched to 
from flash). The data is correct. I will have access to a logic analyzer 
this weekend and will check out the SDRAM burst read access.

>You got the tools - use it to analyze your problem [or just save  the
>time   and  re-check  your  SDRAM  initialization  against  the  chip
>manufacturer's manual; at least this is what I would do if I  was  in
>your position.]
>
>  
>
I have checked the SDRAM initialization and it appears to be correct. 
With the logic analyzer, I will check out the burst read cycle.

>Best regards,
>
>Wolfgang Denk
>
>  
>

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

[Wolfgang Denk]

In message <410B8AD2.9050306@rochester.rr.com> you wrote:
> 
> >And which data are you RADING from SDRAM? 
> >
> The data that was copied prior to the branch to SDRAM.

Then you should be able to single-step the code in the debugger.

> >You wrote you are using a BDI2000 - you can use  it  to  single  step
> >into  the  code  in  SDRAM.  What  does  this give? And if you get an
> >exception - where does it happen? What was the incorrect data?
> >
> I get an exception on the first access of SDRAM (the address branched to 

Even when single stepping? What sort of exception, btw?

> I have checked the SDRAM initialization and it appears to be correct. 
> With the logic analyzer, I will check out the burst read cycle.

Good luck!

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
It is your destiny.                                     - Darth Vader