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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox