is there a recent (2G) BBB debian SD card image with usb gadget networking?

i'm probably just missing the painfully obvious, but is there an
up-to-date debian BBB 2G SD card image that automatically brings up
the USB gadget networking (192.168.7.1/192.168.7.2)?

  i have an old BBB (A5C) with a 2013 cloud9 image in eMMC, and it
starts USB networking automatically with my desktop fedora system. i
grabbed a recent SD card image:

  bone-debian-7.8-console-armhf-2015-03-01-2gb.img.xz

which boots off of SD card fine, but is not set up for USB networking.
i can see the instructions on how to set that up here:

https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-usbgadget

but is there another image that already has that enabled? thanks.

rday

Well, this one:

https://rcn-ee.com/rootfs/bb.org/release/2015-03-01/lxde/BBB-eMMC-flasher-debian-7.8-lxde-armhf-2015-03-01-2gb.img.xz

Just make sure to "disable" the autoflasher, aka reverse this:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flashing_eMMC

Regards,

>
> i'm probably just missing the painfully obvious, but is there an
> up-to-date debian BBB 2G SD card image that automatically brings up
> the USB gadget networking (192.168.7.1/192.168.7.2)?

Well, this one:

https://rcn-ee.com/rootfs/bb.org/release/2015-03-01/lxde/BBB-eMMC-flasher-debian-7.8-lxde-armhf-2015-03-01-2gb.img.xz

  ah, perfect ... i suspected one of the more functional images had
this, i just didn't know which one. accompanying question -- should i
have known that, or is there a note somewhere about that distinction
between images?

Just make sure to "disable" the autoflasher, aka reverse this:

Beagleboard:BeagleBoneBlack Debian - eLinux.org

  oh, that part i'm familiar with.

rday

I don't really spell it out anywhere.

Just the big difference between the 4gb/2gb "lxde" images and the 2gb
"console" image is:

lxde = g_multi
console = g_ether

where as g_ether doesn't work as nicely as g_multi, but i do get
usb0/ethX link to show up on my debian workstation.

The only way to "properly" switch the console back to using g_multi
correcly, would be to add the extra 100Mb fat partition (which the
lxde images have by default). But the point of the console, was
something small users can build off of, so that would be a waste..

Regards,

that's fine, this is perfect.

rday

>
>> >
>> > i'm probably just missing the painfully obvious, but is there an
>> > up-to-date debian BBB 2G SD card image that automatically brings up
>> > the USB gadget networking (192.168.7.1/192.168.7.2)?
>>
>> Well, this one:
>>
>> https://rcn-ee.com/rootfs/bb.org/release/2015-03-01/lxde/BBB-eMMC-flasher-debian-7.8-lxde-armhf-2015-03-01-2gb.img.xz
>
> ah, perfect ... i suspected one of the more functional images had
> this, i just didn't know which one. accompanying question -- should i
> have known that, or is there a note somewhere about that distinction
> between images?

I don't really spell it out anywhere.

Just the big difference between the 4gb/2gb "lxde" images and the 2gb
"console" image is:

lxde = g_multi
console = g_ether

where as g_ether doesn't work as nicely as g_multi, but i do get
usb0/ethX link to show up on my debian workstation.

  hmmmm ... doesn't work on my fedora rawhide system, so i can at
least look around to see why not, figure out what's missing. no
technical reason g_ether shouldn't work here.

The only way to "properly" switch the console back to using g_multi
correcly, would be to add the extra 100Mb fat partition (which the
lxde images have by default). But the point of the console, was
something small users can build off of, so that would be a waste..

  ok, i *know* i'm going to regret asking this, but i'm not at my dev
host right now so i'll ask ... why would "properly" switching console
back to using g_multi require the re-introduction of the FAT partition
(which i know you like to avoid). why does g_multi depend on that FAT
partition?

rday

Just the big difference between the 4gb/2gb "lxde" images and the 2gb
"console" image is:

