Edited by tkaiser at Mon Apr 6, 2015 13:43 |
Yuri replied at Sat Apr 4, 2015 12:58
I have a BPi R1 with hdd WD Blue 1Gb, Igor's debian and kernel 3.4.106
Please have a look at the 'Fix gmac not working reliable on the Bananapi' thread here: http://lists.denx.de/pipermail/u-boot/2014-September/thread.html#190149
I find it a bit hard to diagnose this issue since I don't have the Lamobo R1 (BPi R1) and reports as well as test results one can find on the net are often inaccurate/misleading.
If the aforementioned issue applies also to the Lamobo R1 (which it should since the Lamobo also uses the A20's GMAC implementation but a different PHY in form of the directly connected port of the embedded BCM53125 switch IC) then it might be necessary to either use a patched kernel 3.4 to get good throughput between SoC and switch or to use mainline kernel with appropriate u-boot that pokes these gmac clk register bits.
To test what's going on one has to understand how the two pieces of silicone interact and in which situation the problem applies and when not (eg. switch traffic between the ports of the BCM53125). Some people report that only packets sent from the Lamobo R1 to somewhere else is slow and that the other direction is ok.
Anyway. Recent u-boot versions of OpenWRT contain a patch for board/sunxi/gmac.c:
And they add in configs/Lamobo_R1_defconfig: Copy the Code
- +@@ -34,7 +34,7 @@ int sunxi_gmac_initialize(bd_t *bis)
- + * need to set bits 10-12 GTXDC "GMAC Transmit Clock Delay Chain"
- + * of the GMAC clk register to 3.
- + */
- +-#ifdef CONFIG_TARGET_BANANAPI
- ++#ifdef CONFIG_SUNXI_GMAC_TX_DELAY_3
- + setbits_le32(&ccm->gmac_clk_cfg, 0x3 << 10);
- + #endif
If these 'gmac clk register' are highly board specific then why should a setting for the Banana Pi match the situation on the Lamobo R1? As far as I understand there are two sets of relevant bits: Copy the Code
- bits 5-7, "Configure GMAC receive clock delay chain"
- bits 10-12, "Configure GMAC transmit clock delay chain"
Maybe they've to be adjusted both to avoid clock problems, maybe just tx (bits 10-12). This is something only people owning a Lamobo R1 might be able to answer with tests (if I understood correctly by completely disabling VLANs and just doing iperf in both directions between one capable machine and the router board. The other machine must be able to exceed 935 Mbits/sec against another machine otherwise results might be misleading)