[U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue

[Hector Palacios <hector.palacios@digi.com>]

On 07/15/2013 05:12 PM, Marek Vasut wrote:
> Hi Hector,
>
>> Hi Marek,
>>
>> On 07/15/2013 02:30 PM, Marek Vasut wrote:
>>> Dear Hector Palacios,
>>>
>>>> Hi Marek,
>>>>
>>>> On 07/12/2013 06:48 PM, Marek Vasut wrote:
>>>>>>    [...]
>>>>>>
>>>>>> but I found something:
>>>>>> It is very strange that the timeouts appear always after transferring
>>>>>> between 20 and 24 MiB. So I thought maybe it was not an issue with the
>>>>>> size of the file or the number of packets received, but instead a
>>>>>> timed issue (an issue that happens after some period of time). I
>>>>>> checked, and in fact the timeouts occur exactly 10 seconds after
>>>>>> running the tftp command. I verified that this is what is happening
>>>>>> by adding a udelay(100000) at fec_send(). In this case, the timeout
>>>>>> also occurs after 10 seconds, but due to the delay, I have
>>>>>> transferred only a few Kbytes.
>>>>>
>>>>> Holy moly!
>>>>>
>>>>>> I tried to change different timeout related constants at tftp.c but
>>>>>> still the issue happens after 10s.
>>>>>> It's like if, after these 10 seconds, the PHY lost the link or
>>>>>> something. Really odd. Does it tell you anything?
>>>>>
>>>>> LAN8720 phy, right? Try implementing something like [1], by clearing
>>>>> the EDPWRDOWN bit , the PHY will never enter low-power mode. It's just
>>>>> a simple PHY register RMW which you can stick somewhere into the PHY
>>>>> net/phy/smsc.c code.
>>>>>
>>>>> [1]
>>>>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/djbw/dmaengine
>>>>> /+ /b629820d18fa65cc598390e4b9712fd5f83ee693%5E!/#F0
>>>>
>>>> No, my PHY is a Micrel KSZ8031RNLI.
>>>>
>>>> The hint about the PHY possibly going to power down mode is interesting
>>>> but I checked the PHY registers and EDPD mode (Energy Detect Power
>>>> Down) is off, at least before running the tftp command. Power Down mode
>>>> is off too, so unless these are somehow enabled during the TFTP
>>>> process, this is not what's happening.
>>>
>>> OK, makes sense.
>>>
>>>> The sniffer shows that the TFTP server simply stops sending data
>>>> packets. I can see however the target sending several times the ACK
>>>> packet to the last received data packet. This would point to the TFTP
>>>> server (as Albert suggested), but the fact is the problem occurs with
>>>> different TFTP servers (I tried three different servers) and it does
>>>> not happen with an old v2009 U-Boot using the same target.
>>>
>>> Can you try running "dcache off" command before running the TFTP
>>> transfer? Does it still behave like this?
>>>
>>> You might need to define #define CONFIG_CMD_CACHE for this to work.
>>
>> Sourcery!
>> It's not that it works with dcache off, I found something even more
>> strange: The way I reproduce this issue is by setting the 'bootcmd' to
>> 'dboot ${loadaddr} file100M'. When you set the 'bootcmd' like this:
>>
>> 	setenv bootcmd tftp ${loadaddr} file100M
>>
>> this eventually expands to
>>
>> 	bootcmd=tftp 0x42000000 file100M
>>
>> So this is the command that runs automatically after the bootdelay.
>> I just discovered that if instead of letting the auto boot run, I press a
>> key to stop the auto boot and run the command by hand (either running
>> 'boot' or typing the command 'tftp 0x42000000 file100M'), the tftp
>> transfer works perfectly.
>> On the other hand, if I do the same but use the environment variable
>> ${loadaddr}, i.e. 'tftp ${loadaddr} file100M'. It will stop after 10
>> seconds.
>
> Count it be your hardware needs some more delay to stabilize?

It's not a problem of running the command later. If I run the command later, manually, 
but use ${loadaddr} instead of the hardcoded value 0x42000000, then it will fail. It's 
like if accessing the environment for grabbing the value of ${loadaddr} or for 
grabbing the value of ${bootcmd}, made the problem appear, while if I run a manual 
command that does not require accesing the environment, it works.

>> And to make things funnier I just reproduced this issue on the MX28EVK
>> using the imx U-Boot custodian tree at commit
>> a3f170cdbf7ae0bd24c94c2f46725699bbd69f05. That discards being a platform
>> issue.
>
> It still might be a PHY issue, no?

I guess it might, but the MX28EVK uses a different PHY. An SMSC, I believe.

>> @Fabio: could you manually run the command 'tftp ${loadaddr} file100M'
>
> I guess that'd be a 100MB file?

Yes. The size is not that important as far as it takes more than 10 seconds to 
download. The keypoint here is using the environment variable, rather than an hex value.

Best regards,
--
Hector Palacios