What will it take to get the Ethernet port working?

[clarkss12]

As everyone knows, the gigabit Ethernet port does not work on the 2gig boards running Android and Remix OS.  I have the WiFi card, that came with my pledge, installed, and it is OK for browsing the internet but not for a serious media player device.

Who is in charge of getting this to work??  Is there anyone steering the ship?

[tllim]

As everyone knows, the gigabit Ethernet port does not work on the 2gig boards running Android and Remix OS.  I have the WiFi card, that came with my pledge, installed, and it is OK for browsing the internet but not for a serious media player device.

Who is in charge of getting this to work??  Is there anyone steering the ship?

We are currently looking into this issue and aware several cases that Gbe seems don't work. We think may cause by the Gbe Tx and Rx delay parameter tuning and currently work on this direction.

[clarkss12]

As everyone knows, the gigabit Ethernet port does not work on the 2gig boards running Android and Remix OS.  I have the WiFi card, that came with my pledge, installed, and it is OK for browsing the internet but not for a serious media player device.

Who is in charge of getting this to work??  Is there anyone steering the ship?

We are currently looking into this issue and aware several cases that Gbe seems don't work. We think may cause by the Gbe Tx and Rx delay parameter tuning and currently work on this direction.

Thank you, really appreciate that.  Without Ethernet, these boards are useless for me.  Second item, the fonts are too small on the Remix OS.  The DPI is set to 160 in the build.prop, if it could be changed to 240 DPI, then that would make a perfect box with much larger fonts.

[xalius]

Are all the boards reported with GbE issues 2GB variants? If so, are there differences in the GbE implementation regarding to the layout?

[tllim]

Are all the boards reported with GbE issues 2GB variants? If so, are there differences in the GbE implementation regarding to the layout?

As our understanding, this issue seems happen on both 1GB and 2GB boards. Due to there are more 2GB boards in the field, it may appear that that related to 2GB board. The GbE PCB routing circuit between 1GB and 2GB board should be identical. There is one theory whether is related to different batch of Realtek RTL8211 Phy chip, this chip was in short supply due to Taiwan earthquake and our manufacturer need to purchase at open market (at higher price) to fulfill the KS delivery. I have go thru this checking with one backer and he has 3 2GB boards able to connect to GbE successfully but one 2GB board cannot, and discovered the all 4 boards Realtek RTL8211 comes from same batch thru inspecting the chip marking.

[amc2012]

Are all the boards reported with GbE issues 2GB variants? If so, are there differences in the GbE implementation regarding to the layout?

As our understanding, this issue seems happen on both 1GB and 2GB boards. Due to there are more 2GB boards in the field, it may appear that that related to 2GB board. The GbE PCB routing circuit between 1GB and 2GB board should be identical. There is one theory whether is related to different batch of Realtek RTL8211 Phy chip, this chip was in short supply due to Taiwan earthquake and our manufacturer need to purchase at open market (at higher price) to fulfill the KS delivery. I have go thru this checking with one backer and he has 3 2GB boards able to connect to GbE successfully but one 2GB board cannot, and discovered the all 4 boards Realtek RTL8211 comes from same batch thru inspecting the chip marking.

I have one of the affected boards as well. If there's anything I can do to help. 

I tried playing with the rx-delay & tx-delay with no success. 

Thanks again.

[waldo]

I have one working board and one broken one ; I've been playing around with the rx tx values.
Results are attached ...  The Pine stopped rebooting at 1 1, didn't have a monitor attached so don't know why.

The wget and iperf are from a local apache server capable of delivering over 70 MByte/s http no problem

 The good results for tx1rx1 had me hopefull but those were clearly just a fluke. Tried them again afterwards ... no luck.

I'm beginning to think there might be no software quickfix for this issue.
Anyone willing to prove me wrong ... be my guest; my script is attached too, haven't gone above 1 x 3 yet.
(Just add a line to /etc/rc.local containing the scripts location)

Godspeed

Code:

#!/bin/bash

sleep 1m

RX=$(cat /sys/module/sunxi_gmac/parameters/rx_delay)
TX=$(cat /sys/module/sunxi_gmac/parameters/tx_delay)
tx)



date > /root/r${RX}_t${TX}.txt
ethtool eth0 >> /root/r${RX}_t${TX}.txt
timeout -k 75s 68s iperf  -c 192.168.1.230 -t60 >> /root/r${RX}_t${TX}.txt
timeout -k 75 60s wget --output-document=/dev/null http://192.168.1.230/test.img 2>&1 | grep % >> /root/r${RX}_t${TX}.txt
dmesg | tail -n 30 >> /root/r${RX}_t${TX}.txt
ifconfig eth0 >> /root/r${RX}_t${TX}.txt



if [ $RX -eq 31 ] && [  $TX -eq 7 ]; then
exit 1
fi

if [  $TX -eq 7 ]; then
 TX="0"
 ((RX++))
else
 ((TX++))
fi


# 2806                         tx-delay = <0x1>;   =>0-7
# 2807                         rx-delay = <0x0>;   =>0-31
sed -i '2806s/.*/                         tx-delay = <0x'$(printf "%X" $TX)'>;/' /boot/pine64/sun50i-a64-pine64-plus.dts
sed -i '2807s/.*/                         rx-delay = <0x'$(printf "%X" $RX)'>;/' /boot/pine64/sun50i-a64-pine64-plus.dts
dtc -I dts -O dtb -o /boot/pine64/sun50i-a64-pine64-plus.dtb /boot/pine64/sun50i-a64-pine64-plus.dts
reboot
#echo b > /proc/sysrq-trigger

Needs some explanation from http://forum.pine64.org/showthread.php?t...2#pid16062

[waldo]

ran some more cycles

[waldo]

And had some more fun
r0_t0.txt
r0_t1.txt
r0_t2.txt
r0_t3.txt
r0_t4.txt
r0_t5.txt
r0_t6.txt
r0_t7.txt
r1_t0.txt
r1_t1.txt
r1_t2.txt
r1_t3.txt
r1_t4.txt
r1_t5.txt
r1_t6.txt
r1_t7.txt
r2_t0.txt
r2_t1.txt
r2_t2.txt
r2_t3.txt
r2_t4.txt
r2_t5.txt
r2_t6.txt
r2_t7.txt
r3_t0.txt
r3_t1.txt
r3_t2.txt
r3_t3.txt
r3_t4.txt
r3_t5.txt
r3_t6.txt
r3_t7.txt
r4_t0.txt
r4_t1.txt
r4_t2.txt
r4_t3.txt
r4_t4.txt
r4_t5.txt
r4_t6.txt
r4_t7.txt
r28_t1.txt
r28_t2.txt
r28_t3.txt
r28_t4.txt
r28_t5.txt
r28_t6.txt
r28_t7.txt
r29_t0.txt
r29_t1.txt
r29_t2.txt
r29_t3.txt
r29_t4.txt
r29_t5.txt
r29_t6.txt
r29_t7.txt
r30_t0.txt
r30_t1.txt
r30_t2.txt
r30_t3.txt

there is nothing usefull after r1_t4 it seems ; i'll let it run some more tomorrow ; anyway ... nothing usefull yet

[Coda]

Any update on this? It is a mess to have to wade through some of the longer threads especially the ones that contain bickering.