[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Michael Haas]

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.

It's quite possible that A20-OLinuXino-Lime_defconfig also requires
this change, but I do not have a board for testing.

I have tested this change on u-boot 2016.01.

Signed-off-by: Michael Haas <haas@computerlinguist.org>
Tested-by: Michael Haas <haas@computerlinguist.org>
Cc: ijc at hellion.org.uk
Cc: hdegoede at redhat.com
---

 configs/A20-OLinuXino-Lime2_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/A20-OLinuXino-Lime2_defconfig b/configs/A20-OLinuXino-Lime2_defconfig
index b5181c6..f75b191 100644
--- a/configs/A20-OLinuXino-Lime2_defconfig
+++ b/configs/A20-OLinuXino-Lime2_defconfig
@@ -15,3 +15,4 @@ CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3)"
 CONFIG_CMD_GPIO=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_GMAC_TX_DELAY=4
-- 
2.7.2

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Tom Rini]

On Tue, Mar 15, 2016 at 07:09:14PM +0100, 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.

Sometimes I wonder if we don't need to make a way to make this tweakable
at run time instead.  On my board I forget what the setting is that
makes it mostly usable, but it's not the default one for sure.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160315/8d632532/attachment.sig>

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Michael Haas]

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

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Hans de Goede]

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
>

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Hans de Goede]

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
>>

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Michael Haas]

Hello all,


On 03/16/2016 09:36 PM, Karsten Merker wrote:
> Michael, if you would like to try testing higher RX delay chain values
> on the Lime2, I have attached a small patch that adds an appropriate
> Kconfig option. Regards, Karsten 

I will be testing your patch along with Hans' patch. In fact, I have
already compiled it - I'm just waiting for a new SD card reader to
arrive tomorrow. Sorry for the delay.

In the mean time, as I was trying to get the device to boot at all (not
related to u-boot, just my broken sdcard setup), I did try my old SD
card again to load the debian netinstaller. This should be the version
with the TX_DELAY set to 4.

Now I'm sitting in an ash shell and I can wget files from my desktop at
around 100MB/s.


~ # wget http://192.168.1.170:8000/debian-8.3.0-i386-netinst.iso -O - |
md5sum
Connecting to 192.168.1.170:8000 (192.168.1.170:8000)
-                    100% |*******************************|   315M 
0:00:00 ETA
37f329724a1c072cbe0ebda211fdeb88  -
~ # wget http://192.168.1.170:8000/debian-8.3.0-i386-netinst.iso -O - |
md5sum
Connecting to 192.168.1.170:8000 (192.168.1.170:8000)
-                    100% |*******************************|   315M 
0:00:00 ETA
37f329724a1c072cbe0ebda211fdeb88  -

~ # date +%s; wget
http://192.168.1.170:8000/debian-8.3.0-i386-netinst.iso -O /d
ev/null; date +%s
1258
Connecting to 192.168.1.170:8000 (192.168.1.170:8000)
null                 100% |*******************************|   315M 
0:00:00 ETA
1261

~ # dmesg | grep -i link
[    1.504918] audit: initializing netlink subsys (disabled)
[   88.561822] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   90.547368] sun7i-dwmac 1c50000.ethernet eth0: Link is Up -
1Gbps/Full - flow control rx/tx
[   90.547424] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

~ # cat /etc/lsb-release
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20160316-00:13"
X_INSTALLATION_MEDIUM=netboot
~ # uname -a
Linux debian 4.4.0-1-armmp #1 SMP Debian 4.4.4-2 (2016-03-09) armv7l
GNU/Linux



It takes around three seconds (date +%s; time not set) to transfer the
315MB. The md5sum matches.

Now, with the device sitting on my desk in a debian installer session
and working gbit.. how do I proceed from here? I don't dare rebooting..

Best

Michael

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Hans de Goede]

Hi,

On 17-03-16 06:28, Michael Haas wrote:
> Hello all,
>
>
> On 03/16/2016 09:36 PM, Karsten Merker wrote:
>> Michael, if you would like to try testing higher RX delay chain values
>> on the Lime2, I have attached a small patch that adds an appropriate
>> Kconfig option. Regards, Karsten
>
> I will be testing your patch along with Hans' patch. In fact, I have
> already compiled it - I'm just waiting for a new SD card reader to
> arrive tomorrow. Sorry for the delay.
>
> In the mean time, as I was trying to get the device to boot at all (not
> related to u-boot, just my broken sdcard setup), I did try my old SD
> card again to load the debian netinstaller. This should be the version
> with the TX_DELAY set to 4.
>
> Now I'm sitting in an ash shell and I can wget files from my desktop at
> around 100MB/s.
>
>
> ~ # wget http://192.168.1.170:8000/debian-8.3.0-i386-netinst.iso -O - |
> md5sum
> Connecting to 192.168.1.170:8000 (192.168.1.170:8000)
> -                    100% |*******************************|   315M
> 0:00:00 ETA
> 37f329724a1c072cbe0ebda211fdeb88  -
> ~ # wget http://192.168.1.170:8000/debian-8.3.0-i386-netinst.iso -O - |
> md5sum
> Connecting to 192.168.1.170:8000 (192.168.1.170:8000)
> -                    100% |*******************************|   315M
> 0:00:00 ETA
> 37f329724a1c072cbe0ebda211fdeb88  -
>
> ~ # date +%s; wget
> http://192.168.1.170:8000/debian-8.3.0-i386-netinst.iso -O /d
> ev/null; date +%s
> 1258
> Connecting to 192.168.1.170:8000 (192.168.1.170:8000)
> null                 100% |*******************************|   315M
> 0:00:00 ETA
> 1261
>
> ~ # dmesg | grep -i link
> [    1.504918] audit: initializing netlink subsys (disabled)
> [   88.561822] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [   90.547368] sun7i-dwmac 1c50000.ethernet eth0: Link is Up -
> 1Gbps/Full - flow control rx/tx
> [   90.547424] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>
> ~ # cat /etc/lsb-release
> DISTRIB_ID=Debian
> DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
> DISTRIB_RELEASE="9 (stretch) - installer build 20160316-00:13"
> X_INSTALLATION_MEDIUM=netboot
> ~ # uname -a
> Linux debian 4.4.0-1-armmp #1 SMP Debian 4.4.4-2 (2016-03-09) armv7l
> GNU/Linux
>
>
>
> It takes around three seconds (date +%s; time not set) to transfer the
> 315MB. The md5sum matches.
>
> Now, with the device sitting on my desk in a debian installer session
> and working gbit.. how do I proceed from here? I don't dare rebooting..

There are 3 things which would be interesting to save and compare
with a boot which does have the problem:

1) The gmc clk register, to do this download mmio_dump from:

https://fedorapeople.org/~jwrdegoede/mmio-dump

And as root run:

./mmio-dump 0x1c20164

And record the output

This is a statically linked binary (I use it on android) so it
should work fine. If you don't like running $random binaries
of the internet, you can find the c-code here:

https://fedorapeople.org/~jwrdegoede/mmio-dump.c

Compile this (on the arm-system) with:

gcc -o mmio-dump mmio-dump.c

2) The pmic settings for various ldo-s, etc. as root run:

i2cdump -f -y 0 0x34

And record the output. You may need to
install i2c-tools (or the deb. alternative) and
do "modprobe i2c_dev"

3) The phy settings, unfortunately I do not know of
a way to dump these, so lets just forget about these
and focus on the other 2.

Regards,

Hans





>
> Best
>
> Michael
>
>
>
>
>

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Michael Haas]

On 03/17/2016 11:52 AM, Hans de Goede wrote:
> Hi,
>
> There are 3 things which would be interesting to save and compare
> with a boot which does have the problem:
>
> 1) The gmc clk register, to do this download mmio_dump from:
>
>

Working GBit:
01c20164: 00000c06

Broken GBit:
tomorrow :)

>
> 2) The pmic settings for various ldo-s, etc. as root run:
>
> i2cdump -f -y 0 0x34
> And record the output. You may need to
> install i2c-tools (or the deb. alternative) and
> do "modprobe i2c_dev"
>

I had to download the Debian kernel package on another box, extract the
.ko, transfer and insmod it. Now I'm getting:

~ # /mnt/usr/sbin/i2cdump -f -y 0 0x34
No size specified (using byte-data access)
Error: Could not open file `/dev/i2c-0': No such device


I did mknod the devices, but I'm getting the same error msg:


~ # ls -al /dev/i2c-*
crw-r--r--    1 root     root       89,   0 Mar 17 21:31 /dev/i2c-0
crw-r--r--    1 root     root       89,   1 Mar 17 21:31 /dev/i2c-1
~ #

Module                  Size  Used by
i2c_dev                 7087  0
i2c_sun6i_p2wi          3664  0
dm_mod                 98419  0
md_mod                121938  0
jfs                   175313  0
crc32c_generic          1862  1
btrfs                1068047  0
xor                     4846  1 btrfs
zlib_deflate           20354  1 btrfs
raid6_pq               87885  1 btrfs
vfat                   10249  0
fat                    55086  1 vfat
ext4                  552524  2
crc16                   1274  1 ext4
mbcache                 9623  1 ext4
jbd2                   96157  1 ext4
usb_storage            45523  0
ahci_sunxi              2851  0
libahci_platform        6430  1 ahci_sunxi
libahci                23066  2 libahci_platform,ahci_sunxi
libata                182871  3 libahci,libahci_platform,ahci_sunxi
scsi_mod              188073  2 usb_storage,libata
realtek                 2711  0
dwmac_sunxi             2431  0
stmmac_platform         3302  1 dwmac_sunxi
stmmac                 74687  3 stmmac_platform,dwmac_sunxi
ohci_platform           4658  0
ohci_hcd               38045  1 ohci_platform
ehci_platform           5398  0
ehci_hcd               63999  1 ehci_platform
usbcore               190581  5
usb_storage,ohci_platform,ohci_hcd,ehci_hcd,ehci_platform
usb_common              3195  1 usbcore
phy_sun4i_usb           7858  8
extcon                 10436  1 phy_sun4i_usb
sunxi_mmc              11288  0
leds_gpio               3606  0


I also loaded i2c_sun6i_p2wi  for good measure. Any idea what's missing
here?


> 3) The phy settings, unfortunately I do not know of
> a way to dump these, so lets just forget about these
> and focus on the other 2.
>
I might even look at the data sheet tomorrow if time permits.

Michael


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160317/bd72715d/attachment.sig>

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Hans de Goede]

Hi,

On 17-03-16 22:53, Michael Haas wrote:
> On 03/17/2016 11:52 AM, Hans de Goede wrote:
>> Hi,
>>
>> There are 3 things which would be interesting to save and compare
>> with a boot which does have the problem:
>>
>> 1) The gmc clk register, to do this download mmio_dump from:
>>
>>
>
> Working GBit:
> 01c20164: 00000c06
>
> Broken GBit:
> tomorrow :)
>
>>
>> 2) The pmic settings for various ldo-s, etc. as root run:
>>
>> i2cdump -f -y 0 0x34
>> And record the output. You may need to
>> install i2c-tools (or the deb. alternative) and
>> do "modprobe i2c_dev"
>>
>
> I had to download the Debian kernel package on another box, extract the
> .ko, transfer and insmod it. Now I'm getting:
>
> ~ # /mnt/usr/sbin/i2cdump -f -y 0 0x34
> No size specified (using byte-data access)
> Error: Could not open file `/dev/i2c-0': No such device
>
>
> I did mknod the devices, but I'm getting the same error msg:
>
>
> ~ # ls -al /dev/i2c-*
> crw-r--r--    1 root     root       89,   0 Mar 17 21:31 /dev/i2c-0
> crw-r--r--    1 root     root       89,   1 Mar 17 21:31 /dev/i2c-1
> ~ #
>
> Module                  Size  Used by
> i2c_dev                 7087  0
> i2c_sun6i_p2wi          3664  0
> dm_mod                 98419  0
> md_mod                121938  0
> jfs                   175313  0
> crc32c_generic          1862  1
> btrfs                1068047  0
> xor                     4846  1 btrfs
> zlib_deflate           20354  1 btrfs
> raid6_pq               87885  1 btrfs
> vfat                   10249  0
> fat                    55086  1 vfat
> ext4                  552524  2
> crc16                   1274  1 ext4
> mbcache                 9623  1 ext4
> jbd2                   96157  1 ext4
> usb_storage            45523  0
> ahci_sunxi              2851  0
> libahci_platform        6430  1 ahci_sunxi
> libahci                23066  2 libahci_platform,ahci_sunxi
> libata                182871  3 libahci,libahci_platform,ahci_sunxi
> scsi_mod              188073  2 usb_storage,libata
> realtek                 2711  0
> dwmac_sunxi             2431  0
> stmmac_platform         3302  1 dwmac_sunxi
> stmmac                 74687  3 stmmac_platform,dwmac_sunxi
> ohci_platform           4658  0
> ohci_hcd               38045  1 ohci_platform
> ehci_platform           5398  0
> ehci_hcd               63999  1 ehci_platform
> usbcore               190581  5
> usb_storage,ohci_platform,ohci_hcd,ehci_hcd,ehci_platform
> usb_common              3195  1 usbcore
> phy_sun4i_usb           7858  8
> extcon                 10436  1 phy_sun4i_usb
> sunxi_mmc              11288  0
> leds_gpio               3606  0
>
>
> I also loaded i2c_sun6i_p2wi  for good measure. Any idea what's missing
> here?

