BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

Is this possible? I see that RP zero and RP 3 can do this. I have tried with no luck so far (mini/otg port on one to full USB on the other) and have searched the internet for an example. I see that the mini ports come up as usb/ethernet/device ports - can they be connect together? Or how to we get the full USB port to act as a host and also act as ethernet device? This would be very useful.

This should just work. However, you should be aware this technically is not peer to peer OTG. This is one OTG to host USB. Anyway, this should be no different than connecting a beaglebone to an x86 PC. With the obvious architecture difference as an exception. When you have both connected together what does lsusb tell you ?

change 'dr_mode' to 'otg'

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-bone-common.dtsi#L208-L211

Regards,

Something that does come to mind is that there is a service that runs a set of “generic” scripts at boot. One of these scripts does attempt to run g_ether , or perhaps g_multi on the USB OTG interface. This kernel module I believe is not the same as the as the host kernel module that would have to run on the host board. It’s been a while since I’ve messed with all this though . . .

The whole musb/otg setup is just weird..

I revisited this again last week on the xM, when setting up a
production tester..

To use the port as a host, and plug in a (usb flash drive for
example), you need to modprobe one of the gadget drivers (g_ether for
example).. then the usb port also comes alive and detects the usb
flash disk..

A trick I use to do on the xM, just build-in the g_ether driver, while
you then can't change it later while running, the usb host port always
on kernel bootup..

Regards,

I did some research on this a while back, because I thought it would be
really cool connecting a USB-A cable between two regular computers as a way
to get a peer to peer networking happening. When I read that in order for
this to work, one side *has* to be OTG. Which you kindly pointed out in the
generic board overlay include isn't configured. By default. But anyway, my
point on that is that it's not really an musb / otg issue. But something
that's expected for any g_ether network to function.

If I had the time, I'd dive into the problem full tilt, and see what I
could do to work around that. As far as trying to use peer to peer USN
networking without having to use at least one OTG interface. Which from
what I've read isn't possible, but perhaps I could find a work around. So
for now, like many other potential projects I have in mind . . .back
burner.

thanks for the quick replies

so I need to rebuild the kernel in order to change ‘dr_mode’ to ‘otg’? (it would be much more useful if we didn’t have to do this)

when I boot as is - usb0 comes up ready to network - wouldn’t that mean it’s already setup as otg ?
usb0 Link encap:Ethernet HWaddr 22:87:1a:2a:80:6a

If I do this - do I connect usb mini to usb mini ? or mini to full size usb as I’ve been doing ?

also - why don’t I usb0 or usb1 in /dev? I do see /dev/bus/usb/001 and then /dev/buf/usb/002 when I plug in the 2nd BBB to the full size USB on the first. I assume somewhere I have to assign an ip?
it seems like usb0 and usb1 exist but not as I’d expect

Bert

Bert,

Show us the output of the command:

root@beaglebone:~# ifconfig -a

I’m running:

uname -r
4.4.8-ti-rt-r22

thanks for the quick replies

