can i run my BBB with full networking and NFS rootfs entirely off USB tether?

has anyone configured a BBB and dev host so that the BBB can run
entirely off nothing but USB tether yet still support, all at the same

  * ssh logins (obviously, since it does so already)
  * net access to outside world (again, not hard using NAT on dev
  * NFS mount rootfs over USB tether

that last one's the tricky part, of course, and i can see an alleged
recipe here:

but before i go running off trying that, has anyone else done this and
can confirm whether or not it works? thanks.


According to this;a=blob;f=include/configs/am335x_evm.h;hb=HEAD#l57 and searching through the file for “USB” there are several references to USB_GADGET so it looks like it may be supported.

I have wondered if this will work myself, but quite honestly stopped worrying so much after I got NFS rootfs working(Ethernet ).

addressing my own post, i ran across the u-boot setting:

# setenv ethact usb_ether

which struck me as at least a possibility, so i set that and tried
what i figured was a silly test:

# ping

which should be silly since that interface is not yet configured on
the host so i wasn't sure what was going to happen, but here's the

# ping
using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
MAC 90:59:af:56:ad:71
HOST MAC de:ad:be:af:00:00
RNDIS ready
musb-hdrc: peripheral reset irq lost!
data abort

    MAYBE you should read doc/README.arm-unaligned-accesses

pc : [<9f380ad0>] lr : [<9f385b3c>]
sp : 9f238d48 ip : 00000209 fp : 00000002
r10: 00000000 r9 : 9f23e634 r8 : 9f238f40
r7 : 00000009 r6 : 9f2396f8 r5 : 9ffbc84d r4 : 9ffbc84d
r3 : 9f3acaa4 r2 : 00000100 r1 : 9ffbc84d r0 : 9f3aca30
Flags: nzCv IRQs off FIQs on Mode SVC_32
Resetting CPU ...

resetting ...

  it seems like it was at least *trying* to activate that interface
but i don't know what to do about the rest of that.

  am i after something that simply isn't supported, at least on the
BBB as it's currently shipped? this has to work on a stock BBB, i
don't have the freedom to rebuild u-boot, at least not at the moment.
(i do have the freedom to tweak the host if that's part of
the solution.)


more information needed. What are the exact steps you took to ping the host ? DId you setup ipaddr ? gatewayip ?

Robert I am willing to help if you need it, and if I can. I know a bit about uEnv.txt env variables, but obviously I dont know everything. Most of my knowledge is by reading whats available on the web, and extensive experimentation.

There are several things that must be done in order to ping an outside address. The two I mentioned above, but also I believe that usb0( as seen by uboot ) must be assigned a MAC address. Then you can either set a static IP, or use DHCP ( if the host has a DHCP server ). Personally I would recommend using static IP’s . . . Also the host IP should be the gateway IP, but if IP tables are used, I suppose the real network gateway IP could then be used.

Just from my experience with setting up network booting over ethernet it wont be easy without information forthcoming from someone who already knows. But if it is what you need/want the time spent on it will definitely be worth it. For whatever it is worth, it took me about a week to setup network booting using PXE and NFS. In my spare time.

i appreciate any help i can get -- i'd love to have this resolved by
the end of today as i'd like to put it to use tomorrow so here's the
quick recap.

  i'm using an absolutely stock BBB A5C fresh from circuitco and, for
reference sake, i posted a copy of the entire env here:

(i formatted the value of "bootcmd" for readability.)

  i also posted on the u-boot list, and one of the regulars assured me
this should work as long as the kernel has everything needed to set up
the RNDIS connection either in-kernel or in a ramdisk so, once again,
the answer to that is based on the kernel as shipped by circuitco.

  i simply don't know enough about RNDIS and how it goes about
establishing the net link over the USB tether during a *normal* boot,
so i don't know what options to add to some of the u-boot commands.

  a wild-ass guess as to what a uEnv.txt might look like:

uenvcmd=run netargs; run loaduimage; run loadfdt; bootm ${kloadaddr} - ${fdtaddr}

but beyond that, there are all sorts of questions i have no answers

* do i need to specify all of the above?
* do i need to manually bring up the usb0(?) interface?
* do i need to manually configure dhcp from within u-boot?

on the host side, i have ubuntu 12.04 and doing a *normal* boot works
just fine -- i simply have no idea how u-boot works with RNDIS.

  eventually, i'll want to tftp the kernel image as well, so i'll
definitely have to know how to use u-boot to bring up the net

  feel free to suggest ideas, and i'll give them a shot. has
absolutely no one done this already? i would think it would be a
fairly popular approach.


it might help if i describe the context of what i'm trying to do.
imagine a classroom where each student system has exactly one wired
ethernet port, and that's being used to connect to the outside world.
there is no wireless so that's it for standard network connectivity.
that means that *everything* net-related on the BBB has to use the USB

  in addition, there is no access to the serial port of the BBB, so
students have no ability to stop at the U-Boot prompt to do any
customization. the only BBB u-boot customization is through (as best i
can tell) booting the BBB normally the first time, then replacing
uEnv.txt in the FAT partition. that's it, that's your only
possibility, so the entire solution to this has to be represented with
what you can do with a single custom uEnv.txt file that overrides the
one that ships with the BBB.

  and with nothing but that USB tether, i want to be able to TFTP
kernel images, NFS mount a root filesystem and so on, and all of that
on a BBB exactly the way it's shipped from circuitco, connected to,
say, a ubuntu (or fedora) system. obviously, i can tweak the host
system any way i want, but i can only adjust the BBB via the uEnv.txt

  does that make things clearer?


Yeah I did not really need any clarification, just knowing what you want to do is enough for me.

Here is an example uEnv.txt setup that I found on the web for the beagleboard XM:

optargs=mem=80M@0x80000000 mem=384M@0x88000000 xeno_hal.cpufreq=800000000
root=/dev/nfs rw

nfsargs=setenv bootargs console=${console} mpurate=${mpurate} ${optargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${nfsdevice} nfsroot=${serverip}:${rootpath},${nfsrootargs} root=${root}

uenvcmd=echo Initializing net …; dcache off; usb start; echo Loading kernel …; nfs ${loadaddr} ${serverip}:${rootpath}/boot/uImage ; echo Booting from nfs …; run nfsargs; bootm ${loadaddr}

Two possible problems I see with this. 1) “nfsdevice”, no idea if this is supported in the version of uboot used with the BBB. 2) usbethaddr, again same as problem #1. However, you can test this at the uboot prompt. I can not do this personally as I do not have a proper UART module ( I use an MSP430 launchpad at 9600 BAUD ). So I can not properly see the initial boot up sequence text.

The above optargs env variable is not needed for the BBB, and quite possibly would cause the board to not boot. You would also need to set a few things correctly . . . and well here. I wrote up a blog on network booting.

If you have any questions about my setup there, you can ask me in this post if you like. Dont worry about it being about Debian, uEnv.txt setup is / can be exactly the same. That blog is kind of long winded so you may not have to read everything. Mainly just the uEnv.txt settings on there might give you an idea of what is needed.

My settings should almost work as is, but of course the network adapter would need to be different. Let me know if you get it to work.

Sorry, from the example above:

mpurate=800 is not needed and . …

console=ttyO2,115200n8 should probably be console=ttyO0,115200n8. It really depends on if you want the Serial debug to act as your serial connection interface to the BBB I guess.

Also for added clarity optargs=mem=80M@0x80000000 mem=384M@0x88000000 xeno_hal.cpufreq=800000000 is wrong for our device.

We also need to load the device tree blob for the AM3559 / beaglebone black, but I outline that in my blog.

i'm teaching all this week so i'm going to have limited time to test
this but i'll do my best. i appreciate all the assistance, thanks. of
course, if anyone else wants to check this out, by all means, go wild.


Ok, just some information.

After toying with usbnet / g_ether, using virtualbox and mapping the RNDIS Windows driver to a “physical” GbE device from within virtualbox. I have to say the performance is substandard. A full MB/s less than the actual ethernet device on the BBB. ( 9.6MB/s throughput ).

When using the RNDIS driver from within windows and using SMB to pick up an NTFS share . . . it is far worse at 55KB/s throughput. I am told by someone i know on IRC this has to do with current NTFS support, but yeah either way totally unacceptable.

So Robert here is the deal as I see it. Booting from usbnet is a no go. rootfs from usbnet should be possible, with the g_ether module statically compiled into the kernel. Performance would take a slight hit assuming it performed as well as the virtualized RNDIS driver passed through windows into a virtual machine as a GbE device. With that said, I am betting that Microsoft in their infinite wisdom is bogging things down some ( as I have read on the internet ). So perhaps g_ether<->usbnet would perform better from Linux to Linux. However I am still dubious on that statement as the “article” I read was obviously written by a Linux zealot ( blaming MS for every_single_problem a Linux developer could possibly have writing drivers for Windows ).

Anyway, whatever the case, I personally am a bit turned off the the results so far. As my own motivation was purely based on performance. Perhaps it would be best to use that single ethernet connection. connect to the BBB, and setup IP masquerading over usbnet to allow the bbb, and PC to have access to the internet ? Kind of a warped and twisted solution I know, but it is the only solution that I can currently think of that may give you what you need / want.