Maybe i2c-mv64xxx is a module with the Debian kernel ? That would be
bad because that would mean that we cannot communicate to the pmic
until the i2c-mv64xxx module is loaded. OTOH not having a pmic
driver talking to the pmic may explain why things work on this
particular sdcard :)

To check if that module is loaded and initialized do:

ls /sys/bus/i2c/devices

You should see at least a i2c-0 there. After the modprobe
of that driver, check dmesg for any axp messages if you're
getting some then the loading of the driver causes the pmic
driver to talk to the device (iow the pmic driver is present
already) if this happens, I would double check the gbit, because
the loading of the pmic driver may change things.

Regards,

Hans



>
>> 3) The phy settings, unfortunately I do not know of
>> a way to dump these, so lets just forget about these
>> and focus on the other 2.
>>
> I might even look at the data sheet tomorrow if time permits.
>
> Michael
>
>

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Michael Haas]

On 03/18/2016 08:02 PM, Karsten Merker wrote:
> The installer supports a number of systems that can only load images
> of limited size, therefore the installer includes only an
> installation-related subset of all the kernel modules and i2c-mv64xxx
> currently isn't among those. This hasn't been a practical problem up
> to now, but being able to talk to the pmic is indeed something that
> should be possible even in the installer. I'll try to address that in
> the next days. Regards, Karsten 

Just an anecdote: I loaded i2c-mv64xx.ko which I had extracted from the
deb and the olinuxino locked up.

So now I'm trying to reproduce broken GBit, which is harder than
expected. I managed to do it once right after the lockup in u-boot: tftp
was slow and ran into timeouts. Then I typed 'reset' in the u-boot
shell. u-boot started again and GBit was working again.

Weird.

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Michael Haas]

On 03/18/2016 08:06 PM, Michael Haas wrote:
> On 03/18/2016 08:02 PM, Karsten Merker wrote:
>> The installer supports a number of systems that can only load images
>> of limited size, therefore the installer includes only an
>> installation-related subset of all the kernel modules and i2c-mv64xxx
>> currently isn't among those. This hasn't been a practical problem up
>> to now, but being able to talk to the pmic is indeed something that
>> should be possible even in the installer. I'll try to address that in
>> the next days. Regards, Karsten 
> Just an anecdote: I loaded i2c-mv64xx.ko which I had extracted from the
> deb and the olinuxino locked up.

Just for the record: loading i2c-mv64xx.ko reproducibly hangs my Debian
Jessie install with the 4.3.0-0.bpo.1-armmp-lpae kernel.
This happens only on u-boot 2016.01; both Debian stable 2014.10 and my
own build of 2016.03 + patches work fine!


So no problem since it's fixed on newer builds.
Just a note for those playing along at home and wondering why their
olinuxino does not come up anymore with 2016.01.
>
> So now I'm trying to reproduce broken GBit, which is harder than
> expected. I managed to do it once right after the lockup in u-boot: tftp
> was slow and ran into timeouts. Then I typed 'reset' in the u-boot
> shell. u-boot started again and GBit was working again.
>
> Weird.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[François-David Collin]

Hi,

I am not 100% sure, but I remember trying first to disable the PMIC in uboot to cure this problem, see my post on archlinux arm forum there : https://archlinuxarm.org/forum/viewtopic.php?f=33&t=9911#p50946
But eventually I think this is this patch http://lists.denx.de/pipermail/u-boot/2016-March/248923.html
which got it right (no need of disabling pmic). My guess is the board failed to activate the Ethernet PHY via pmic due to incompatible config (the failure was just after the pmic i2c registering by the kernel).

Regards,
-- 
Fran?ois-David Collin

De?: Michael Haas
Envoy? le?:dimanche 20 mars 2016 09:52
??: u-boot at lists.denx.de
Objet?:Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

On 03/18/2016 08:06 PM, Michael Haas wrote:
> On 03/18/2016 08:02 PM, Karsten Merker wrote:
>> The installer supports a number of systems that can only load images
>> of limited size, therefore the installer includes only an
>> installation-related subset of all the kernel modules and i2c-mv64xxx
>> currently isn't among those. This hasn't been a practical problem up
>> to now, but being able to talk to the pmic is indeed something that
>> should be possible even in the installer. I'll try to address that in
>> the next days. Regards, Karsten 
> Just an anecdote: I loaded i2c-mv64xx.ko which I had extracted from the
> deb and the olinuxino locked up.

Just for the record: loading i2c-mv64xx.ko reproducibly hangs my Debian
Jessie install with the 4.3.0-0.bpo.1-armmp-lpae kernel.
This happens only on u-boot 2016.01; both Debian stable 2014.10 and my
own build of 2016.03 + patches work fine!


So no problem since it's fixed on newer builds.
Just a note for those playing along at home and wondering why their
olinuxino does not come up anymore with 2016.01.
>
> So now I'm trying to reproduce broken GBit, which is harder than
> expected. I managed to do it once right after the lockup in u-boot: tftp
> was slow and ran into timeouts. Then I typed 'reset' in the u-boot
> shell. u-boot started again and GBit was working again.
>
> Weird.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Michael Haas]

Hello all,


After the board locked up, I am now working exclusively from within
u-boot. Occasionally, gbit will work well. At other times, it will
appear to work well but the kernel won't boot. And sometimes,
downloading a  kernel will just time-out.

A reset is often enough to get a behavior change. In my earlier post, I
noted that it's hard for me now to get broken gbit: I've since then also
had spurs where five resets in a row did not work.

On 03/17/2016 11:52 AM, Hans de Goede wrote:
> There are 3 things which would be interesting to save and compare
> with a boot which does have the problem:
>

> ./mmio-dump 0x1c20164
>
>

I have used the u-boot 'md' command here. Between a completely broken
(timeouts) and working (at least a finished download), there is no change:

Working:

=> md 0x1c20164
01c20164: 00000c06 00000000 00000000 00000000    ................


Broken:

 md 0x1c20164
01c20164: 00000c06 00000000 00000000 00000000    ................


>
> 2) The pmic settings for various ldo-s, etc. as root run:
>
> i2cdump -f -y 0 0x34
>
>

I used the i2c md command here to get several dumps:

Working 1:
=> i2c md 0x34 0 0xff
0000: c1 10 00 41 00 00 00 00 00 00 00 00 00 00 00 00    ...A............
0010: 01 00 17 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
0020: 00 00 00 1c 00 00 00 16 cf 54 00 00 00 00 00 00    .........T......
0030: 60 03 42 c9 45 22 9d 08 a5 1f 68 5f fc 16 00 00    `.B.E"....h_....
0040: 00 00 00 00 00 00 00 00 40 40 00 00 00 00 00 00    ........@@......
0050: 09 0a 00 00 00 00 00 00 00 00 00 00 00 00 6d 0f    ..............m.
0060: db 07 3e 08 00 00 00 00 00 00 00 00 00 00 00 00    ..>.............
0070: 00 00 00 00 00 00 00 00 1a 03 00 00 00 00 db 08    ................
0080: e0 fd 83 80 32 00 ff 00 00 00 00 00 00 00 00 21    ....2..........!
0090: 07 a5 07 07 00 02 00 00 00 00 00 00 00 00 00 00    ................
00a0: 00 00 00 00 00 00 00 00 08 00 00 00 00 00 db 06    ................
00b0: 00 00 00 00 00 00 00 00 00 7f 00 ba 00 00 00 00    ................
00c0: 01 01 02 04 07 0d 10 1a 24 2e 35 3d 49 54 5c 63    ........$.5=IT\c
00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
00f0: 41 00 80 03 00 00 00 00 00 00 00 00 00 00 00    A..............


Working 2:

=> i2c md 0x34 0 0xff
0000: c1 10 00 41 00 00 00 00 00 00 00 00 00 00 00 00    ...A............
0010: 01 00 17 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
0020: 00 00 00 1c 00 00 00 16 cf 54 00 00 00 00 00 00    .........T......
0030: 60 03 42 c9 45 22 9d 08 a5 1f 68 5f fc 16 00 00    `.B.E"....h_....
0040: 00 00 00 00 00 00 00 00 40 40 00 00 00 00 00 00    ........@@......
0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6d 0f    ..............m.
0060: db 0c 3e 08 00 00 00 00 00 00 00 00 00 00 00 00    ..>.............
0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 db 08    ................
0080: e0 fd 83 80 32 00 ff 00 00 00 00 00 00 00 00 21    ....2..........!
0090: 07 a5 07 07 00 02 00 00 00 00 00 00 00 00 00 00    ................
00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dc 00    ................
00b0: 00 00 00 00 00 00 00 00 00 7f 00 ba 00 00 00 00    ................
00c0: 01 01 02 04 07 0d 10 1a 24 2e 35 3d 49 54 5c 63    ........$.5=IT\c
00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
00f0: 41 00 80 03 00 00 00 00 00 00 00 00 00 00 00    A..............


