Jump to content

g_ether on H3 with mainline


Sean Carson

Recommended Posts

IIRC it should be working on legacy while on mainline it is not implemented yet or buggy. I hope someone else could provide more info on the issue.

Link to comment
Share on other sites

I am having a problem and I really don't know if this is my fault or if could be a problem with mainline.

 

My current version is:

 

Linux orangepizero 4.11.5-sun8i #11 SMP Fri Jun 23 20:03:23 CEST 2017 armv7l armv7l armv7l GNU/Linux

I have been fighting with g_ether on an OPIZero as slave (OTG mode) connected with another machine HOST USB port, but no matter what I do, it is not possible to make it to work well.

 

Several months ago I was able to connect two OPIZero machines with legacy kernel in both of them.  But now, I need to use another machine (OPIZ+2 H5 or BPI-R2) having 4.4 kernel and it doesn't work.

 

For this I decompiled the dtb file and replaced the "peripheral" with "otg".

Original:

                usb@01c19000 {
                        compatible = "allwinner,sun8i-h3-musb";
                        reg = <0x1c19000 0x400>;
                        clocks = <0x2 0x20>;
                        resets = <0x2 0x11>;
                        interrupts = <0x0 0x47 0x4>;
                        interrupt-names = "mc";
                        phys = <0x11 0x0>;
                        phy-names = "usb";
                        extcon = <0x11 0x0>;
                        status = "okay";
                        dr_mode = "peripheral";
                        linux,phandle = <0x31>;
                        phandle = <0x31>;
                };

New one:

                usb@01c19000 {
                        compatible = "allwinner,sun8i-h3-musb";
                        reg = <0x1c19000 0x400>;
                        clocks = <0x2 0x20>;
                        resets = <0x2 0x11>;
                        interrupts = <0x0 0x47 0x4>;
                        interrupt-names = "mc";
                        phys = <0x11 0x0>;
                        phy-names = "usb";
                        extcon = <0x11 0x0>;
                        status = "okay";
                        dr_mode = "otg";
                        linux,phandle = <0x31>;
                        phandle = <0x31>;
                };

Commented g_serial and added g_ether in the /etc/modules file.

 

Disabled Network-Manager, installed Avahi in both machines.

 

Added the following in /etc/network/interfaces file.

iface usb0 inet manual
        up /usr/sbin/avahi-autoipd --force-bind -D $IFACE
        down /usr/sbin/avahi-autoipd --kill $IFACE

And bring usb0 to life with  ifup usb0.

 

When I try to ping from the OPIZero to the other machine the ping fails, but tcpdump receives "something" in the destination side (the HOST one):

12:11:42.826864 ff:ff:46:7b:0e:f2 (oui Unknown) > 2e:00:ff:ff:ff:ff (oui Unknown), ethertype Unknown (0x8718), length 48: 
	0x0000:  0806 0001 0800 0604 0001 467b 0ef2 8718  ..........F{....
	0x0010:  a9fe 0702 0000 0000 0000 a9fe 04cb dead  ................
	0x0020:  beef  

The OPIZero usb0 port configuration is this one:

usb0      Link encap:Ethernet  HWaddr 46:7b:0e:f2:87:18  
          inet6 addr: fe80::447b:eff:fef2:8718/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:525 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:28094 (28.0 KB)

usb0:avahi Link encap:Ethernet  HWaddr 46:7b:0e:f2:87:18  
          inet addr:169.254.7.2  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

As can be seen, the source address is shifted 16 bits (the 0x8718 type it is really part of the source hardware address).

To check if the destination was the problem, I connected a Raspberry Pi Zero machine with Raspbian configured as OTG and worked without any issue, and tested the HOST side with Armbian on OPIZ+2H5 and Ubuntu on RPI-R2 with the same result in both, so "I think" that the problem is with the Armbian in the OPIZero.

 

 

Link to comment
Share on other sites

13 minutes ago, malvcr said:

I think" that the problem is with the Armbian in the OPIZero.


The problem is you not reading the warning text. Mainline kernel for Opi zero is under development and features that you want to use does not exist at all

 

Link to comment
Share on other sites

No no, I understand it.  I was trying with the Mainline because the last Legacy version has the same behavior (my mistake for not to say it, I'm sorry).

 

I made this to work several months ago with complex scenarios involving several Zero machines, and let it at one side for a while because I was making other things.  When I returned to this part using a recent Legacy update this didn't work.  I thought that was my mistake, but these days I have been returning to work on this and really it doesn't work with Mainline neither with Legacy.

 

At least you are giving me a confirmation.  I can't use the OPIZ+2H5 in this moment for any serious task ... I will wait, and if I can help some way let me know.

 

Thanks

Link to comment
Share on other sites

28 minutes ago, malvcr said:

I can't use the OPIZ+2H5 in this moment for any serious task ...


You can check latest 4.13 kernel if there is any progress in this area. It's accessible from a beta repository.

Link to comment
Share on other sites

I added the beta repository and updated there ... not yet on 4.13 but 4.11.12 ... and with just this change, several packages didn't arrive "officially" to the HOST machine arrived corrupted but with the OTG machine name an other data ... still doesn't work, but it is different than previous versions.  This shows that it is different inside (it is evolving).

 

Then I went to check 4.14 rc3 repository on the Kernel.org original place for all distributions and found this notice there:

 

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/musb/musb_core.c

 

Quote

* This consists of a Host Controller Driver (HCD) and a peripheral * controller driver implementing the "Gadget" API; OTG support is * in the works. These are normal Linux-USB controller drivers which * use IRQs and have no dedicated thread.

 

I think this is not ready, and this is why g_ether is still there although marked as "legacy".  Could be possible that "musb" and "g_ether" are working one against the other?  The problem with the dtb file is that everything is very interleaved.  I will try to disable musb to see if this makes any difference.  Although I also will try to find another solution "without" the gadget part until this to be officially ready.

 

Link to comment
Share on other sites

To get current 4.13 you need to switch to NEXT branch. Check "alternative kernels" in armbian-config or download it manually from beta.armbian.com together with dtb package.

Wrote on mobile

Link to comment
Share on other sites

Same behavior.

 

I decided to follow a different path for my current need (no OTG-HOST) ... but as a side project I will continue checking what is the reason this happens.  When I have it working I will return with my findings.

 

What worries me is the lack of parameters; where is defined how to work the packages structure?  However, this is not Armbian decision but Linux one (the people that are creating that infrastructure part in the kernel core).  Let me see if I can design a different way to do that type of connection, without musb neither g_ether.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines