From: Hans de Goede <hdegoede@redhat.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
Date: Wed, 16 Mar 2016 11:53:58 +0100 [thread overview]
Message-ID: <56E93B46.2070400@redhat.com> (raw)
In-Reply-To: <56E9278F.7060801@redhat.com>
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
>>
next prev parent reply other threads:[~2016-03-16 10:53 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-15 5:41 [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2 Michael Haas
[not found] ` <20160315180914.GA1878@excalibur.cnev.de>
2016-03-15 20:41 ` Tom Rini
2016-03-16 8:32 ` Michael Haas
2016-03-16 9:29 ` Hans de Goede
2016-03-16 10:53 ` Hans de Goede [this message]
[not found] ` <20160316203642.GC1817@excalibur.cnev.de>
2016-03-17 5:28 ` Michael Haas
2016-03-17 10:52 ` Hans de Goede
2016-03-17 21:53 ` Michael Haas
2016-03-18 7:41 ` Hans de Goede
[not found] ` <20160318190220.GC1815@excalibur.cnev.de>
2016-03-18 19:06 ` Michael Haas
2016-03-20 8:36 ` Michael Haas
2016-03-20 10:05 ` François-David Collin
2016-03-18 20:32 ` Michael Haas
2016-03-18 21:53 ` Michael Haas
2016-03-19 8:39 ` François-David Collin
2016-03-19 9:32 ` Hans de Goede
2016-03-19 9:35 ` Michael Haas
2016-03-19 9:45 ` Michael Haas
2016-03-19 13:40 ` Michael Haas
2016-03-19 14:35 ` François-David Collin
2016-03-20 13:45 ` Hans de Goede
2016-03-20 15:28 ` Michael Haas
2016-03-20 18:51 ` Hans de Goede
[not found] ` <20160321154714.GA4751@excalibur.cnev.de>
2016-03-21 18:57 ` Michael Haas
2016-03-21 20:59 ` Hans de Goede
2016-03-21 21:01 ` Hans de Goede
2016-03-21 21:47 ` Michael Haas
2016-03-21 22:00 ` Hans de Goede
2016-03-22 5:12 ` Michael Haas
2016-03-22 8:46 ` Peter Korsgaard
2016-03-22 8:57 ` Hans de Goede
2016-03-22 9:01 ` Michael Haas
2016-03-22 9:50 ` Peter Korsgaard
[not found] ` <20160321173000.GD4751@excalibur.cnev.de>
2016-03-21 20:56 ` Hans de Goede
-- strict thread matches above, loose matches on Subject: below --
2016-03-18 17:33 François-David Collin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56E93B46.2070400@redhat.com \
--to=hdegoede@redhat.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.