USB Configfs in Device Tree

Shreyas · April 2, 2021, 2:36pm

I would like to know what exactly is the below stated is trying to convey.

To speed up the boot process by configuring USB statically in the device tree instead of it being conventionally done through a script at boot time.
Goal: USB configfs in device tree such that they can be configured statically in device tree ahead of boot and speed the boot process.

Link - BeagleBoard/GSoC/Ideas-2021 - eLinux.org

My Doubt - What is the meaning of USB configfs ? I haven’t came across such terminology. I know device trees are useful in configuration of non-discoverable peripherals on the board but what has configfs have to do with it? Now that combined with USB configfs is really confusing.

Past Discussion - [GSoC 2019 Project Proposal] USB configFS in device tree - #3 by jmarek

RobertCNelson · April 2, 2021, 2:48pm

So, configfs is pretty cool, ram based filesystem with sysfs’s functionality…

https://www.kernel.org/doc/Documentation/filesystems/configfs/configfs.txt

When we load libcomposite on bootup, and setup our USB gadget driver thru “configfs”, you’ll notice it’s a very similar structure layout to something that “could be” easily done in a device-tree. So the idea with this GSOC project, is to create a device-tree node that could specify the USB gadget thru libcomposite on bootup. Thus users of USB gadget wouldn’t have to rely on custom boot scripts or libusbgX…

Regards,

Shreyas · April 2, 2021, 2:51pm

That clears a lot of doubts. Thank You for the swift reply.

RobertCNelson · April 2, 2021, 2:52pm

PS, here is our messy boot script:

github.com

RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh#L414-L526


		else
			echo "${log} Creating g_multi"
			mkdir -p /sys/kernel/config/usb_gadget/g_multi || true
			cd /sys/kernel/config/usb_gadget/g_multi

			echo ${usb_bcdUSB} > bcdUSB
			echo ${usb_idVendor} > idVendor # Linux Foundation
			echo ${usb_idProduct} > idProduct # Multifunction Composite Gadget
			echo ${usb_bcdDevice} > bcdDevice

			#0x409 = english strings...
			mkdir -p strings/0x409

			echo ${usb_iserialnumber} > strings/0x409/serialnumber
			echo ${usb_imanufacturer} > strings/0x409/manufacturer
			echo ${usb_iproduct} > strings/0x409/product

			mkdir -p configs/c.1/strings/0x409
			echo "BeagleBone Composite" > configs/c.1/strings/0x409/configuration

This file has been truncated. show original

The idea, would be to create a device-tree that does that exact same procedure.

Regards,

dlech · April 2, 2021, 3:48pm

FYI, Device Tree is for describing the hardware, not for configuration (so implementing this using device tree would probably not be accepted in the mainline Linux kernel). I would suggest looking at Boot Configuration — The Linux Kernel documentation instead of device tree.

Shreyas · April 2, 2021, 6:46pm

I have went through both the suggestions. I agree with @dlech (Being a newbie all I did was to go through articles and docs and the statement fits) that Device trees are not intended for configuration. However in this case of adding the USB gadget node , there’s a thin boundary between configuration and description.
For ex. by adding IDs (product and vendor) , I would be describing it whereas while adding strings of function instances I would have been configuring it. (These are a newbie’s thoughts , please correct me wherever I am wrong)
So I might have two things to consider (of course with your suggestions):

To make a dtsi file that contains a generic cdc node as suggested by @RobertCNelson and add more properties to it in the board specific file
To use bootconfig
For the first case I will need to go through device tree bindings and write a generic node and in the board config i would add more properties and values to it.
For the 2nd case , I am unclear of how the key value pairs would be used. If procfs is the solution in this case then there won’t be any difference.