Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
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.
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
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.
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
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
participants (2)
-
Hans de Goede -
Michael Haas