Linux/AM3352: Mounting ROOTFS over USB Ethernet

Richard McAleer

Part Number: AM3352

Tool/software: Linux

I am working on a board closely based on a BeagleBoneBlack (with some functionality removed e.g. there is no hardware ethernet port)

I am at the stage in the project where I need to move from booting from SD card to running from an onboard SPI Nor Flash ROM (freeing the SD card for user data)

as an interim step I would like to run with the rootfs on my host PC
this should avoid the slow erase and reflash cycles required while I implement support for the SD card as a data store.

Therefore I am wondering if there is anyway to mount the root file system over USB ethernet?

Thus far I can both:

use the ethact as usb_ether in u-boot nicely to TFTP data to the board
use the g_ether driver (when booting from SD card) to mount remote folders for access to my application for testing and update

What I am unable to work out is how I might handover from one to the other (the g_ether driver is a module in the filesystem so there's a chicken-v-egg scenario)

Any advice or suggestions would be gratefully received.

Best regards,

- Richard

over 7 years ago

0 Bin Liu over 7 years ago

TI__Guru**** 174281 points

Richard,

Yes, it is possible to use kernel g_ether driver to make the usb peripheral port as a ethernet port.
1. Please ensure to use the latest Processor SDK Linux to avoid any known usb issues;
2. First boot from SD card and validate the usb function has no issue, and you can use common network functions with g_ether module;
3. Rebuild kernel to config all usb drivers, including g_ether into kernel zImage, so that usb is functional before mounting the rootfs.
4. Better to set "g_ether.host_addr=<mac-address>" in your u-boot bootargs to get consistent mac address for your usb ethernet port.

0 Richard McAleer over 7 years ago in reply to Bin Liu

Expert 1485 points

Thanks Bin

that sounds like a good way to go!

I may need to bump my SDK whick is at 04.01 at the moment
it's actually g_multi that is being used as a driver; presumably the principles are the same

I take it for identifying the modues to include within the kernel I should be looking at the loaded list (apologies for the for formatting but it's a very small FS and it's using BusyBox for as much as it can)

e.g

root@elle-board:~# lsmod
Not tainted
usb_f_acm 7581 1 - Live 0xbf096000
u_serial 13121 1 usb_f_acm, Live 0xbf08e000
usb_f_ecm 10206 1 - Live 0xbf087000
g_multi 6145 0 - Live 0xbf081000
usb_f_rndis 21599 2 g_multi, Live 0xbf076000
usb_f_mass_storage 40880 2 g_multi, Live 0xbf066000
u_ether 13192 3 usb_f_ecm,g_multi,usb_f_rndis, Live 0xbf05e000
libcomposite 46333 5 usb_f_acm,usb_f_ecm,g_multi,usb_f_rndis,usb_f_mass_storage, Live 0xbf04b000
configfs 29509 6 usb_f_acm,usb_f_ecm,usb_f_rndis,usb_f_mass_storage,libcomposite, Live 0xbf03e000
musb_dsps 11981 0 - Live 0xbf037000
musb_hdrc 64303 1 musb_dsps, Live 0xbf020000
udc_core 17043 8 usb_f_acm,u_serial,usb_f_ecm,usb_f_rndis,usb_f_mass_storage,u_ether,libcomposite,musb_hdrc, Live 0xbf016000
phy_am335x 2372 1 - Live 0xbf012000
phy_generic 5525 1 phy_am335x, Live 0xbf00d000
usb_common 4236 5 libcomposite,musb_dsps,musb_hdrc,udc_core,phy_am335x, Live 0xbf008000
phy_am335x_control 2873 1 phy_am335x, Live 0xbf004000
musb_am335x 1426 0 [permanent], Live 0xbf000000

and that those should go in to the kernel

That leaves the question of what takes over the role of the gadget.sh in this case?

At present the script I use is from the SDK:

root@elle-board:/etc/init.d# cat gadget.sh 
#!/bin/sh

# Based off:
# github.com/.../am335x_evm.sh

# Assume some defaults
SERIAL_NUMBER="1234BBBK5678"
PRODUCT="am335x_evm"
manufacturer="ti.com"

# Read serial numberfrom the eerpom
eeprom="/sys/bus/i2c/devices/0-0050/eeprom"
if [ -f ${eeprom} ] ; then
    SERIAL_NUMBER=$(hexdump -e '8/1 "%c"' ${eeprom} -n 28 | cut -b 17-28)
    PRODUCT="BeagleBoneBlack"
    manufacturer="BeagleBoard.org"
fi

echo "SERIAL_NUMBER = ${SERIAL_NUMBER}"
echo "PRODUCT = ${PRODUCT}"


mac_address="/proc/device-tree/ocp/ethernet@4a100000/slave@4a100300/mac-address"
[ -r "$mac_address" ] || exit 0

host_addr=$(/usr/bin/hexdump -v -e '5/1 "%02X:" 1/1 "%02X"' "$mac_address")
echo "host_addr = ${host_addr}"

# Set the g_multi parameters
g_defaults="cdrom=0 ro=1 stall=0 removable=1 nofua=1"

g_product="iSerialNumber=${SERIAL_NUMBER} iManufacturer=${manufacturer} iProduct=${PRODUCT}"

g_network="host_addr=${host_addr}"

g_storage="file=/dev/mmcblk0p1"

modprobe g_multi ${g_storage} ${g_defaults} ${g_product} ${g_network}

# Bring up the USB network interface
ifup usb0

is it just a case of incorporating the arguments passed to g_multi via modprobe in to the bootargs from u-boot?

e.g g_multi.host_addr=XXXX g_multi.file=/dev/XXXX

Thanks greatly for the assistance

Best regards,

Richard

0 Bin Liu over 7 years ago in reply to Richard McAleer

TI__Guru**** 174281 points

Richard,

Richard McAleer said:

I take it for identifying the modues to include within the kernel I should be looking at the loaded list

......

and that those should go in to the kernel

Yes, but it is not that much work as it looks like. Some of the gadget function modules will be built in automatically once the g_multi gadget driver is configured built in.

The following wiki explain what modules are related. Hope it helps.

Richard McAleer said:

is it just a case of incorporating the arguments passed to g_multi via modprobe in to the bootargs from u-boot?

e.g g_multi.host_addr=XXXX g_multi.file=/dev/XXXX

I would think so.

Once thing to note is that - as mentioned in the wiki referred above, build-in usb gadget driver used to be broken due to cppi_dma driver is probed later than musb driver. I am not sure if it is still the case in the current kernel. I haven't tested built in gadget for a while.

If it is still broken, you have two options to solve it:

- disable CPPI DMA if ~40mbps usb throughput meets your requirement;

- modify dts to move the CPPI dt node above musb and the phy nodes.

Processors

Processors forum

Linux/AM3352: Mounting ROOTFS over USB Ethernet