From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Wed, 16 Mar 2016 10:29:51 +0100 Subject: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2 In-Reply-To: <56E91A12.8080506@computerlinguist.org> References: <1458020499-9506-1-git-send-email-haas@computerlinguist.org> <20160315180914.GA1878@excalibur.cnev.de> <56E91A12.8080506@computerlinguist.org> Message-ID: <56E9278F.7060801@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 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 >