[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