lxde = g_multi
console = g_ether

where as g_ether doesn't work as nicely as g_multi, but i do get
usb0/ethX link to show up on my debian workstation.

  hmmmm ... doesn't work on my fedora rawhide system, so i can at
least look around to see why not, figure out what's missing. no
technical reason g_ether shouldn't work here.

The only way to "properly" switch the console back to using g_multi
correcly, would be to add the extra 100Mb fat partition (which the
lxde images have by default). But the point of the console, was
something small users can build off of, so that would be a waste..

  ok, i *know* i'm going to regret asking this, but i'm not at my dev
host right now so i'll ask ... why would "properly" switching console
back to using g_multi require the re-introduction of the FAT partition
(which i know you like to avoid). why does g_multi depend on that FAT
partition?

Yeah, it doesn't depend on "FAT" it just requires a partition..
However if that partition = root partition, in testing we found it
would randomly corrupt things on the root partition.

So it just needs a secondary non-mounted partition.. So to just
properly use g_multi, i'd be forced to waste space on a 2nd partition
in the console's "case"..

I think the better solution is just to figure out why g_ether doesn't
work like g_multi. :wink:

Regards,

>>
>> Just the big difference between the 4gb/2gb "lxde" images and the 2gb
>> "console" image is:
>>
>> lxde = g_multi
>> console = g_ether
>>
>> where as g_ether doesn't work as nicely as g_multi, but i do get
>> usb0/ethX link to show up on my debian workstation.
>
> hmmmm ... doesn't work on my fedora rawhide system, so i can at
> least look around to see why not, figure out what's missing. no
> technical reason g_ether shouldn't work here.
>
>> The only way to "properly" switch the console back to using g_multi
>> correcly, would be to add the extra 100Mb fat partition (which the
>> lxde images have by default). But the point of the console, was
>> something small users can build off of, so that would be a waste..
>
> ok, i *know* i'm going to regret asking this, but i'm not at my dev
> host right now so i'll ask ... why would "properly" switching console
> back to using g_multi require the re-introduction of the FAT partition
> (which i know you like to avoid). why does g_multi depend on that FAT
> partition?

Yeah, it doesn't depend on "FAT" it just requires a partition..
However if that partition = root partition, in testing we found it
would randomly corrupt things on the root partition.

So it just needs a secondary non-mounted partition.. So to just
properly use g_multi, i'd be forced to waste space on a 2nd
partition in the console's "case"..

  um ... what? that's just a bit disturbing, i was unaware of that. so
there's no *actual* necessity for a second partition for g_multi, it's
just to avoid this issue.

I think the better solution is just to figure out why g_ether
doesn't work like g_multi. :wink:

  i agree, i'll dig into that this weekend unless someone solves it
first.

rday

Yeah, it doesn't depend on "FAT" it just requires a partition..
However if that partition = root partition, in testing we found it
would randomly corrupt things on the root partition.

So it just needs a secondary non-mounted partition.. So to just
properly use g_multi, i'd be forced to waste space on a 2nd
partition in the console's "case"..

  um ... what? that's just a bit disturbing, i was unaware of that. so
there's no *actual* necessity for a second partition for g_multi, it's
just to avoid this issue.

I think the better solution is just to figure out why g_ether
doesn't work like g_multi. :wink:

  i agree, i'll dig into that this weekend unless someone solves it
first.

That would be awesome if you had just a free moment, I've gone bald
scratching my head on this issue. :wink:

So far, I've narrowed one of the issues down to "CONFIG_USB_ETH_EEM"
which i've now globally disabled...

Here's how i modprobe the g_multi/g_ether drivers...

Regards,

ok, just so i understand what i want to look at this weekend, let me
make sure i understand the terrain here.

  if i read you correctly, you can connect your console image (which
uses g_ether) to a debian box via USB, and you get networking
automatically, correct? that would be the basic usb0 interface on the
BBB, and 192.168.7.[12], is that right? because if i do exactly the
same thing on my fedora rawhide box (console image), i *don't* get
networking, which suggests some deficiency on the fedora side.

  on the other hand, plugging in the g_multi-based lxde image the same
