Please don't top post.
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style http://www.caliburn.nl/topposting.html
rk1825 wrote:
I understand that if it is data sync problem then it should wait/hang at that place, But it is getting reset. When i probed reset status it says Check stop reset has happened.
Yes, that is hard to reconcile with print statements "fixing" your problem.
What is the link register and other important registers set to when your program checkstops? That will tell you what you were doing just before you went <splat>. The registers, in conjunction with a disassembly of the module you were in before going <splat>, will give you clues to what your pointers were pointing to. Often those are very useful clues.
My best guess at this point is that you either have a memory initialization (or layout) problem that is being masked by the print statements (seems unlikely) or you are stomping on memory inadvertently. For the later hypothesis, by adding print statements, you have shifted the memory location that you stomp on to a "safe" location instead of a location that crashes you. This would imply stack or pointer problems.
Good luck, gvb
We are using custom board based on MPC8313 processor, phy used in our board is LAN8700 and U-boot version used is 1.3.0.
1.3.0 is getting pretty old. :-/ Any chance of using the latest release?
-Thanks Rupesh
Jerry Van Baren-7 wrote:
Please don't top quote.
rudresh wrote:
HI gvb
I was trying to print the status of phy registers by putting some debug statements in adjust_link function of tsec.c (drivers/tsec.c).
I found that after putting these debugs, i could not recreate the problem and ethernet works fine.
does this mean there is DDR2 initialization problem in my code..?
No, "fixing" the problem by putting in debug statements sounds more like data cache (less likely) or bus interface unit (missing sync) issues where your processor is holding on to the data rather than writing it out when you think you wrote it out or reordering reads and writes (missing sync/eieio issue). This would get into the "data accessor" (read/write with sync calls) functions and proper use thereof.
Having said that, I am puzzled how sync/timing issues would result in your board spontaneously resetting - that is usually a memory corruption problem. Adding print statements generally doesn't "solve" memory corruption problems (sometimes it seems to due to changes in stack usage if you have something set up wrong, but I cannot even speculate on how/why/what could be set up wrong from the far end of a mail list).
You didn't say what version of u-boot you are basing your code off of nor what processor you are using. I don't have expertise w/ the tsec or your PHY, perhaps if you are more specific someone with real experience with the tsec, etc. can give more advice.
gvb
Jerry Van Baren-7 wrote:
rudresh wrote:
Hi,
In Ethernet PHY LAN8700 driver having some issues, during tftp the large file of more than 2MB of the binary file , some time its hangup & sometime its reset the board. same driver is working in evaluation board with same PHY & interface . if i tried in customize board the problem is occurring every 2- 3 of iteration. how to fix this issue..
Thanks Rudresh
Hi Rudresh,
If your ethernet driver uses DMA, it is probably due to a SDRAM (DDR/DDR2/DDR3) configuration issue (fixable) or a board layout issue (expensive to fix).
http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation http://www.denx.de/wiki/DULG/SDRAM
gvb
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot