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

[Bert Beckmann]

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.

[William Hermans]

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 ?

On Fri, Jan 20, 2017 at 3:15 PM, Bert Beckmann <bert...@gmail.com> wrote:

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.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/916e44f5-1ea7-4f12-8a79-8919e3084215%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

change 'dr_mode' to 'otg'

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

Regards,

--
Robert Nelson
https://rcn-ee.com/

[William Hermans]

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 . . .

[Robert Nelson]

On Fri, Jan 20, 2017 at 5:15 PM, William Hermans <yyr...@gmail.com> wrote:
> 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..

[William Hermans]

On Fri, Jan 20, 2017 at 4:20 PM, Robert Nelson <robert...@gmail.com> wrote:
>
> 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,
>
> --
> Robert Nelson
> https://rcn-ee.com/

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.

[Bert Beckmann]

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

[William Hermans]

Bert,

Show us the output of the command:

root@beaglebone:~# ifconfig -a

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/8be4b8ee-bd5f-484f-8ce4-f170ca53346b%40googlegroups.com.

[Bert Beckmann]

I'm running:

uname -r 

4.4.8-ti-rt-r22

On Friday, January 20, 2017 at 4:04:38 PM UTC-7, Bert Beckmann wrote:

[William Hermans]

On Fri, Jan 20, 2017 at 4:41 PM, Bert Beckmann <bert...@gmail.com> wrote:
>

> 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.

[William Hermans]

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.

[Bert Beckmann]

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)

On Friday, January 20, 2017 at 4:04:38 PM UTC-7, Bert Beckmann wrote:

[William Hermans]

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

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/11dc57f3-12c5-4579-b678-b481cf3f8bdc%40googlegroups.com.

[Bert Beckmann]

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.

On Friday, January 20, 2017 at 4:04:38 PM UTC-7, Bert Beckmann wrote:

[William Hermans]

On Fri, Jan 20, 2017 at 5:20 PM, Bert Beckmann <bert...@gmail.com> wrote:
>
> 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.

[William Hermans]

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.

[William Hermans]

On Fri, Jan 20, 2017 at 5:30 PM, William Hermans <yyr...@gmail.com> wrote:

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.

[Bert Beckmann]

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.

On Friday, January 20, 2017 at 4:04:38 PM UTC-7, Bert Beckmann wrote:

[Bert Beckmann]

SUCCESS!

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

:)

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

Thanks very much to both of you

On Friday, January 20, 2017 at 4:04:38 PM UTC-7, Bert Beckmann wrote:

[William Hermans]

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 ;)

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/a8ddf915-5a0a-46c3-a75e-81a062e05b3b%40googlegroups.com.