RE: [U-Boot-Users] Software emulation exception on entry into RAM
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
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
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
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
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
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
participants (3)
-
Michael Bendzick -
Thomas Laman -
Wolfgang Denk