way on my fedora box works just fine.

  so given some time this weekend, my goal would be to try to identify
why USB networking using g_ether works with debian but fails with
fedora. do i have that right?

rday

Well... Just one other problem... My debian/jessie box is running a
mainline kernel with all modules... So... It "might" be broken for
normal Debian users.. :wink:

From looking at g_multi/g_ether they use most of the same path in
linux, but the vid/pid/manufacture name is different.

Regards,

not worried about that ... what would be useful is a dump from
"udevadm monitor" while plugging in the BBB, to at least see the
uevents to figure out what that would map to.

  and now, i'm off to drink martinis.

rday

  not worried about that ... what would be useful is a dump from
"udevadm monitor" while plugging in the BBB, to at least see the
uevents to figure out what that would map to.

here you go:

  and now, i'm off to drink martinis.

Enjoy Those!

Regards,

I think the better solution is just to figure out why g_ether doesn’t
work like g_multi. :wink:

Two different “host” side drivers. At least with a Windows “host”.

where as g_ether doesn’t work as nicely as g_multi, but i do get
usb0/ethX link to show up on my debian workstation.

@Robert Nelson

Can you elaborate as to what works differently ? Perhaps I can find out whats going on. Or otherwise have some insight on this,

I’ve been using g_ether ( versus g_multi ) exclusively for the last . . . I don’t know, maybe up to a year. Aside from the initial setup hassle, I’ve not had many problems with it. However, the board does connect up to a Debian host, but does run ethernet, and g_ether simultaneously. Initially, I’ve had to manually load the module, until I edit the modules file to include the proper g_ether module reference. then it’s just a matter of editing the interfaces file accordingly.

Oh, I should mention that I set the g_ether IP statically on both sides of the connection.

a quick note on what i've seen on my fedora rawhide box, just to
make sure i'm on the right track. i first plugged in my (A5C) BBB via
serial console and started minicom just so i could track the boot
process -- that seems to work fine. (booting from SD card console
image, just to be clear.)

  i started

$ udevadm monitor

then plugged in the USB cable for networking, and while the board was
booting, i was seeing nothing from udevadm, which i thought was odd.
finally, via minicom, i got a "boot" prompt and, almost immediately
thereafter, this blast from udevadm:

KERNEL[68599.502843] add /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.4 (usb)
KERNEL[68599.503607] add /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.4/4-1.4:1.0 (usb)
KERNEL[68599.504712] add /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.4/4-1.4:1.0/net/eth0 (net)
KERNEL[68599.504763] add /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.4/4-1.4:1.0/net/eth0/queues/rx-0 (queues)
KERNEL[68599.504784] add /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.4/4-1.4:1.0/net/eth0/queues/tx-0 (queues)
KERNEL[68599.505519] add /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.4/4-1.4:1.1 (usb)
KERNEL[68599.559377] move /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.4/4-1.4:1.0/net/enp0s29u1u4 (net)

first observation was ... no module events. in addition, i suddenly
got a corresponding net interface on the fedora box, but with no IP
address:

enp0s29u1u4: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
        ether 90:59:af:4b:3b:8d txqueuelen 1000 (Ethernet)
        RX packets 0 bytes 0 (0.0 B)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 0 bytes 0 (0.0 B)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

  and on the BBB end, no "usb0" interface that i was expecting, just
this:

eth0 Link encap:Ethernet HWaddr 90:59:af:4b:3b:8b
          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:40

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:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

  so, just to be absolutely clear, on your loaded debian box, USB
networking to the BBB works just fine with the stock console image,
and this:

https://gist.github.com/RobertCNelson/50175bfc8f4cb8c521fb

is what you see on the host end as it comes up. at least i know what's
missing and i'll keep poking around.

rday