From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Wed, 16 Mar 2016 11:53:58 +0100 Subject: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2 In-Reply-To: <56E9278F.7060801@redhat.com> References: <1458020499-9506-1-git-send-email-haas@computerlinguist.org> <20160315180914.GA1878@excalibur.cnev.de> <56E91A12.8080506@computerlinguist.org> <56E9278F.7060801@redhat.com> Message-ID: <56E93B46.2070400@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>