Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

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

[beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

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: > > Is this possible? I see

[beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

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

[beagleboard] Syntax highlighter for pasm in Sublime Text 3

I'm programming the BBB's PRU in pasm. Does anyone know how I can get Sublime Text to color the code (syntax highlight)? I cross-posted here: http://stackoverflow.com/questions/41774562/pasm-syntax-highlighting-in-sublime-text-3 Thanks. -Justin -- For more options, visit

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

On Fri, Jan 20, 2017 at 5:30 PM, William Hermans 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

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

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

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

On Fri, Jan 20, 2017 at 5:20 PM, Bert Beckmann 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

[beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

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

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

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

[beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

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

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

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

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

On Fri, Jan 20, 2017 at 4:41 PM, Bert Beckmann 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

[beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

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

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

Bert, Show us the output of the command: *root@beaglebone:~#* ifconfig -a On Fri, Jan 20, 2017 at 4:41 PM, Bert Beckmann 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

[beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

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

Re: [beagleboard] BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

On Fri, Jan 20, 2017 at 4:20 PM, Robert Nelson 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

Re: [beagleboard] BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

On Fri, Jan 20, 2017 at 5:15 PM, William Hermans 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

Re: [beagleboard] BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

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

Re: [beagleboard] BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

On Fri, Jan 20, 2017 at 4:15 PM, Bert Beckmann 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

Re: [beagleboard] BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

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

[beagleboard] 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

Re: [beagleboard] Debian 8.6 IoT and BeagleBone Green HDMI Cape

I'm not sure exactly what monitor it is, it's one of the 7" touchscreens from adafruit. Its mounted and I can see any identifying marks on it. In messing with it and trying another monitor, it has now stopped working. When it was working it was very fuzzy, but at least let me watch the boot

Re: [beagleboard] Debian 8.6 IoT and BeagleBone Green HDMI Cape

On Fri, Jan 20, 2017 at 12:30 PM, Matrioux wrote: > > That did it, my kernel was a few versions behind. Thanks! Sweet!! BTW, what model monitor/lcd are you using??? I need to find "one" that works first, before i break too many things while fixing the driver.. Regards, --

Re: [beagleboard] Debian 8.6 IoT and BeagleBone Green HDMI Cape

That did it, my kernel was a few versions behind. Thanks! On Friday, January 20, 2017 at 11:37:59 AM UTC-5, RobertCNelson wrote: > > On Fri, Jan 20, 2017 at 9:41 AM, Matrioux > wrote: > > > > I'm running the 8.6 debian IoT image on the BBGW and the HDMI cape > doesn't

Re: [beagleboard] Debian 8.6 IoT and BeagleBone Green HDMI Cape

On Fri, Jan 20, 2017 at 9:41 AM, Matrioux wrote: > > I'm running the 8.6 debian IoT image on the BBGW and the HDMI cape doesn't > seem to work, I'm not even seeing it on the i2c bus. Is there a package I > need to install for it to function? Make sure you are running:

[beagleboard] Debian 8.6 IoT and BeagleBone Green HDMI Cape

I'm running the 8.6 debian IoT image on the BBGW and the HDMI cape doesn't seem to work, I'm not even seeing it on the i2c bus. Is there a package I need to install for it to function? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are

[beagleboard] Re: Which script allocates /var/swap.img on second boot?

And of course swap is set up by one of our ansible configuration scripts which I didn't grep out initially. Sorry for the confusion. Robert's images don't install swap. -- Kind regards, Tarmo Kuuse On Friday, January 20, 2017 at 10:53:22 AM UTC+2, Tarmo Kuuse wrote: > > It turns out that

[beagleboard] Re: Which script allocates /var/swap.img on second boot?

It turns out that systemd is configured to maintain a swap file. This is what I did to make it stop: List systemd-s swap units: $ sudo systemctl --type swap Disable a swap unit named "var-swap.img.swap": $ sudo systemctl mask var-swap.img.swap -- Kind regards, Tarmo Kuuse On Thursday,

Re: [beagleboard] How to tell the cape-manager to load BB-BONE-LCD4-01 in a slot without using an eeprom

Hello Robert, Thank you for your reply, I have repeated this test, with "dmesg | tail" (see below and complete dmesg as attachment). With no capes attached* I echo echo BB-BONE-LCD4-01 to the slots, this does not work as I would expect, then I echo BB-UART1 to the slots and this seems to