[U-Boot] regarding u-boot ethernet support for TFTP boot in Banana pi R1 (Lamobo R1)
Dear all,
I've successfully compiled and running u-boot on the Bananapi R1 board using the instructions in http://linux-sunxi.org/Mainline_U-boot#Compile_U-Boot
This board uses a BCM 53125 ethernet chip
4+1 ports 10/100/1000 Ethernet RJ45 (BCM 53125), WLAN @802.11b/g/n (RTL8192CU) with 2x external antennas connectors
But when I any try to run any NETWORK related command - i'm getting a "No Link". I do have the ip add, gateway addr, net mask etc set as environment variables.
sunxi# ping 192.168.10.1 ethernet@01c50000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@01c50000: No link. ping failed; host 192.168.10.1 is not alive
Could someone help me to understand if the above issue can be fixed by any config changes ?
thanks Ram
-- View this message in context: http://u-boot.10912.n7.nabble.com/regarding-u-boot-ethernet-support-for-TFTP... Sent from the U-Boot mailing list archive at Nabble.com.
Hi,
On 12-08-15 10:26, ramki982 wrote:
Dear all,
I've successfully compiled and running u-boot on the Bananapi R1 board using the instructions in http://linux-sunxi.org/Mainline_U-boot#Compile_U-Boot
This board uses a BCM 53125 ethernet chip
4+1 ports 10/100/1000 Ethernet RJ45 (BCM 53125), WLAN @802.11b/g/n (RTL8192CU) with 2x external antennas connectors
But when I any try to run any NETWORK related command - i'm getting a "No Link". I do have the ip add, gateway addr, net mask etc set as environment variables.
sunxi# ping 192.168.10.1 ethernet@01c50000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@01c50000: No link. ping failed; host 192.168.10.1 is not alive
The problem is that the R1 uses a broadcom switch chip rather then a regular ethernet phy, and neither u-boot nor the upstream kernel has support for this switch chip.
So this is sortof expected behavior. There are kernel patches for adding support for the switch chip in question and people have successfully build upstream kernels with those patches.
It might be interesting to write a small u-boot patch adding support for this switch chip, which simply enables all ports as normal (not part of a vlan) ports.
Even if you only add proper kernel support, u-boot still needs to initialize the gmac, as the kernel does not know how to setup the gmac tx / rx clk delays, ideally someone would write a small kernel gmac clk driver patch to teach the kernel about this.
Regards,
Hans
Thanks for your inputs Hans
I think you are referring to patches like https://github.com/igorpecovnik/lib/blob/next/patch/bananapi-r1-next.patch that add b53 driver support to mainline kernel.
I'll try to start working on it
thanks Ram
On Wed, Aug 12, 2015 at 3:56 PM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 12-08-15 10:26, ramki982 wrote:
Dear all,
I've successfully compiled and running u-boot on the Bananapi R1 board using the instructions in http://linux-sunxi.org/Mainline_U-boot#Compile_U-Boot
This board uses a BCM 53125 ethernet chip
4+1 ports 10/100/1000 Ethernet RJ45 (BCM 53125), WLAN @802.11b/g/n (RTL8192CU) with 2x external antennas connectors
But when I any try to run any NETWORK related command - i'm getting a "No Link". I do have the ip add, gateway addr, net mask etc set as environment variables.
sunxi# ping 192.168.10.1 ethernet@01c50000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@01c50000: No link. ping failed; host 192.168.10.1 is not alive
The problem is that the R1 uses a broadcom switch chip rather then a regular ethernet phy, and neither u-boot nor the upstream kernel has support for this switch chip.
So this is sortof expected behavior. There are kernel patches for adding support for the switch chip in question and people have successfully build upstream kernels with those patches.
It might be interesting to write a small u-boot patch adding support for this switch chip, which simply enables all ports as normal (not part of a vlan) ports.
Even if you only add proper kernel support, u-boot still needs to initialize the gmac, as the kernel does not know how to setup the gmac tx / rx clk delays, ideally someone would write a small kernel gmac clk driver patch to teach the kernel about this.
Regards,
Hans
participants (3)
-
Hans de Goede -
Ramakrishnan Meenakshi Sundaram -
ramki982