Caanoo / WIZ Thoughts On Wiz Usb Gadget Interface


hcf

Still Fresh
Joined
Nov 15, 2009
Messages
32
Age
49
Location
Milpitas, CA, USA
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.
 
Actually on early firmwares they had vfat filesystem directly on NAND flash, but fortunately they came to their senses and did what you saw now, else the NAND would have weared down pretty quickly for everyone.
 
notaz said:
Actually on early firmwares they had vfat filesystem directly on NAND flash, but fortunately they came to their senses and did what you saw now, else the NAND would have weared down pretty quickly for everyone.

Probably VFAT directly on the NAND would be a mistake, unless they had implemented a software FTL ("Flash Translation Layer") like is done on PCMCIA flash (or a firmware FTL like is done on some USB flash thumb drives)...then it wouldn't be that different from VFAT-image-on-ubifs-on-NAND; in this sense ubifs is kind of like a filesystem with an integrated FTL (and quite a lot of other benefits, probably performance and especially stability since it seems to be funded by Nokia). A straight FTL might be simpler but I don't know if that software exists or how stable it might be (or if GPH hoped to use space not consumed by vfat.img in some other built-in operations).

Mainly it was just that in some thread (I can't remember) I read someone was implying GPH were not competent for the vfat.img reason; there may be other reasons of course, but this one at least seems to be done correctly on GPH's part.
 
Last edited by a moderator:
hcf said:
notaz said:
Actually on early firmwares they had vfat filesystem directly on NAND flash, but fortunately they came to their senses and did what you saw now, else the NAND would have weared down pretty quickly for everyone.

Probably VFAT directly on the NAND would be a mistake, unless they had implemented a software FTL ("Flash Translation Layer") like is done on PCMCIA flash (or a firmware FTL like is done on some USB flash thumb drives)...then it wouldn't be that different from VFAT-image-on-ubifs-on-NAND; in this sense ubifs is kind of like a filesystem with an integrated FTL (and quite a lot of other benefits, probably performance and especially stability since it seems to be funded by Nokia). A straight FTL might be simpler but I don't know if that software exists or how stable it might be (or if GPH hoped to use space not consumed by vfat.img in some other built-in operations).

Mainly it was just that in some thread (I can't remember) I read someone was implying GPH were not competent for the vfat.img reason; there may be other reasons of course, but this one at least seems to be done correctly on GPH's part.

The vfat image on loopback is still really hacky, especially as it wastes ~100Mb of space, admittedly better than vfat directly on the nand though. Pretty sure the way to do this is vfat on ubiblk on ubi.
 
Last edited by a moderator:
hcf said:
notaz said:
Actually on early firmwares they had vfat filesystem directly on NAND flash, but fortunately they came to their senses and did what you saw now, else the NAND would have weared down pretty quickly for everyone.

Probably VFAT directly on the NAND would be a mistake, unless they had implemented a software FTL ("Flash Translation Layer") like is done on PCMCIA flash (or a firmware FTL like is done on some USB flash thumb drives)...then it wouldn't be that different from VFAT-image-on-ubifs-on-NAND; in this sense ubifs is kind of like a filesystem with an integrated FTL (and quite a lot of other benefits, probably performance and especially stability since it seems to be funded by Nokia). A straight FTL might be simpler but I don't know if that software exists or how stable it might be (or if GPH hoped to use space not consumed by vfat.img in some other built-in operations).

Mainly it was just that in some thread (I can't remember) I read someone was implying GPH were not competent for the vfat.img reason; there may be other reasons of course, but this one at least seems to be done correctly on GPH's part.

The vfat image on loopback is still really hacky, especially as it wastes ~100Mb of space, admittedly better than vfat directly on the nand though. Pretty sure the way to do this is vfat on ubiblk on ubi.
 
Last edited by a moderator:
Back
Top