Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
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
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% |*******************************| 315M0: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% |*******************************| 315M0: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
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:
- The gmc clk register, to do this download mmio_dump from:
Working GBit: 01c20164: 00000c06
Broken GBit: tomorrow :)
- 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?
- 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
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:
- The gmc clk register, to do this download mmio_dump from:
Working GBit: 01c20164: 00000c06
Broken GBit: tomorrow :)
- 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
- 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
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 ................
- 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).
- 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
On 03/17/2016 11:52 AM, Hans de Goede wrote:
- 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
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@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@lime2 Dev]$ sudo ./mmio-dump 0x1c20164 01c20164: 00000006 [alarm@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@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@lime2 Dev]$ sudo ./mmio-dump 0x1c20164 01c20164: 00000006 [alarm@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,
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
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:
- Stop the boot in u-boot (press a key on the serial console)
- 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
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:
- Stop the boot in u-boot (press a key on the serial console)
- 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.
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:
- Stop the boot in u-boot (press a key on the serial console)
- 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
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@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@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@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.
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:
- Stop the boot in u-boot (press a key on the serial console)
- 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
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:
- Stop the boot in u-boot (press a key on the serial console)
- 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
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:
- Stop the boot in u-boot (press a key on the serial console)
- 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
participants (3)
-
François-David Collin -
Hans de Goede -
Michael Haas