so I need to rebuild the kernel in order to change 'dr_mode' to 'otg'?

  (it would be much more useful if we didn't have to do this)

when I boot as is - usb0 comes up ready to network - wouldn't that mean

it's already setup as otg ?

    usb0 Link encap:Ethernet HWaddr 22:87:1a:2a:80:6a

If I do this - do I connect usb mini to usb mini ? or mini to full size

usb as I've been doing ?

also - why don't I usb0 or usb1 in /dev? I do see /dev/bus/usb/001 and

then /dev/buf/usb/002 when I plug in the 2nd BBB to the full size USB on
the first. I assume somewhere I have to assign an ip?

it seems like usb0 and usb1 exist but not as I'd expect

Bert

So, you would connect these boards just like you would connect a beaglebone
to a PC. The "client" would be connected to the USB mini, while the "host"
would be connected to the full sized USB port. There is a catch here
however. The "host" Beaglebone would have to be power by the barrel jack,
or through the P9 header with probably a 2A power supply - To be safe. This
is because the "client" will probably want to power it's self over the USB
port. Additionally, if you're going to run more than just the basic
hardware on the client. You're going to need more than 500mA where, I'm not
sure how it works when you have both USB and the barrel jack plugged in at
the same time.

As far as configuring the interface for networking. I always hard coded
this myself in /etc/network/interfaces like so:

PC side:
william@eee-pc:~$ tail /etc/network/interfaces
auto usb0
allow-hotplug usb0
iface usb0 inet static
        address 192.168.7.1
        netmask 255.255.255.0
        network 192.168.7.0
        gateway 192.168.7.1

Then the beaglebone "client" side(USB mini) would be the same, except the
"address" would be 192.168.7.2. Configured this way, there is no need for a
DHCP server on either end.

Honestly, it would be much simpler to just connect the two board together via an ethernet cross over cable if possible. Or, if you have other ideas for the erthernet ports, and you’re comm traffic is light, You could purchase a 3v3 TTL serial to USB cable, and communicate between the two over serial.

so close!

without any kernel changes - I am now seeing usb0 and usb1 in ifconfig on BBB1 when I connect the 2nd BBB to the first (mini to full).
I assign IP’s - I gave 192.168.7.1 to the 2nd BBB.
Maybe netmask / ip #'s are causing problems - will try using .2 and .3 with mask of 255.255.255.0

what happens now — if I ssh to 192.168.7.1 expecting to see my 2nd BBB, I get connected to the BBB I am running on.
so so close!

ah - however - now on the 2nd BBB - no usb0 device shows up. That explains a little. When the cable is connected, the 2nd BBB drops it’s usb0 definition. The 1st BBB get’s usb1 added though.

Maybe Robert’s mod is needed.

Here are the ifconfigs:

BBB1:

root@rib2bbb-08977:~# ifconfig -a

eth0 Link encap:Ethernet HWaddr 80:30:dc:91:16:b5

inet addr:172.28.0.120 Bcast:172.28.0.255 Mask:255.255.255.0

inet6 addr: fe80::8230:dcff:fe91:16b5/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:7500 errors:0 dropped:0 overruns:0 frame:0

TX packets:1464 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:806150 (787.2 KiB) TX bytes:163855 (160.0 KiB)

Interrupt:175

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0

inet6 addr: ::1/128 Scope:Host

UP LOOPBACK RUNNING MTU:65536 Metric:1

RX packets:415 errors:0 dropped:0 overruns:0 frame:0

TX packets:415 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1

RX bytes:41928 (40.9 KiB) TX bytes:41928 (40.9 KiB)

usb0 Link encap:Ethernet HWaddr 3a:a6:6d:9c:15:2d

inet addr:192.168.7.2 Bcast:192.168.7.3 Mask:255.255.255.252

inet6 addr: fe80::38a6:6dff:fe9c:152d/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:10 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

usb1 Link encap:Ethernet HWaddr 9a:2a:76:42:c0:87

inet addr:192.168.7.1 Bcast:192.168.7.3 Mask:255.255.255.252

inet6 addr: fe80::982a:76ff:fe42:c087/64 Scope:Link

UP BROADCAST MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:1 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:0 (0.0 B) TX bytes:90 (90.0 B)

BBB2:

root@rib2bbb-11111:~# ifconfig
eth0 Link encap:Ethernet HWaddr 68:c9:0b:ee:66:c4
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:175

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:452 errors:0 dropped:0 overruns:0 frame:0
TX packets:452 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:36528 (35.6 KiB) TX bytes:36528 (35.6 KiB)

Mask:255.255.255.252

^^ Will be a problem.

This mask means you have the ability to use 3 address, of which one is reserved for the broadcast “IP” Which is not usable by an interface. 192.168.7.0. Which, I’m not a network guru, and I could be remembering incorrectly. You could try loosing that last field from 252 to 251m and see if that works.

In an attempt to fix your multiple USB interfaces on the first BBB try to disable the generic start up service temporarily. This can be done by issuing the command:

systemctl disable generic-board-startup.service

With elevated commands. reboot the board, and try again. If neither interface comes up after a reboot, then you can reenable the service by running:

systemctl enable generic-board-startup.service

using ethernet would be simpler but we need the ethernet ports on each BBB for another purpose (isolated networks).

I think this will work - the host side of things seems to be behaving properly, the client is not and maybe that’s what Robert’s change is for.

This approach also will make for an interesting BBB cluster when the SanCloud EBBB is back on the market and we can USB network 4 BBB’s (1 EBBB + 3 regular BBB’s) with no ethernet switch or hub.

using ethernet would be simpler but we need the ethernet ports on each

BBB for another purpose (isolated networks).

I think this will work - the host side of things seems to be behaving

properly, the client is not and maybe that's what Robert's change is for.

This approach also will make for an interesting BBB cluster when the

SanCloud EBBB is back on the market and we can USB network 4 BBB's (1 EBBB
+ 3 regular BBB's) with no ethernet switch or hub.

Well the good news is that if this does not work out, you can purchase two
USB to ethernet adapters, which should be natively supported ( drivers
already included in the kernel, assuming they were not compiled out ).
Which is to say, I know they exist, I've seen them used, but I've never
used them personally. So you would or should do your own homework on that,
if and when it comes to that. To make sure they will in fact work. I've
been told however, they work pretty good. But again, no personal hands on.

Bert, So it a distinct possibility you’re running into the “wall” that Robert mentioned in his first post. The OTG interface in the device tree board overlay file is configured in peripheral mode. In order to fix that. No you would not need to recompile the kernel( this is one of the great things about device tree overlays ), but you would have to edit, and recompile the device tree board overlay, move the old one out of the way, and replace with the newly created device tree overlay binary. This would however only have to be performed on the client (USB mini ) BBB.

In fact I would say it is the most likely cause for what you're seeing.

I’m on that path now.

I got Robert’s dtb-rebuilder repo, downloaded it, made his change and am using the updated dtb. Of course - usb1 is not showing up now on BBB1. It would show up when I plugged BBB2 into it (it’s full USB to BBB2 mini USB) - now not.

I’ll keep wrestling with it.

SUCCESS!

It works - BBB1 is 192.168.7.2, BBB2 is 192.168.7.3 and I can ssh between the two.

:slight_smile:

Looks like it was Robert’s mod plus getting the IP’s correctly.

Thanks very much to both of you

Awesome. So here is a decent reference for all things USB network related: http://www.linux-usb.org/usbnet/

Which I had forgotten that using USB-A to USB-A cables is electrically unsound. E.g. you can destroy USB equipment using these. The cables I was probably remembering was the USB host-to-host cables mentioned on that page.

Can’t wait for USB3-C “bridge” adapters :wink: