Small follow-up: I'm refering to GMAC send/receive clock delay chain. For Banana Pi/Pro it was necessary to set bit 10-12 of the gmac clk register to 3 to get decent network throughput (for Cubietruck it's set to 1 currently).
http://lists.denx.de/pipermail/u-boot/2014-September/190239.html This is done in u-boot: http://lists.denx.de/pipermail/u-boot/2015-January/202590.html Since this is a very board specific value to compensate for trace lengths on the PCB (see explanation above) I had doubts that using also 3 on the Lamobo R1 (which has a totally different PCB and uses a different PHY than Banana Pi/Pro) would make any sense. Igor tried a few other values (2,4,5,6,7,9,12) and came up with 4 giving better results. So now he sets "CONFIG_GMAC_TX_DELAY=4" https://github.com/igorpecovnik/lib/blob/next/patch/add-lamobo-r1-uboot.patch If I have the time I will set up an unattended test setup and brute-force through all possible values of CONFIG_GMAC_TX_DELAY and also CONFIG_GMAC_RX_DELAY (why shouldn't the other direction not also be affected? This is what we have right now with all A20 boards: asymmetric throughput). With mainline kernel and adjusted SMP, network and cpufreq settings (also due to patched U-boot) I managed to get 940 Mbits/sec RX and 670 Mbits/sec TX: http://forum.lemaker.org/thread-12167-1-1-nas_performance_with_kernel_3_19_0.html This is what I want to achieve on the Lamobo R1 as well and try to reach 940 Mbits/sec TX on Banana Pi/Pro. But no idea whether the idea to set CONFIG_GMAC_RX_DELAY will work since code for this value in board/sunxi/gmac.c seems to be missing (and unfortunately I'm no coder) -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
