hcf
Still Fresh
While they are still fresh in my mind, I wanted to share some things that occurred to me after the recent g_serial.ko and g_ether.ko bits.
1) The LF1000 driver can only have one USB gadget attached to it. I think this is actually true of USB gadget hardware and device drivers in general. The thing is USB permits a client to emit up to 16 endpoint addresses (16 addresses in, 16 addresses out), so there's no /USB/ limitation that you couldn't run, say, a serial device, ethernet, and block driver all in parallel. I think this is a Linux gadget architectural issue; the gadget driver (g_ether, g_serial) assigns itself the endpoint addresses and takes charge of sending the entire set of configuration blocks. What's needed instead is an "attaching point driver" that assigns endpoint addresses to device drivers as they are attached. A slightly easier, but less dynamic method would be to manually merge the modules you're interested into one gadget. That might be a good step as a proof of concept.
So, for the forseeable future, and not without a lot of work, we're limited to one gadget driver at a time.
2) In some thread, someone thought it was really unusual that GPH presented a "vfat.img" for the NAND device, even though they had clearly mounted a filesystem on the NAND device in question, they're using a loop device to mount the vfat image. My understanding is that the NAND "ubi" driver has special needs because of the nature of NAND flash (for one thing, the 'ubi' device is not a block device), so you must use "ubifs" on the raw ubi flash. Meanwhile the USB Gadget way of exposing a drive via USB is by block device, and it is assumed that block device will present a FAT filesystem (so any host can mount the block device). There isn't a "filesystem" extension USB gadget, and I'm not sure there is even a standard USB method that works at that layer. So the ubifs filesystem carries a vfat.img file, which is loop mounted to access the NAND, and the USB gadget is invoked to treat the file like a block device.
In summary this is all basically a workaround for NAND flash's special needs.
1) The LF1000 driver can only have one USB gadget attached to it. I think this is actually true of USB gadget hardware and device drivers in general. The thing is USB permits a client to emit up to 16 endpoint addresses (16 addresses in, 16 addresses out), so there's no /USB/ limitation that you couldn't run, say, a serial device, ethernet, and block driver all in parallel. I think this is a Linux gadget architectural issue; the gadget driver (g_ether, g_serial) assigns itself the endpoint addresses and takes charge of sending the entire set of configuration blocks. What's needed instead is an "attaching point driver" that assigns endpoint addresses to device drivers as they are attached. A slightly easier, but less dynamic method would be to manually merge the modules you're interested into one gadget. That might be a good step as a proof of concept.
So, for the forseeable future, and not without a lot of work, we're limited to one gadget driver at a time.
2) In some thread, someone thought it was really unusual that GPH presented a "vfat.img" for the NAND device, even though they had clearly mounted a filesystem on the NAND device in question, they're using a loop device to mount the vfat image. My understanding is that the NAND "ubi" driver has special needs because of the nature of NAND flash (for one thing, the 'ubi' device is not a block device), so you must use "ubifs" on the raw ubi flash. Meanwhile the USB Gadget way of exposing a drive via USB is by block device, and it is assumed that block device will present a FAT filesystem (so any host can mount the block device). There isn't a "filesystem" extension USB gadget, and I'm not sure there is even a standard USB method that works at that layer. So the ubifs filesystem carries a vfat.img file, which is loop mounted to access the NAND, and the USB gadget is invoked to treat the file like a block device.
In summary this is all basically a workaround for NAND flash's special needs.