Broken 1:

=> i2c md 0x34 0 0xff
0000: c1 10 00 41 00 00 00 00 00 00 00 00 00 00 00 00    ...A............
0010: 01 00 17 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
0020: 00 00 00 1c 00 00 00 16 cf 54 00 00 00 00 00 00    .........T......
0030: 60 03 42 c9 45 22 9d 08 a5 1f 68 5f fc 16 00 00    `.B.E"....h_....
0040: 00 00 00 00 00 00 00 00 40 40 00 00 00 00 00 00    ........@@......
0050: 22 06 00 00 00 00 00 00 00 00 00 00 00 00 6e 04    ".............n.
0060: db 0a 3e 08 00 00 00 00 00 00 00 00 00 00 00 00    ..>.............
0070: 00 00 00 00 00 00 00 00 03 08 00 00 00 00 db 08    ................
0080: e0 fd 83 80 32 00 ff 00 00 00 00 00 00 00 00 21    ....2..........!
0090: 07 a5 07 07 00 02 00 00 00 00 00 00 00 00 00 00    ................
00a0: 00 00 00 00 00 00 00 00 20 08 00 00 00 00 db 09    ........ .......
00b0: 00 00 00 00 00 00 00 00 00 7f 00 ba 00 00 00 00    ................
00c0: 01 01 02 04 07 0d 10 1a 24 2e 35 3d 49 54 5c 63    ........$.5=IT\c
00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
00f0: 41 00 80 03 00 00 00 00 00 00 00 00 00 00 00    A..............

Broken 2:

=> i2c md 0x34 0 0xff
0000: c1 10 00 41 00 00 00 00 00 00 00 00 00 00 00 00    ...A............
0010: 01 00 17 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
0020: 00 00 00 1c 00 00 00 16 cf 54 00 00 00 00 00 00    .........T......
0030: 60 03 42 c9 45 22 9d 08 a5 1f 68 5f fc 16 00 00    `.B.E"....h_....
0040: 00 00 00 00 00 00 00 00 40 40 00 00 00 00 00 00    ........@@......
0050: 1d 08 00 00 00 00 00 00 00 00 00 00 00 00 6d 0b    ..............m.
0060: db 07 3e 08 00 00 00 00 00 00 00 00 00 00 00 00    ..>.............
0070: 00 00 00 00 00 00 00 00 15 04 00 00 00 00 db 06    ................
0080: e0 fd 83 80 32 00 ff 00 00 00 00 00 00 00 00 21    ....2..........!
0090: 07 a5 07 07 00 02 00 00 00 00 00 00 00 00 00 00    ................
00a0: 00 00 00 00 00 00 00 00 1b 08 00 00 00 00 db 06    ................
00b0: 00 00 00 00 00 00 00 00 00 7f 00 ba 00 00 00 00    ................
00c0: 01 01 02 04 07 0d 10 1a 24 2e 35 3d 49 54 5c 63    ........$.5=IT\c
00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
00f0: 41 00 80 03 00 00 00 00 00 00 00 00 00 00 00    A..............


Some bits seem to differ, but apparently none of the regular enable bits
(if I'm reading the data sheet correctly).

>
> 3) The phy settings, unfortunately I do not know of
> a way to dump these, so lets just forget about these
> and focus on the other 2.
>
> Regards,
>
> Hans
>
>>
>>

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Michael Haas]

On 03/17/2016 11:52 AM, Hans de Goede wrote:
>
> 3) The phy settings, unfortunately I do not know of
> a way to dump these, so lets just forget about these
> and focus on the other 2.
>

You can dump these with 'mii read' in u-boot. I sat down with the
rtl8211eg data sheet and decided to look at 'PHYCR (PHY Specific Control
Register, Address 0x10)' and
'PHYSR (PHY Specific Status Register, Address 0x11)'.

There is no difference at 0x10 between working and broken. There are
some changed bits in  reserved areas in 0x11:

Bad:
=> mii read 1 0x10
01EE
=> mii read 1 0x11
AD5C
# 1010 1101 0101 1100


Good:
=> mii read 1 0x10
01EE
=> mii read 1 0x11
BDDC
# 1011 1101 1101 1100

Good #2:
=> mii read 1 0x11
BD5C
# 1011 1101 0101 1100


I haven't yet looked at other registers.

Michael

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[François-David Collin]

Hi,

As I?m banging my head on this too, please allow me to provide some details
I got two stable situations :
The Lime2 is connected directly to the Gbit interface of my laptop, speed are OK:

1. The Lime2 is connected directly to the Gbit interface of my laptop

[alarm at lime2 ~]$ iperf3 -s -p 5201
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.137.1, port 58077
[? 5] local 192.168.137.58 port 5201 connected to 192.168.137.1 port 58078
[ ID] Interval?????????? Transfer???? Bandwidth
[? 5]?? 0.00-1.00?? sec? 81.4 MBytes?? 683 Mbits/sec
[? 5]?? 1.00-2.00?? sec? 82.2 MBytes?? 690 Mbits/sec
[? 5]?? 2.00-3.00?? sec? 85.0 MBytes?? 713 Mbits/sec
[? 5]?? 3.00-4.00?? sec? 82.1 MBytes?? 689 Mbits/sec
[? 5]?? 4.00-5.00?? sec? 87.9 MBytes?? 738 Mbits/sec
[? 5]?? 5.00-6.00?? sec? 78.8 MBytes?? 661 Mbits/sec
[? 5]?? 6.00-7.00?? sec? 75.0 MBytes?? 629 Mbits/sec
[? 5]?? 7.00-8.00?? sec? 88.4 MBytes?? 741 Mbits/sec
[? 5]?? 8.00-9.00?? sec? 69.2 MBytes?? 581 Mbits/sec
[? 5]?? 9.00-10.00? sec? 67.2 MBytes?? 564 Mbits/sec
[? 5]? 10.00-10.04? sec? 2.82 MBytes?? 660 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval?????????? Transfer???? Bandwidth
[? 5]?? 0.00-10.04? sec? 0.00 Bytes? 0.00 bits/sec????????????????? sender
[? 5]?? 0.00-10.04? sec?? 800 MBytes?? 669 Mbits/sec????????????????? receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.137.1, port 58081
[? 5] local 192.168.137.58 port 5201 connected to 192.168.137.1 port 58082
[ ID] Interval?????????? Transfer???? Bandwidth?????? Retr? Cwnd
[? 5]?? 0.00-1.00?? sec? 71.4 MBytes?? 598 Mbits/sec??? 0??? 221 KBytes
[? 5]?? 1.00-2.00?? sec? 76.0 MBytes?? 637 Mbits/sec??? 0??? 221 KBytes
[? 5]?? 2.00-3.00?? sec? 76.8 MBytes?? 645 Mbits/sec??? 0??? 221 KBytes
[? 5]?? 3.00-4.00?? sec? 74.1 MBytes?? 621 Mbits/sec??? 0??? 221 KBytes
[? 5]?? 4.00-5.00?? sec? 75.0 MBytes?? 630 Mbits/sec??? 0??? 221 KBytes
[? 5]?? 5.00-6.00?? sec? 69.4 MBytes?? 582 Mbits/sec??? 0??? 221 KBytes
[? 5]?? 6.00-7.03?? sec? 68.6 MBytes?? 562 Mbits/sec??? 0??? 221 KBytes
[? 5]?? 7.03-8.03?? sec? 65.3 MBytes?? 548 Mbits/sec??? 0??? 221 KBytes
[? 5]?? 8.03-9.00?? sec? 64.1 MBytes?? 552 Mbits/sec??? 0??? 221 KBytes
[? 5]?? 9.00-10.00? sec? 72.8 MBytes?? 610 Mbits/sec?? ?0??? 221 KBytes
[? 5]? 10.00-10.04? sec? 2.27 MBytes?? 513 Mbits/sec??? 0??? 221 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval?????????? Transfer???? Bandwidth?????? Retr
[? 5]?? 0.00-10.04? sec?? 716 MBytes?? 598 Mbits/sec??? 0 ????????????sender
[? 5]?? 0.00-10.04? sec? 0.00 Bytes? 0.00 bits/sec????????????????? receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

[alarm at lime2 Dev]$ sudo ./mmio-dump 0x1c20164
01c20164: 00000006
[alarm at lime2 Dev]$ sudo i2cdump -f -y 0 0x34
No size specified (using byte-data access)
???? 0? 1? 2? 3? 4? 5? 6? 7? 8? 9? a? b? c? d? e? f??? 0123456789abcdef
00: c1 10 00 41 00 00 00 00 00 00 00 00 00 00 00 00??? ??.A............
10: 05 00 5f 00 00 00 00 00 00 00 00 00 00 00 00 00??? ?._.............
20: 00 00 00 1c 00 00 00 16 cb 54 00 00 00 00 00 00??? ...?...??T......
30: 60 03 42 c9 45 22 9d 0a a5 1f 68 5f fc 16 00 00??? `?B?E"????h_??..
40: 00 00 00 00 60 00 00 00 00 00 00 00 00 00 00 00??? ....`...........
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70 02??? ..............p?
60: dc 0e 3e 08 00 00 00 00 00 00 00 00 00 00 00 00??? ??>?............
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dd 0e??? ..............??
80: e0 fd 83 80 32 00 ff 00 00 00 00 00 00 00 00 21??? ????2..........!
90: 07 a5 07 07 00 02 00 00 00 00 00 00 00 00 00 00??? ????.?..........
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dd 0c??? ..............??
b0: 00 00 00 00 00 00 00 00 00 7f 00 ba 00 00 00 00??? .........?.?....
c0: 01 01 02 04 07 0d 10 1a 24 2e 35 3d 49 54 5c 63??? ????????$.5=IT\c
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00??? ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00??? ................
f0: 41 00 80 03 00 00 00 00 00 00 00 00 00 00 00 00??? A.??............

2. The Lime2 is connected to one of the 4 Gbit port of my home switch, TX speed are terrible, RX are somewhat OK

