[U-Boot] Ethernet PHY LAN8700

[U-Boot] Ethernet PHY LAN8700

[rudresh]

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
-- 
View this message in context: http://www.nabble.com/Ethernet-PHY-LAN8700-tp22239868p22239868.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

[U-Boot] Ethernet PHY LAN8700

[Jerry Van Baren]

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] Ethernet PHY LAN8700

[rudresh]

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


 



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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 
> 

-- 
View this message in context: http://www.nabble.com/Ethernet-PHY-LAN8700-tp22239868p22246162.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

[U-Boot] Ethernet PHY LAN8700

[Jerry Van Baren]

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] Ethernet PHY LAN8700

[rk1825]

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.

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.

-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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 
> 

-- 
View this message in context: http://www.nabble.com/Ethernet-PHY-LAN8700-tp22239868p22247116.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

[U-Boot] Ethernet PHY LAN8700

[Jerry Van Baren]

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 at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>>
>