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

Hans de Goede hdegoede at redhat.com
Wed Mar 16 11:53:58 CET 2016


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:

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

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


More information about the U-Boot mailing list