[alarm at lime2 ~]$ iperf3 -s -p 5201
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.0.10, port 58657
[? 5] local 192.168.0.8 port 5201 connected to 192.168.0.10 port 58658
[ ID] Interval?????????? Transfer???? Bandwidth
[? 5]?? 0.00-1.00?? sec? 0.00 Bytes? 0.00 bits/sec
[? 5]?? 1.00-2.00?? sec? 49.9 KBytes?? 409 Kbits/sec
[? 5]?? 2.00-3.00?? sec? 25.7 KBytes?? 210 Kbits/sec
[? 5]?? 3.00-4.00?? sec? 18.5 KBytes?? 152 Kbits/sec
[? 5]?? 4.00-5.00?? sec? 17.1 KBytes?? 140 Kbits/sec
[? 5]?? 5.00-6.00?? sec? 0.00 Bytes? 0.00 bits/sec
[? 5]?? 6.00-7.00?? sec? 0.00 Bytes? 0.00 bits/sec
[? 5]?? 7.00-8.00?? sec? 0.00 Bytes? 0.00 bits/sec
[? 5]?? 8.00-9.00?? sec? 0.00 Bytes? 0.00 bits/sec
[? 5]?? 9.00-10.00? sec? 0.00 Bytes? 0.00 bits/sec
[? 5]? 10.00-10.19? sec? 0.00 Bytes? 0.00 bits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval?????????? Transfer???? Bandwidth
[? 5]?? 0.00-10.19? sec? 0.00 Bytes? 0.00 bits/sec????????????????? sender
[? 5]?? 0.00-10.19? sec?? 111 KBytes? 89.4 Kbits/sec????????????????? receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.0.10, port 58684
[? 5] local 192.168.0.8 port 5201 connected to 192.168.0.10 port 58685
[ ID] Interval?????????? Transfer???? Bandwidth?????? Retr? Cwnd
[? 5]?? 0.00-1.01?? sec? 87.5 MBytes?? 728 Mbits/sec??? 0??? 210 KBytes
[? 5]?? 1.01-2.01?? sec? 89.3 MBytes?? 746 Mbits/sec??? 0??? 210 KBytes
[? 5]?? 2.01-3.00?? sec? 84.2 MBytes?? 710 Mbits/sec??? 0??? 221 KBytes
[? 5]?? 3.00-4.00?? sec? 85.3 MBytes?? 718 Mbits/sec??? 0??? 221 KBytes
[? 5]?? 4.00-5.01?? sec? 80.3 MBytes?? 668 Mbits/sec??? 0??? 221 KBytes
[? 5]?? 5.01-6.01?? sec? 88.1 MBytes?? 741 Mbits/sec??? 0??? 221 KBytes
[? 5]?? 6.01-7.00?? sec? 89.1 MBytes?? 751 Mbits/sec??? 0??? 221 KBytes
[? 5]?? 7.00-8.01?? sec? 89.5 MBytes?? 745 Mbits/sec??? 0??? 221 KBytes
[? 5]?? 8.01-9.00?? sec? 83.5 MBytes?? 708 Mbits/sec??? 0??? 221 KBytes
[? 5]?? 9.00-10.00? sec? 79.2 MBytes?? 664 Mbits/sec??? 0??? 221 KBytes
[? 5]? 10.00-10.06? sec? 2.75 MBytes?? 371 Mbits/sec??? 0??? 221 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval?????????? Transfer???? Bandwidth?????? Retr
[? 5]?? 0.00-10.06? sec?? 859 MBytes?? 716 Mbits/sec??? 0???????????? sender
[? 5]?? 0.00-10.06? sec? 0.00 Bytes? 0.00 bits/sec????????????????? receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

[alarm at lime2 Dev]$ sudo ./mmio-dump 0x1c20164
01c20164: 00000006
[alarm at lime2 Dev]$ sudo i2cdump -f -y 0 0x34
No size specified (using byte-data access)
???? 0? 1? 2? 3? 4? 5? 6? 7? 8? 9? a? b? c? d? e? f??? 0123456789abcdef
00: c1 10 00 41 00 00 00 00 00 00 00 00 00 00 00 00??? ??.A............
10: 05 00 5f 00 00 00 00 00 00 00 00 00 00 00 00 00??? ?._.............
20: 00 00 00 1c 00 00 00 16 cb 54 00 00 00 00 00 00??? ...?...??T......
30: 60 03 42 c9 45 22 9d 0a a5 1f 68 5f fc 16 00 00??? `?B?E"????h_??..
40: 00 00 00 00 60 00 00 00 00 00 00 00 00 00 00 00??? ....`...........
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6c 0a??? ..............l?
60: dd 08 3e 08 00 00 00 00 00 00 00 00 00 00 00 00??? ??>?............
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dd 0e??? ..............??
80: e0 fd 83 80 32 00 ff 00 00 00 00 00 00 00 00 21??? ????2..........!
90: 07 a5 07 07 00 02 00 00 00 00 00 00 00 00 00 00??? ????.?..........
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dd 06??? ..............??
b0: 00 00 00 00 00 00 00 00 00 7f 00 ba 00 00 00 00??? .........?.?....
c0: 01 01 02 04 07 0d 10 1a 24 2e 35 3d 49 54 5c 63??? ????????$.5=IT\c
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00??? ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00??? ................
f0: 41 00 80 03 00 00 00 00 00 00 00 00 00 00 00 00??? A.??............

Hope this helps to pinepoint the source of the problem ?

Regards,
-- 
Fran?ois-David Collin

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Hans de Goede]

Hi,

On 19-03-16 09:39, Fran?ois-David Collin wrote:
> Hi,
>
> As I?m banging my head on this too, please allow me to provide some details
> I got two stable situations :
> The Lime2 is connected directly to the Gbit interface of my laptop, speed are OK:

Michael Haas' work to debug this by looking at the phy registers
seems to be the most promising so-far, the clk reg and axp209
registers all seem to be identical between good and bad setups.

Can you try to:

1) Stop the boot in u-boot (press a key on the serial console)
2) Bring up the network, e.g. type "dhcp" then ctrl+c when it tries
to tftp
3) Do: "mii read 1 0x11" in u-boot and record the output ?

Regards,

Hans

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Michael Haas]

On 03/19/2016 10:32 AM, Hans de Goede wrote:
> Hi,
>
> On 19-03-16 09:39, Fran?ois-David Collin wrote:
>> Hi,
>>
>> As I?m banging my head on this too, please allow me to provide some
>> details
>> I got two stable situations :
>> The Lime2 is connected directly to the Gbit interface of my laptop,
>> speed are OK:
>
> Michael Haas' work to debug this by looking at the phy registers
> seems to be the most promising so-far, the clk reg and axp209
> registers all seem to be identical between good and bad setups.
>
> Can you try to:
>
> 1) Stop the boot in u-boot (press a key on the serial console)
> 2) Bring up the network, e.g. type "dhcp" then ctrl+c when it tries
> to tftp
> 3) Do: "mii read 1 0x11" in u-boot and record the output ?
>
> Regards,
>
> Hans


I am currently (as I write this email) looking at the full set of
registers for the PHY, including the additional
pages:

setenv miipagedump 'for page in 0x0 0x01 0x02 0x03 0x04 0x05 0x06 0x07;
do echo "page $page"; mii write 1 0x1f $page; run miidump; done; mii
write 1 0x1f 0x00'


setenv miireadable 'setenv x 0x0; while test $x -le 5; do echo $x; mii
dump 1 $x; setexpr x $x + 1; done'
setenv miidump 'setenv x 0x0; while test $x -le 31; do echo $x; mii read
1 $x; setexpr x $x + 1; done'
setenv pmicdump 'i2c md 0x34 0xff'
setenv clkdump 'md 0x1c20164'

setenv doboot 'run pmicdump; run clkdump; setenv bootargs
console=ttyS0,115200 rootwait panic=10; setenv autoload no;dhcp; run
miireadable; run miipagedump; setenv serverip 192.168.1.170;tftpboot
${scriptaddr} /debian-installer/armhf/tftpboot.scr;source ${scriptaddr}'


No results as of yet, but I have yet to do a run where I successfully
dump all extpages.. the script was off before hand. Some registers were
different between working and non-working runs, but these were mostly
reserved. I will be posting a full log later on.

Interesting: 01c20224 is 14888022 for broken runs and 14888021 on
working runs - but I have not verified this extensively.

I'm hanging out as 'laga' in #u-boot.

Michael

Another

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Michael Haas]

On 03/19/2016 10:32 AM, Hans de Goede wrote:
> Hi,
>
> On 19-03-16 09:39, Fran?ois-David Collin wrote:
>> Hi,
>>
>> As I?m banging my head on this too, please allow me to provide some
>> details
>> I got two stable situations :
>> The Lime2 is connected directly to the Gbit interface of my laptop,
>> speed are OK:
>
> Michael Haas' work to debug this by looking at the phy registers
> seems to be the most promising so-far, the clk reg and axp209
> registers all seem to be identical between good and bad setups.
>
> Can you try to:
>
> 1) Stop the boot in u-boot (press a key on the serial console)
> 2) Bring up the network, e.g. type "dhcp" then ctrl+c when it tries
> to tftp
> 3) Do: "mii read 1 0x11" in u-boot and record the output ?
>
> Regards,
>
> Hans

I'm attaching four files, two with tftp timeouts and two with a
successful boot.
The -miipages files include mii pages 0 to 7, but not extpages.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: broken.dump
Type: application/octet-stream
Size: 6817 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160319/d9fc1d69/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: broken-miipages.dump
Type: application/octet-stream
Size: 9834 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160319/d9fc1d69/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: working.dump
Type: application/octet-stream
Size: 8715 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160319/d9fc1d69/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: working-miipages.dump
Type: application/octet-stream
Size: 25352 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160319/d9fc1d69/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160319/d9fc1d69/attachment-0001.sig>

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Michael Haas]

On 03/19/2016 10:32 AM, Hans de Goede wrote:
> Hi,
>
> On 19-03-16 09:39, Fran?ois-David Collin wrote:
>> Hi,
>>
>> As I?m banging my head on this too, please allow me to provide some
>> details
>> I got two stable situations :
>> The Lime2 is connected directly to the Gbit interface of my laptop,
>> speed are OK:
>
> Michael Haas' work to debug this by looking at the phy registers
> seems to be the most promising so-far, the clk reg and axp209
> registers all seem to be identical between good and bad setups.
>
> Can you try to:
>
> 1) Stop the boot in u-boot (press a key on the serial console)
> 2) Bring up the network, e.g. type "dhcp" then ctrl+c when it tries
> to tftp
> 3) Do: "mii read 1 0x11" in u-boot and record the output ?
>
> Regards,
>
> Hans

Hi all,

i have diffed and cross-compared logs of several working and broken tftp
downloads. The most significant
difference between working and broken was registers 0xa, 0x1c and 0x2a
in the first MII page.

These registers started making sense when I looked at the datasheet for
the RTL8211CL. Previously, I was looking at the RTL8211E.

