| Message ID | 20160316203642.GC1817@excalibur.cnev.de |
|---|---|
| State | Not Applicable |
| Headers | show |
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% |*******************************| 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 > > > > >
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
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 > >
On Fri, Mar 18, 2016 at 08:41:07AM +0100, Hans de Goede wrote: > 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 :) Hrm, i2c-mv64xxx is indeed not included in the installer... The regular Debian kernel package generally contains all available modules for its target platform. This isn't the case with the Debian installer though. 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
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.
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 > >> >>
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
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, -- François-David Collin
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: > > 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
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.
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@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot
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,
From 3a21c46e772b30929540c8ee9775fb314523ae4e Mon Sep 17 00:00:00 2001 From: Karsten Merker <merker@debian.org> Date: Sun, 28 Feb 2016 11:34:36 +0100 Subject: [PATCH] sunxi: Allow configuring the GMAC Receive Clock Delay Chain via Kconfig. --- board/sunxi/Kconfig | 6 ++++++ board/sunxi/gmac.c | 2 ++ 2 files changed, 8 insertions(+) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 5e9d3af..636bd5e 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -597,6 +597,12 @@ config GMAC_TX_DELAY ---help--- Set the GMAC Transmit Clock Delay Chain value. +config GMAC_RX_DELAY + int "GMAC Receive Clock Delay Chain" + default 0 + ---help--- + Set the GMAC Receive Clock Delay Chain value. + config SPL_STACK_R_ADDR default 0x4fe00000 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || MACH_SUN7I || MACH_SUN8I default 0x2fe00000 if MACH_SUN9I diff --git a/board/sunxi/gmac.c b/board/sunxi/gmac.c index 4e222d8..897036c 100644 --- a/board/sunxi/gmac.c +++ b/board/sunxi/gmac.c @@ -26,6 +26,8 @@ int sunxi_gmac_initialize(bd_t *bis) CCM_GMAC_CTRL_GPIT_RGMII); setbits_le32(&ccm->gmac_clk_cfg, CCM_GMAC_CTRL_TX_CLK_DELAY(CONFIG_GMAC_TX_DELAY)); + setbits_le32(&ccm->gmac_clk_cfg, + CCM_GMAC_CTRL_RX_CLK_DELAY(CONFIG_GMAC_RX_DELAY)); #else setbits_le32(&ccm->gmac_clk_cfg, CCM_GMAC_CTRL_TX_CLK_SRC_MII | CCM_GMAC_CTRL_GPIT_MII); -- 2.1.4