[U-Boot] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

Hi,

On 16-03-16 10:29, Hans de Goede wrote:
> Hi,
>
> On 16-03-16 09:32, Michael Haas wrote:
>> On 03/15/2016 07:09 PM, Karsten Merker wrote:
>>> On Tue, Mar 15, 2016 at 06:41:39AM +0100, Michael Haas wrote:
>>>
>>>> This change is required to get GBIT Ethernet to work
>>>> reliably on my board. Without CONFIG_GMAC_TX_DELAY=4, the connection
>>>> suffers severe packet loss and SSH becomes unusable.
>>>>
>>>> --- 192.168.1.1 ping statistics ---
>>>> 100 packets transmitted, 100 received, 0% packet loss, time 19842ms
>>>> rtt min/avg/max/mdev = 0.260/0.334/0.527/0.038 ms
>>>>
>>>> I have also tried CONFIG_GMAC_TX_DELAY=3, which still
>>>> yielded 11-13% packet loss.
>>> Hello,
>>>
>>> unfortunately this change doesn't solve the gigabit issues
>>> on my LIME2 - it even seems to make them worse on my board.
>>>
>>>
>>> Could you perhaps try netbooting a kernel with your LIME2?
>>> I would be interested in knowing whether that works on your
>>> board (with CONFIG_GMAC_TX_DELAY=0/4).
>>>
>>>
>> Hello Karsten,
>>
>> I just tried netbooting the debian installer: it didn't work, just as
>> you said.
>>
>> Even worse: I noticed I had not installed my patched u-boot at all when
>> I ran the ping test above! With my patch, the kernel would not download
>> at all.
>>
>> So the patch is wrong and I'm sorry for having wasted everyone's time here.
>>
>> I won't give up yet, however. The fact still stands that at some point,
>> I was able to use GBit Ethernet
>> without any issues in Linux, possibly after a warm reboot.
>
> Interesting, if you can reproduce things working better after a warm reboot,
> try dumping the reg which gets modified by modifying ONFIG_GMAC_TX_DELAY,
> note that reg has RX_DELAY bits too, maybe we need to tweak those.
>
> Although a warm reboot typically only preserves settings outside of the soc,
> so if a warm reboot fixes things int may be that whatever you're warm rebooting
> from (I would assume some vendor image) is setting some things differently
> in the phy.

So this made me think: are we building the u-boot phy drivers. Guess what we
are not, which might explain things, can you try this change:


And see if that helps ?

Regards,

Hans


>
>
>>
>> For (my) future reference, I used these commands:
>>
>> --
>> setenv bootargs console=ttyS0,115200 rootwait panic=10
>> setenv autoload no
>> dhcp
>> setenv serverip 192.168.1.170
>> tftpboot ${scriptaddr} /debian-installer/armhf/tftpboot.scr
>> source ${scriptaddr}
>> --
>>
>> I'll be playing around with the value a bit more to find the "best"
>> value for netbooting from a cold state, then try to get it
>> to work within Linux itself. Perhaps there are also some clock adjusts
>> to be done from within the DTS.
>>
>> Sorry again!
>>
>> Michael
>>

On Wed, Mar 16, 2016 at 11:53:58AM +0100, Hans de Goede wrote:

[ Olimex OlinuXino Lime2: netboot on a gigabit ethernet link
  results in a corrupted image while on a 100MBit link things
  work properly ]

> So this made me think: are we building the u-boot phy drivers. Guess what we
> are not, which might explain things, can you try this change:
> 
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -314,6 +314,7 @@ extern int soft_i2c_gpio_scl;
>  #define CONFIG_PHY_GIGE                /* GMAC can use gigabit PHY     */
>  #define CONFIG_PHY_ADDR                1
>  #define CONFIG_MII                     /* MII PHY management           */
> +#define CONFIG_PHY_REALTEK
>  #endif
> 
>  #ifdef CONFIG_USB_EHCI_HCD
> 
> And see if that helps ?

Hello,

I have tried this patch on top of v2016.01 (as v2016.03 has
other network-related problems, cf. the thread starting at
http://lists.denx.de/pipermail/u-boot/2016-March/247565.html),
but unfortunately it doesn't bring any visible improvement.

Netbooting a kernel on a gigabit link still results in a
non-booting or crashing kernel while everything works fine on a
100MBit link.

Regards,
Karsten