0xA was set to 7800 for working runs and 3800 for broken runs. The
difference is bit 14 in the GBSR: 'MASTER/SLAVE Configuration
Resolution'. In the broken runs, the autonegotation configured the
OlinuXino to 'slave'. I have whipped up a quick patch which disable the
master/slave part of the autonegotiation and force master mode.

The patch itself is quite terrible as it's forcing the master mode bits
for every phy, not just for the RTL8211CL. It's good enough for testing,
however, and I seem to be getting consistent download speeds. There are
occasional hangs when booting the downloaded kernel, but that is
probably a different issue.

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 51b5746..484b2be 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -170,6 +170,7 @@ int genphy_restart_aneg(struct phy_device *phydev)
 int genphy_config_aneg(struct phy_device *phydev)
 {
        int result;
+       phy_write(phydev, MDIO_DEVAD_NONE, 0x09, 0x1A00);
 
        if (AUTONEG_ENABLE != phydev->autoneg)
                return genphy_setup_forced(phydev);

Please test this change and let me know. If it's successful, I will
submit a proper version.

Best

Michael


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160319/67045f58/attachment.sig>

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[François-David Collin]

Hello,

Finally, some good news: it?s working.

Thanks you very much, sir. I wonder why nobody noticed or cared about this before.
Thanks, again. 

[alarm at lime2 ~]$ curl "http://192.168.0.254:8095/fixed/1G" -o /dev/null           % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1024M  100 1024M    0     0   104M      0  0:00:09  0:00:09 --:--:--  105M
[alarm at lime2 ~]$ iperf3 -c 192.168.0.19 5201
Connecting to host 192.168.0.19, port 5201
[  4] local 192.168.0.8 port 36226 connected to 192.168.0.19 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  91.4 MBytes   765 Mbits/sec    0    223 KBytes
[  4]   1.00-2.01   sec  92.8 MBytes   773 Mbits/sec    0    223 KBytes
[  4]   2.01-3.00   sec  91.2 MBytes   771 Mbits/sec    0    223 KBytes
[  4]   3.00-4.00   sec  92.0 MBytes   773 Mbits/sec    0    223 KBytes
[  4]   4.00-5.00   sec  86.6 MBytes   725 Mbits/sec    0    223 KBytes
[  4]   5.00-6.00   sec  91.1 MBytes   763 Mbits/sec    0    223 KBytes
[  4]   6.00-7.00   sec  92.9 MBytes   780 Mbits/sec    0    223 KBytes
[  4]   7.00-8.01   sec  92.2 MBytes   772 Mbits/sec    0    223 KBytes
[  4]   8.01-9.00   sec  89.5 MBytes   753 Mbits/sec    0    223 KBytes
[  4]   9.00-10.00  sec  89.0 MBytes   749 Mbits/sec    0    223 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   909 MBytes   762 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   909 MBytes   762 Mbits/sec                  receiver

iperf Done.
[alarm at lime2 ~]$ iperf3 -c 192.168.0.19 5201 -R
Connecting to host 192.168.0.19, port 5201
Reverse mode, remote host 192.168.0.19 is sending
[  4] local 192.168.0.8 port 36230 connected to 192.168.0.19 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   112 MBytes   936 Mbits/sec
[  4]   1.00-2.00   sec   112 MBytes   937 Mbits/sec
[  4]   2.00-3.00   sec   112 MBytes   938 Mbits/sec
[  4]   3.00-4.00   sec   112 MBytes   938 Mbits/sec
[  4]   4.00-5.00   sec   112 MBytes   938 Mbits/sec
[  4]   5.00-6.00   sec   111 MBytes   935 Mbits/sec
[  4]   6.00-7.00   sec   111 MBytes   930 Mbits/sec
[  4]   7.00-8.00   sec   111 MBytes   935 Mbits/sec
[  4]   8.00-9.00   sec   112 MBytes   937 Mbits/sec
[  4]   9.00-10.00  sec   111 MBytes   935 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec  1.09 GBytes   936 Mbits/sec                  sender
[  4]   0.00-10.00  sec  1.09 GBytes   936 Mbits/sec                  receiver

iperf Done.

-- 
Fran?ois-David Collin

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Hans de Goede]

Hi,

On 19-03-16 14:40, Michael Haas wrote:
> On 03/19/2016 10:32 AM, Hans de Goede wrote:
>> Hi,
>>
>> On 19-03-16 09:39, Fran?ois-David Collin wrote:
>>> Hi,
>>>
>>> As I?m banging my head on this too, please allow me to provide some
>>> details
>>> I got two stable situations :
>>> The Lime2 is connected directly to the Gbit interface of my laptop,
>>> speed are OK:
>>
>> Michael Haas' work to debug this by looking at the phy registers
>> seems to be the most promising so-far, the clk reg and axp209
>> registers all seem to be identical between good and bad setups.
>>
>> Can you try to:
>>
>> 1) Stop the boot in u-boot (press a key on the serial console)
>> 2) Bring up the network, e.g. type "dhcp" then ctrl+c when it tries
>> to tftp
>> 3) Do: "mii read 1 0x11" in u-boot and record the output ?
>>
>> Regards,
>>
>> Hans
>
> Hi all,
>
> i have diffed and cross-compared logs of several working and broken tftp
> downloads. The most significant
> difference between working and broken was registers 0xa, 0x1c and 0x2a
> in the first MII page.
>
> These registers started making sense when I looked at the datasheet for
> the RTL8211CL. Previously, I was looking at the RTL8211E.
>
> 0xA was set to 7800 for working runs and 3800 for broken runs. The
> difference is bit 14 in the GBSR: 'MASTER/SLAVE Configuration
> Resolution'. In the broken runs, the autonegotation configured the
> OlinuXino to 'slave'. I have whipped up a quick patch which disable the
> master/slave part of the autonegotiation and force master mode.
>
> The patch itself is quite terrible as it's forcing the master mode bits
> for every phy, not just for the RTL8211CL. It's good enough for testing,
> however, and I seem to be getting consistent download speeds. There are
> occasional hangs when booting the downloaded kernel, but that is
> probably a different issue.
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 51b5746..484b2be 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -170,6 +170,7 @@ int genphy_restart_aneg(struct phy_device *phydev)
>   int genphy_config_aneg(struct phy_device *phydev)
>   {
>          int result;
> +       phy_write(phydev, MDIO_DEVAD_NONE, 0x09, 0x1A00);
>
>          if (AUTONEG_ENABLE != phydev->autoneg)
>                  return genphy_setup_forced(phydev);
>
> Please test this change and let me know. If it's successful, I will
> submit a proper version.

Good catch, I wonder why we need this. I believe that the proper version
should probably be wrapped in a #ifdef CONFIG_REALTEK_PHY_FORCE_MASTER
and then add a Kconfig option for this (and enable it in the lime2
defconfig), forcing this on all rtl8211cl phy-s seems wrong, unless
someone can dig up an errata from realtek which said we should.

Are any other sunxi boards impacted by the same problem that you know ?

Regards,

Hans

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Michael Haas]

On 03/20/2016 02:45 PM, Hans de Goede wrote:
> Hi,
>
> On 19-03-16 14:40, Michael Haas wrote:
>> On 03/19/2016 10:32 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 19-03-16 09:39, Fran?ois-David Collin wrote:
>>>> Hi,
>>>>
>>>> As I?m banging my head on this too, please allow me to provide some
>>>> details
>>>> I got two stable situations :
>>>> The Lime2 is connected directly to the Gbit interface of my laptop,
>>>> speed are OK:
>>>
>>> Michael Haas' work to debug this by looking at the phy registers
>>> seems to be the most promising so-far, the clk reg and axp209
>>> registers all seem to be identical between good and bad setups.
>>>
>>> Can you try to:
>>>
>>> 1) Stop the boot in u-boot (press a key on the serial console)
>>> 2) Bring up the network, e.g. type "dhcp" then ctrl+c when it tries
>>> to tftp
>>> 3) Do: "mii read 1 0x11" in u-boot and record the output ?
>>>
>>> Regards,
>>>
>>> Hans
>>
>> Hi all,
>>
>> i have diffed and cross-compared logs of several working and broken tftp
>> downloads. The most significant
>> difference between working and broken was registers 0xa, 0x1c and 0x2a
>> in the first MII page.
>>
>> These registers started making sense when I looked at the datasheet for
>> the RTL8211CL. Previously, I was looking at the RTL8211E.
>>
>> 0xA was set to 7800 for working runs and 3800 for broken runs. The
>> difference is bit 14 in the GBSR: 'MASTER/SLAVE Configuration
>> Resolution'. In the broken runs, the autonegotation configured the
>> OlinuXino to 'slave'. I have whipped up a quick patch which disable the
>> master/slave part of the autonegotiation and force master mode.
>>
>> The patch itself is quite terrible as it's forcing the master mode bits
>> for every phy, not just for the RTL8211CL. It's good enough for testing,
>> however, and I seem to be getting consistent download speeds. There are
>> occasional hangs when booting the downloaded kernel, but that is
>> probably a different issue.
>>
>> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
>> index 51b5746..484b2be 100644
>> --- a/drivers/net/phy/phy.c
>> +++ b/drivers/net/phy/phy.c
>> @@ -170,6 +170,7 @@ int genphy_restart_aneg(struct phy_device *phydev)
>>   int genphy_config_aneg(struct phy_device *phydev)
>>   {
>>          int result;
>> +       phy_write(phydev, MDIO_DEVAD_NONE, 0x09, 0x1A00);
>>
>>          if (AUTONEG_ENABLE != phydev->autoneg)
>>                  return genphy_setup_forced(phydev);
>>
>> Please test this change and let me know. If it's successful, I will
>> submit a proper version.
>
> Good catch, I wonder why we need this. I believe that the proper version
> should probably be wrapped in a #ifdef CONFIG_REALTEK_PHY_FORCE_MASTER
> and then add a Kconfig option for this (and enable it in the lime2
> defconfig), forcing this on all rtl8211cl phy-s seems wrong, unless
> someone can dig up an errata from realtek which said we should.

I was going to add that in realtek.c, not in phy.c - as soon as I figure
out which section there is applicable. I have started a new thread
asking about that.
>
> Are any other sunxi boards impacted by the same problem that you know ?
>

No, I don't know of any other boards, but I have not looked very hard :)

Michael

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Hans de Goede]

Hi,

On 20-03-16 16:28, Michael Haas wrote:
> On 03/20/2016 02:45 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 19-03-16 14:40, Michael Haas wrote:
>>> On 03/19/2016 10:32 AM, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 19-03-16 09:39, Fran?ois-David Collin wrote:
>>>>> Hi,
>>>>>
>>>>> As I?m banging my head on this too, please allow me to provide some
>>>>> details
>>>>> I got two stable situations :
>>>>> The Lime2 is connected directly to the Gbit interface of my laptop,
>>>>> speed are OK:
>>>>
>>>> Michael Haas' work to debug this by looking at the phy registers
>>>> seems to be the most promising so-far, the clk reg and axp209
>>>> registers all seem to be identical between good and bad setups.
>>>>
>>>> Can you try to:
>>>>
>>>> 1) Stop the boot in u-boot (press a key on the serial console)
>>>> 2) Bring up the network, e.g. type "dhcp" then ctrl+c when it tries
>>>> to tftp
>>>> 3) Do: "mii read 1 0x11" in u-boot and record the output ?
>>>>
>>>> Regards,
>>>>
>>>> Hans
>>>
>>> Hi all,
>>>
>>> i have diffed and cross-compared logs of several working and broken tftp
>>> downloads. The most significant
>>> difference between working and broken was registers 0xa, 0x1c and 0x2a
>>> in the first MII page.
>>>
>>> These registers started making sense when I looked at the datasheet for
>>> the RTL8211CL. Previously, I was looking at the RTL8211E.
>>>
>>> 0xA was set to 7800 for working runs and 3800 for broken runs. The
>>> difference is bit 14 in the GBSR: 'MASTER/SLAVE Configuration
>>> Resolution'. In the broken runs, the autonegotation configured the
>>> OlinuXino to 'slave'. I have whipped up a quick patch which disable the
>>> master/slave part of the autonegotiation and force master mode.
>>>
>>> The patch itself is quite terrible as it's forcing the master mode bits
>>> for every phy, not just for the RTL8211CL. It's good enough for testing,
>>> however, and I seem to be getting consistent download speeds. There are
>>> occasional hangs when booting the downloaded kernel, but that is
>>> probably a different issue.
>>>
>>> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
>>> index 51b5746..484b2be 100644
>>> --- a/drivers/net/phy/phy.c
>>> +++ b/drivers/net/phy/phy.c
>>> @@ -170,6 +170,7 @@ int genphy_restart_aneg(struct phy_device *phydev)
>>>    int genphy_config_aneg(struct phy_device *phydev)
>>>    {
>>>           int result;
>>> +       phy_write(phydev, MDIO_DEVAD_NONE, 0x09, 0x1A00);
>>>
>>>           if (AUTONEG_ENABLE != phydev->autoneg)
>>>                   return genphy_setup_forced(phydev);
>>>
>>> Please test this change and let me know. If it's successful, I will
>>> submit a proper version.
>>
>> Good catch, I wonder why we need this. I believe that the proper version
>> should probably be wrapped in a #ifdef CONFIG_REALTEK_PHY_FORCE_MASTER
>> and then add a Kconfig option for this (and enable it in the lime2
>> defconfig), forcing this on all rtl8211cl phy-s seems wrong, unless
>> someone can dig up an errata from realtek which said we should.
>
> I was going to add that in realtek.c, not in phy.c - as soon as I figure
> out which section there is applicable.

Ack, I already understood that. What I mean is that even if you limit
the fix to just apply to rtl8211cl phys, that that is still a somewhat
big hammer if the problem only happens on the lime2. Always applying
the workaround if the phy is a rtl8211cl means also applying it on
other sunxi boards and likely also on boards with a completely different
soc which also happen to use the rtl8211cl, which is why I suggest that
you wrap it in #ifdef CONFIG_REALTEK_PHY_FORCE_MASTER and a matching
Kconfig bool, which defaults to false.

> I have started a new thread
> asking about that.

Ack I've seen that.

>> Are any other sunxi boards impacted by the same problem that you know ?
>>
>
> No, I don't know of any other boards, but I have not looked very hard :)

Ok, so for now lets put this fix / workaround behind a #ifdef then, and
enable it only on the lime2

Regards,

Hans

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Michael Haas]

On 03/21/2016 04:47 PM, Karsten Merker wrote:
>>>> Are any other sunxi boards impacted by the same problem that you know ?
>>> No, I don't know of any other boards, but I have not looked very hard :)
> At least the Olimex A20-SOM-EVB (which uses the same RTL8211CL
> PHY) has the same issue and forcing master mode helps there as
> well.  With the above change added on top of v2016.01, I can
> successfully boot via tftp on a gigabit link on both the Lime2
> and the A20-SOM-EVB, which was impossible before.
Great news!

>
> Some quick iperf measurements on the A20-SOM-EVB with the patch
> applied show network throughput comparable to what I get with
> other A20-based systems.
>
> All my other A20-based boards - which don't have problems on
> gigabit links - use an RTL8211E instead of the RTL8211CL.  I had
> been looking into the source of the gigabit problems on the
> A20-SOM-EVB for a while already and talked with Olimex about
> them.  Olimex has also been trying to debug the issue and told me
> that the problem doesn't seem to occur on all boards, and that
> during their tests different RTL8211CL chips (i.e. same chip
> model, but with different production date codes) behaved
> differently.  This would fit into the hypothesis that there might
> be some kind of erratum in at least some series of the RTL8211CL.
>
>

So, Olimex knows about these issues? :/ Perhaps you can CC your contact
there once we have a final patch.

By the way, I just searched the web for "rtl8211c master mode" and found
this [0]:

---%--

// The EVK board with RTL8211C requires this sequence per information 
	// Realtek.
	// 1. Register 0x1F, write 0005 -> Page 5
	// 2. Register 0x0C, write 0000
	// 3. Register 0x01, change bit [7]  to 1
	// 4. Register 0x1F, write 0000 -> Page 0

	// However, please note that it is not recommended to use the RTL8211CL 125MHz clock output because 
	// it is not stable when link at Slave mode. If you need the clock output, 
	// please consider using RTL8211E instead.
	// 5. Force manual "master" mode in auto-negotiation.

	#if defined(CONFIG_DIGICOLOR_MAINBOARD_THUNDERBOLT_REV1)
	if (!RTL8211C_hack) {
	  // Enable 125 Mhz clock output
	  gmac_mdio_write(ei, phy_id, 0x1f, 5);
	  gmac_mdio_write(ei, phy_id, 0x0c, 0);
  	  gmac_mdio_read (ei, phy_id, 0x01, &data);
	  data |= 0x80;
	  gmac_mdio_write(ei, phy_id, 0x01, data);
	  gmac_mdio_write(ei, phy_id, 0x1f, 0);
	  // Set Manual MASTER Mode
  	  gmac_mdio_read (ei, phy_id, 0x09, &data);
	  data |= 0x1800;
	  gmac_mdio_write(ei, phy_id, 0x09, data);
	  // Restart Autonegotiation
  	  gmac_mdio_read (ei, phy_id, 0x00, &data);
	  data |= 0x0200;
	  gmac_mdio_write(ei, phy_id, 0x00, data);
	  // All done now.
	  RTL8211C_hack = 1;
	}
	#endif

%---


I guess we are not the first to find this out the hard way. If the issue
is related to an internal clock of the RTL8211C, is there perhaps an
external clock we can use?



[0]
http://mydc-proj.googlecode.com/svn/trunk/linux/target/u-boot/2010.09-cnxt/board/cnxt/common/gmac_hal.c

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Hans de Goede]

Hi,

On 21-03-16 19:57, Michael Haas wrote:
> On 03/21/2016 04:47 PM, Karsten Merker wrote:
>>>>> Are any other sunxi boards impacted by the same problem that you know ?
>>>> No, I don't know of any other boards, but I have not looked very hard :)
>> At least the Olimex A20-SOM-EVB (which uses the same RTL8211CL
>> PHY) has the same issue and forcing master mode helps there as
>> well.  With the above change added on top of v2016.01, I can
>> successfully boot via tftp on a gigabit link on both the Lime2
>> and the A20-SOM-EVB, which was impossible before.
> Great news!
>
>>
>> Some quick iperf measurements on the A20-SOM-EVB with the patch
>> applied show network throughput comparable to what I get with
>> other A20-based systems.
>>
>> All my other A20-based boards - which don't have problems on
>> gigabit links - use an RTL8211E instead of the RTL8211CL.  I had
>> been looking into the source of the gigabit problems on the
>> A20-SOM-EVB for a while already and talked with Olimex about
>> them.  Olimex has also been trying to debug the issue and told me
>> that the problem doesn't seem to occur on all boards, and that
>> during their tests different RTL8211CL chips (i.e. same chip
>> model, but with different production date codes) behaved
>> differently.  This would fit into the hypothesis that there might
>> be some kind of erratum in at least some series of the RTL8211CL.
>>
>>
>
> So, Olimex knows about these issues? :/ Perhaps you can CC your contact
> there once we have a final patch.
>
> By the way, I just searched the web for "rtl8211c master mode" and found
> this [0]:
>
> ---%--
>
> // The EVK board with RTL8211C requires this sequence per information
> 	// Realtek.
> 	// 1. Register 0x1F, write 0005 -> Page 5
> 	// 2. Register 0x0C, write 0000
> 	// 3. Register 0x01, change bit [7]  to 1
> 	// 4. Register 0x1F, write 0000 -> Page 0
>
> 	// However, please note that it is not recommended to use the RTL8211CL 125MHz clock output because
> 	// it is not stable when link at Slave mode. If you need the clock output,
> 	// please consider using RTL8211E instead.
> 	// 5. Force manual "master" mode in auto-negotiation.
>
> 	#if defined(CONFIG_DIGICOLOR_MAINBOARD_THUNDERBOLT_REV1)
> 	if (!RTL8211C_hack) {
> 	  // Enable 125 Mhz clock output
> 	  gmac_mdio_write(ei, phy_id, 0x1f, 5);
> 	  gmac_mdio_write(ei, phy_id, 0x0c, 0);
>    	  gmac_mdio_read (ei, phy_id, 0x01, &data);
> 	  data |= 0x80;
> 	  gmac_mdio_write(ei, phy_id, 0x01, data);
> 	  gmac_mdio_write(ei, phy_id, 0x1f, 0);
> 	  // Set Manual MASTER Mode
>    	  gmac_mdio_read (ei, phy_id, 0x09, &data);
> 	  data |= 0x1800;
> 	  gmac_mdio_write(ei, phy_id, 0x09, data);
> 	  // Restart Autonegotiation
>    	  gmac_mdio_read (ei, phy_id, 0x00, &data);
> 	  data |= 0x0200;
> 	  gmac_mdio_write(ei, phy_id, 0x00, data);
> 	  // All done now.
> 	  RTL8211C_hack = 1;
> 	}
> 	#endif
>
> %---
>
>
> I guess we are not the first to find this out the hard way. If the issue
> is related to an internal clock of the RTL8211C, is there perhaps an
> external clock we can use?

Oh good catch, so I believe that we should submit a patch to the u-boot
realtek phy driver which:

1) Adds a seperate init function for the RTL8211C
2) In that function set the force master mode bit and then
    call the init function currently used for RTL8211C and others,
    this assumes that the more generic init function will not reset
    the force master mode bit.

Good work! I believe we're quite close to a fix now :)

Regards,

Hans

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Hans de Goede]

Hi,

On 21-03-16 21:59, Hans de Goede wrote:
> Hi,
>
> On 21-03-16 19:57, Michael Haas wrote:
>> On 03/21/2016 04:47 PM, Karsten Merker wrote:
>>>>>> Are any other sunxi boards impacted by the same problem that you know ?
>>>>> No, I don't know of any other boards, but I have not looked very hard :)
>>> At least the Olimex A20-SOM-EVB (which uses the same RTL8211CL
>>> PHY) has the same issue and forcing master mode helps there as
>>> well.  With the above change added on top of v2016.01, I can
>>> successfully boot via tftp on a gigabit link on both the Lime2
>>> and the A20-SOM-EVB, which was impossible before.
>> Great news!
>>
>>>
>>> Some quick iperf measurements on the A20-SOM-EVB with the patch
>>> applied show network throughput comparable to what I get with
>>> other A20-based systems.
>>>
>>> All my other A20-based boards - which don't have problems on
>>> gigabit links - use an RTL8211E instead of the RTL8211CL.  I had
>>> been looking into the source of the gigabit problems on the
>>> A20-SOM-EVB for a while already and talked with Olimex about
>>> them.  Olimex has also been trying to debug the issue and told me
>>> that the problem doesn't seem to occur on all boards, and that
>>> during their tests different RTL8211CL chips (i.e. same chip
>>> model, but with different production date codes) behaved
>>> differently.  This would fit into the hypothesis that there might
>>> be some kind of erratum in at least some series of the RTL8211CL.
>>>
>>>
>>
>> So, Olimex knows about these issues? :/ Perhaps you can CC your contact
>> there once we have a final patch.
>>
>> By the way, I just searched the web for "rtl8211c master mode" and found
>> this [0]:
>>
>> ---%--
>>
>> // The EVK board with RTL8211C requires this sequence per information
>>     // Realtek.
>>     // 1. Register 0x1F, write 0005 -> Page 5
>>     // 2. Register 0x0C, write 0000
>>     // 3. Register 0x01, change bit [7]  to 1
>>     // 4. Register 0x1F, write 0000 -> Page 0
>>
>>     // However, please note that it is not recommended to use the RTL8211CL 125MHz clock output because
>>     // it is not stable when link at Slave mode. If you need the clock output,
>>     // please consider using RTL8211E instead.
>>     // 5. Force manual "master" mode in auto-negotiation.
>>
>>     #if defined(CONFIG_DIGICOLOR_MAINBOARD_THUNDERBOLT_REV1)
>>     if (!RTL8211C_hack) {
>>       // Enable 125 Mhz clock output
>>       gmac_mdio_write(ei, phy_id, 0x1f, 5);
>>       gmac_mdio_write(ei, phy_id, 0x0c, 0);
>>          gmac_mdio_read (ei, phy_id, 0x01, &data);
>>       data |= 0x80;
>>       gmac_mdio_write(ei, phy_id, 0x01, data);
>>       gmac_mdio_write(ei, phy_id, 0x1f, 0);
>>       // Set Manual MASTER Mode
>>          gmac_mdio_read (ei, phy_id, 0x09, &data);
>>       data |= 0x1800;
>>       gmac_mdio_write(ei, phy_id, 0x09, data);
>>       // Restart Autonegotiation
>>          gmac_mdio_read (ei, phy_id, 0x00, &data);
>>       data |= 0x0200;
>>       gmac_mdio_write(ei, phy_id, 0x00, data);
>>       // All done now.
>>       RTL8211C_hack = 1;
>>     }
>>     #endif
>>
>> %---
>>
>>
>> I guess we are not the first to find this out the hard way. If the issue
>> is related to an internal clock of the RTL8211C, is there perhaps an
>> external clock we can use?
>
> Oh good catch, so I believe that we should submit a patch to the u-boot
> realtek phy driver which:
>
> 1) Adds a seperate init function for the RTL8211C
> 2) In that function set the force master mode bit and then
>     call the init function currently used for RTL8211C and others,
>     this assumes that the more generic init function will not reset
>     the force master mode bit.
>
> Good work! I believe we're quite close to a fix now :)

Hmm, I just realized / read that RTL8211B and RTL8211C have the same
phyid, maybe there is some other reg which we can use to differentiate
between them ?

Otherwise we are back to having a #ifdef for the fix ...

Regards,

Hans

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Michael Haas]

>Hmm, I just realized / read that RTL8211B and RTL8211C have the same
phyid, maybe there is some other reg which we can use to differentiate between them ?

>Otherwise we are back to having a #ifdef for the fix ...

>Regards,

Hans


The BSD people seem to key off a revision field, which has value 3 for the rtl8211c: 

https://lists.freebsd.org/pipermail/svn-src-stable-9/2015-March/007669.html

Excuse the bad quoting, I am on mobile and the client is broken.

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Hans de Goede]

Hi,

On 21-03-16 22:47, Michael Haas wrote:
>> Hmm, I just realized / read that RTL8211B and RTL8211C have the same
> phyid, maybe there is some other reg which we can use to differentiate between them ?
>
>> Otherwise we are back to having a #ifdef for the fix ...
>
>> Regards,
>
> Hans
>
>
> The BSD people seem to key off a revision field, which has value 3 for the rtl8211c:
>
> https://lists.freebsd.org/pipermail/svn-src-stable-9/2015-March/007669.html

And another good catch, yes that looks like it should work.

Now all we need to do is turn all this info into a proper patch.

Regards,

Hans

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Michael Haas]

On 03/21/2016 11:00 PM, Hans de Goede wrote:
> Hi,
>
> On 21-03-16 22:47, Michael Haas wrote:
>>> Hmm, I just realized / read that RTL8211B and RTL8211C have the same
>> phyid, maybe there is some other reg which we can use to
>> differentiate between them ?
>>
>>> Otherwise we are back to having a #ifdef for the fix ...
>>
>>> Regards,
>>
>> Hans
>>
>>
>> The BSD people seem to key off a revision field, which has value 3
>> for the rtl8211c:
>>
>> https://lists.freebsd.org/pipermail/svn-src-stable-9/2015-March/007669.html
>>
>
> And another good catch, yes that looks like it should work.
>
> Now all we need to do is turn all this info into a proper patch.
>
> Regards,
>
> Hans
I'm going to work on that. I'd like to have the bragging rights for
having a patch in Das U-Boot :)

Michael

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Peter Korsgaard]

>>>>> "Hans" == Hans de Goede <hdegoede@redhat.com> writes:

Hi,

 > Oh good catch, so I believe that we should submit a patch to the u-boot
 > realtek phy driver which:

 > 1) Adds a seperate init function for the RTL8211C
 > 2) In that function set the force master mode bit and then
 >    call the init function currently used for RTL8211C and others,
 >    this assumes that the more generic init function will not reset
 >    the force master mode bit.

So what happens if you connect two of these boards together without a
switch in between? Will they be able to autonegotiate?

-- 
Bye, Peter Korsgaard

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Hans de Goede]

Hi,

On 22-03-16 09:46, Peter Korsgaard wrote:
>>>>>> "Hans" == Hans de Goede <hdegoede@redhat.com> writes:
>
> Hi,
>
>   > Oh good catch, so I believe that we should submit a patch to the u-boot
>   > realtek phy driver which:
>
>   > 1) Adds a seperate init function for the RTL8211C
>   > 2) In that function set the force master mode bit and then
>   >    call the init function currently used for RTL8211C and others,
>   >    this assumes that the more generic init function will not reset
>   >    the force master mode bit.
>
> So what happens if you connect two of these boards together without a
> switch in between? Will they be able to autonegotiate?

Likely not, but without this fix, they would and they would have an
unreliable connection. Arguably no connection is better then an
unreliable one.

Regards,

Hans

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Michael Haas]

Am 22. M?rz 2016 09:57:16 MEZ, schrieb Hans de Goede <hdegoede@redhat.com>:
>Hi,
>
>On 22-03-16 09:46, Peter Korsgaard wrote:
>>>>>>> "Hans" == Hans de Goede <hdegoede@redhat.com> writes:
>>
>> Hi,
>>
>>   > Oh good catch, so I believe that we should submit a patch to the
>u-boot
>>   > realtek phy driver which:
>>
>>   > 1) Adds a seperate init function for the RTL8211C
>>   > 2) In that function set the force master mode bit and then
>>   >    call the init function currently used for RTL8211C and others,
>>   >    this assumes that the more generic init function will not
>reset
>>   >    the force master mode bit.
>>
>> So what happens if you connect two of these boards together without a
>> switch in between? Will they be able to autonegotiate?
>
>Likely not, but without this fix, they would and they would have an
>unreliable connection. Arguably no connection is better then an
>unreliable one.
>
>Regards,
>
>Hans

I assume that forcing the link to 100mbps would work for this case. After all, the fix should only apply for GBit mode.

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Peter Korsgaard]

>>>>> "Hans" == Hans de Goede <hdegoede@redhat.com> writes:

 >> So what happens if you connect two of these boards together without a
 >> switch in between? Will they be able to autonegotiate?

 > Likely not, but without this fix, they would and they would have an
 > unreliable connection. Arguably no connection is better then an
 > unreliable one.

True.

-- 
Venlig hilsen,
Peter Korsgaard 

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Hans de Goede]

Hi,

On 21-03-16 18:30, Karsten Merker wrote:
> On Mon, Mar 21, 2016 at 04:47:15PM +0100, Karsten Merker wrote:
>> On Sun, Mar 20, 2016 at 07:51:20PM +0100, Hans de Goede wrote:
>>> On 20-03-16 16:28, Michael Haas wrote:
>>>> On 03/20/2016 02:45 PM, Hans de Goede wrote:
>>>>> On 19-03-16 14:40, Michael Haas wrote:
>
>>>>>> 0xA was set to 7800 for working runs and 3800 for broken runs. The
>>>>>> difference is bit 14 in the GBSR: 'MASTER/SLAVE Configuration
>>>>>> Resolution'. In the broken runs, the autonegotation configured the
>>>>>> OlinuXino to 'slave'. I have whipped up a quick patch which disable the
>>>>>> master/slave part of the autonegotiation and force master mode.
>
>>>>>> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
>>>>>> index 51b5746..484b2be 100644
>>>>>> --- a/drivers/net/phy/phy.c
>>>>>> +++ b/drivers/net/phy/phy.c
>>>>>> @@ -170,6 +170,7 @@ int genphy_restart_aneg(struct phy_device *phydev)
>>>>>>    int genphy_config_aneg(struct phy_device *phydev)
>>>>>>    {
>>>>>>           int result;
>>>>>> +       phy_write(phydev, MDIO_DEVAD_NONE, 0x09, 0x1A00);
>>>>>>
>>>>>>           if (AUTONEG_ENABLE != phydev->autoneg)
>>>>>>                   return genphy_setup_forced(phydev);
>>>>>>
>
>>>> I was going to add that in realtek.c, not in phy.c - as soon as I figure
>>>> out which section there is applicable.
>
> Unfortunately the issue is now split over two threads - this one and the
> "Which entry in drivers/net/phy/realtek.c matches my device?" thread.
>
> It looks like we have three related but separate issues here:
>
> a) The sunxi config doesn't actually build the phy drivers:
>
>     include/configs/sunxi-common.h contains:
>
>     302 /* Ethernet support */
>     303 #ifdef CONFIG_SUNXI_EMAC
>     304 #define CONFIG_PHY_ADDR         1
>     305 #define CONFIG_MII                      /* MII PHY management           */
>     306 #define CONFIG_PHYLIB
>     307 #endif
>     308
>     309 #ifdef CONFIG_SUNXI_GMAC
>     310 #define CONFIG_PHY_GIGE                 /* GMAC can use gigabit PHY     */
>     311 #define CONFIG_PHY_ADDR         1
>     312 #define CONFIG_MII                      /* MII PHY management           */
>     313 #endif
>
>     For the sunxi EMAC case (which is AFAIK only used on A10/A13)
>     CONFIG_PHYLIB is enabled, but for the CONFIG_SUNXI_GMAC case (all
>     other sunxi-based systems) we don't enable any PHY driver.

We do enable phylib for gmac based systems, we have CONFIG_ETH_DESIGNWARE=y
in defconfigs using GMAC and drivers/net/Kconfig has:

config ETH_DESIGNWARE
         bool "Synopsys Designware Ethernet MAC"
         select PHYLIB

We do however only enable the generic (vendor neutral phy) phylib support
and not any vendor specific drivers, I've a commit in my tree enabling
realtek phy support.

https://github.com/jwrdegoede/u-boot-sunxi/commit/8121866aa55b010d31fe75c1eb5d2372c1e27a62

So it looks like a) is already covered :)

>     So we
>     either need to enable CONFIG_PHYLIB for CONFIG_SUNXI_GMAC as well
>     or enable the relevant PHY drivers (do we actually have anything
>     besides realtek on sunxi-based systems?) separately, i.e.
>     something like
>
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index b26363d..ea15e37 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -310,6 +310,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
>
>
> b) The realtek PHY driver (drivers/net/phy/realtek.c) doesn't match
>     on the RTL8211CL PHY ID, so even if it is compiled in, it still
>     doesn't work. For more details on this issue, see the "Which entry
>     in drivers/net/phy/realtek.c matches my device?" thread.
>
>
> c) The master/slave mode problem that can be worked around by forcing
>     master mode on the RTL8211CL.

Regards,

Hans

[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[François-David Collin]

Hi,

As I?m banging my head on this too, please allow me to provide some details
I got two stable situations :
The Lime2 is connected directly to the Gbit interface of my laptop, speed are OK:

1. The Lime2 is connected directly to the Gbit interface of my laptop

[alarm at lime2 ~]$ iperf3 -s -p 5201
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.137.1, port 58077
[  5] local 192.168.137.58 port 5201 connected to 192.168.137.1 port 58078
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec  81.4 MBytes   683 Mbits/sec
[  5]   1.00-2.00   sec  82.2 MBytes   690 Mbits/sec
[  5]   2.00-3.00   sec  85.0 MBytes   713 Mbits/sec
[  5]   3.00-4.00   sec  82.1 MBytes   689 Mbits/sec
[  5]   4.00-5.00   sec  87.9 MBytes   738 Mbits/sec
[  5]   5.00-6.00   sec  78.8 MBytes   661 Mbits/sec
[  5]   6.00-7.00   sec  75.0 MBytes   629 Mbits/sec
[  5]   7.00-8.00   sec  88.4 MBytes   741 Mbits/sec
[  5]   8.00-9.00   sec  69.2 MBytes   581 Mbits/sec
[  5]   9.00-10.00  sec  67.2 MBytes   564 Mbits/sec
[  5]  10.00-10.04  sec  2.82 MBytes   660 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.04  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.04  sec   800 MBytes   669 Mbits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.137.1, port 58081
[  5] local 192.168.137.58 port 5201 connected to 192.168.137.1 port 58082
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  5]   0.00-1.00   sec  71.4 MBytes   598 Mbits/sec    0    221 KBytes
[  5]   1.00-2.00   sec  76.0 MBytes   637 Mbits/sec    0    221 KBytes
[  5]   2.00-3.00   sec  76.8 MBytes   645 Mbits/sec    0    221 KBytes
[  5]   3.00-4.00   sec  74.1 MBytes   621 Mbits/sec    0    221 KBytes
[  5]   4.00-5.00   sec  75.0 MBytes   630 Mbits/sec    0    221 KBytes
[  5]   5.00-6.00   sec  69.4 MBytes   582 Mbits/sec    0    221 KBytes
[  5]   6.00-7.03   sec  68.6 MBytes   562 Mbits/sec    0    221 KBytes
[  5]   7.03-8.03   sec  65.3 MBytes   548 Mbits/sec    0    221 KBytes
[  5]   8.03-9.00   sec  64.1 MBytes   552 Mbits/sec    0    221 KBytes
[  5]   9.00-10.00  sec  72.8 MBytes   610 Mbits/sec    0    221 KBytes
[  5]  10.00-10.04  sec  2.27 MBytes   513 Mbits/sec    0    221 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.04  sec   716 MBytes   598 Mbits/sec    0             sender
[  5]   0.00-10.04  sec  0.00 Bytes  0.00 bits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

[alarm at lime2 Dev]$ sudo ./mmio-dump 0x1c20164
01c20164: 00000006
[alarm at lime2 Dev]$ sudo i2cdump -f -y 0 0x34
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: c1 10 00 41 00 00 00 00 00 00 00 00 00 00 00 00    ??.A............
10: 05 00 5f 00 00 00 00 00 00 00 00 00 00 00 00 00    ?._.............
20: 00 00 00 1c 00 00 00 16 cb 54 00 00 00 00 00 00    ...?...??T......
30: 60 03 42 c9 45 22 9d 0a a5 1f 68 5f fc 16 00 00    `?B?E"????h_??..
40: 00 00 00 00 60 00 00 00 00 00 00 00 00 00 00 00    ....`...........
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70 02    ..............p?
60: dc 0e 3e 08 00 00 00 00 00 00 00 00 00 00 00 00    ??>?............
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dd 0e    ..............??
80: e0 fd 83 80 32 00 ff 00 00 00 00 00 00 00 00 21    ????2..........!
90: 07 a5 07 07 00 02 00 00 00 00 00 00 00 00 00 00    ????.?..........
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dd 0c    ..............??
b0: 00 00 00 00 00 00 00 00 00 7f 00 ba 00 00 00 00    .........?.?....
c0: 01 01 02 04 07 0d 10 1a 24 2e 35 3d 49 54 5c 63    ????????$.5=IT\c
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 41 00 80 03 00 00 00 00 00 00 00 00 00 00 00 00    A.??............

2. The Lime2 is connected to one of the 4 Gbit port of my home switch, TX speed are terrible, RX are somewhat OK

[alarm at lime2 ~]$ iperf3 -s -p 5201
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.0.10, port 58657
[  5] local 192.168.0.8 port 5201 connected to 192.168.0.10 port 58658
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec  0.00 Bytes  0.00 bits/sec
[  5]   1.00-2.00   sec  49.9 KBytes   409 Kbits/sec
[  5]   2.00-3.00   sec  25.7 KBytes   210 Kbits/sec
[  5]   3.00-4.00   sec  18.5 KBytes   152 Kbits/sec
[  5]   4.00-5.00   sec  17.1 KBytes   140 Kbits/sec
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec
[  5]  10.00-10.19  sec  0.00 Bytes  0.00 bits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.19  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.19  sec   111 KBytes  89.4 Kbits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.0.10, port 58684
[  5] local 192.168.0.8 port 5201 connected to 192.168.0.10 port 58685
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  5]   0.00-1.01   sec  87.5 MBytes   728 Mbits/sec    0    210 KBytes
[  5]   1.01-2.01   sec  89.3 MBytes   746 Mbits/sec    0    210 KBytes
[  5]   2.01-3.00   sec  84.2 MBytes   710 Mbits/sec    0    221 KBytes
[  5]   3.00-4.00   sec  85.3 MBytes   718 Mbits/sec    0    221 KBytes
[  5]   4.00-5.01   sec  80.3 MBytes   668 Mbits/sec    0    221 KBytes
[  5]   5.01-6.01   sec  88.1 MBytes   741 Mbits/sec    0    221 KBytes
[  5]   6.01-7.00   sec  89.1 MBytes   751 Mbits/sec    0    221 KBytes
[  5]   7.00-8.01   sec  89.5 MBytes   745 Mbits/sec    0    221 KBytes
[  5]   8.01-9.00   sec  83.5 MBytes   708 Mbits/sec    0    221 KBytes
[  5]   9.00-10.00  sec  79.2 MBytes   664 Mbits/sec    0    221 KBytes
[  5]  10.00-10.06  sec  2.75 MBytes   371 Mbits/sec    0    221 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.06  sec   859 MBytes   716 Mbits/sec    0             sender
[  5]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

[alarm at lime2 Dev]$ sudo ./mmio-dump 0x1c20164
01c20164: 00000006
[alarm at lime2 Dev]$ sudo i2cdump -f -y 0 0x34
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: c1 10 00 41 00 00 00 00 00 00 00 00 00 00 00 00    ??.A............
10: 05 00 5f 00 00 00 00 00 00 00 00 00 00 00 00 00    ?._.............
20: 00 00 00 1c 00 00 00 16 cb 54 00 00 00 00 00 00    ...?...??T......
30: 60 03 42 c9 45 22 9d 0a a5 1f 68 5f fc 16 00 00    `?B?E"????h_??..
40: 00 00 00 00 60 00 00 00 00 00 00 00 00 00 00 00    ....`...........
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6c 0a    ..............l?
60: dd 08 3e 08 00 00 00 00 00 00 00 00 00 00 00 00    ??>?............
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dd 0e    ..............??
80: e0 fd 83 80 32 00 ff 00 00 00 00 00 00 00 00 21    ????2..........!
90: 07 a5 07 07 00 02 00 00 00 00 00 00 00 00 00 00    ????.?..........
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dd 06    ..............??
b0: 00 00 00 00 00 00 00 00 00 7f 00 ba 00 00 00 00    .........?.?....
c0: 01 01 02 04 07 0d 10 1a 24 2e 35 3d 49 54 5c 63    ????????$.5=IT\c
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 41 00 80 03 00 00 00 00 00 00 00 00 00 00 00 00    A.??............

Hope this helps to pinepoint the source of the problem ?

Regards,
-- 
Fran?ois-David Collin