[U-Boot] usbtty Support on AT91SAM9XXX chipsets
Hi
I am interested in getting usbtty support running on an AT91SAM9G20 board. I have picked up the latest code on the CDC head on the u-boot-usb GIT tree and am currently attempting to get the CDC-Ether support up and running (merging various changes from the 9261 board to the 9260).
However in order to support our factory processes (which are currently set up to use serial ports) we need to use the usbtty framework. I have had a quick go at replacing CONFIG_USG_ETHER with CONFIG_USB_TTY in the config file but it doesn't work. Digging around a bit I think this is due to the following points:
1. usbtty.c uses a global function call based UDC framework (udc_init, udc_endpoint_read|write etc) 2. This framework is implemented on the older UDC devices (omap1510_udc.c, pxa27x_udh.c & mpc8xx_udc.c) but is not implemented on at91_udc.c. 3. drivers/usb/gadget/ether.c uses a new (Linux derived?) USB gadget framework based on registering function tables and accessing via helper functions in gadget.h. 4. at91_udc.c is implemented to this framework.
Hence omap1510, pxa27x & mpc8xx support USB TTY operation and at91 supports ethernet operation but other combinations are not currently possible.
Please could someone advise on the best way forward, initially I can think of a couple of options as follows:
1. create a wrapper that implements the old framework functions (udc_init, udc_endpoint_read|write etc) and simply maps them on to the new framework. 2. import the appropriate TTY gadget implementation from Linux (as for ether.c) and get it working and registered as a proper device.
I suspect 2 is the better option and the way that the project was moving, but I thought I'd check if this was the way to go and whether anyone else had made any progress in this area. Also, if this is the way to go, could someone confirm which version of the Linux Gadget framework ether.c and friends are based on. It appears to be completely different to the latest version.
Cheers
Daniel Sherwood Software Engineer
Sepura PLC
Radio House, St Andrew's Road Cambridge, CB4 1GR, UK T: +44 (0) 1223 694637 F: +44 (0) 1223 879000 www.sepura.com http://www.sepura.com
The information in this email is confidential. It is intended solely for the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution is prohibited and may be unlawful. If you have received this email in error please delete it immediately and contact commercial@sepura.com.
Sepura plc. Registered Office: Radio House, St Andrew’s Road, Cambridge, CB4 1GR, England. Registered in England and Wales. Registration Number 4353801
Hello Daniel,
I am interested in getting usbtty support running on an AT91SAM9G20 board. I have picked up the latest code on the CDC head on the u-boot-usb GIT tree and am currently attempting to get the CDC-Ether support up and running (merging various changes from the 9261 board to the 9260).
Great! If you have patches, please sent them in!
- usbtty.c uses a global function call based UDC framework
(udc_init, udc_endpoint_read|write etc) 2. This framework is implemented on the older UDC devices (omap1510_udc.c, pxa27x_udh.c & mpc8xx_udc.c) but is not implemented on at91_udc.c. 3. drivers/usb/gadget/ether.c uses a new (Linux derived?) USB gadget framework based on registering function tables and accessing via helper functions in gadget.h. 4. at91_udc.c is implemented to this framework.
It is indeed a Linux derived layer for getting USB-CDC going in U-boot. The focus on the port was to get USB-CDC-Ethernet going, not _yet_ supporting serial terminals. A serial console might behave somewhat different. Serial console needs to be up all the time as long as u-boot is active, while the CDC-ethernet connection only when there is network traffic. So, the use of both pieces of code are somewhat different.
Hence omap1510, pxa27x & mpc8xx support USB TTY operation and at91 supports ethernet operation but other combinations are not currently possible. Please could someone advise on the best way forward, initially I can think of a couple of options as follows:
Okay.
- create a wrapper that implements the old framework functions
(udc_init, udc_endpoint_read|write etc) and simply maps them on to the new framework. 2. import the appropriate TTY gadget implementation from Linux (as for ether.c) and get it working and registered as a proper device.
The new framework was _not_ meant _yet_ as a replacement for usbtty code. As mentioned above the goal was network traffic over USB. We choose to integrate the complete gadget layer as well to make integration of other class drivers easier, and to stay closer to the original code.
I suspect 2 is the better option and the way that the project was moving, but I thought I'd check if this was the way to go and whether anyone else had made any progress in this area.
There are indeed 2 routes: 1. If you need a serial console, you can still use it with the older usbtty code. 2. Adapt the new CDC layer such that it becomes suitable for console purposes as well. I would be happy integrating patches for this in the USB branch. That would allow us to migrate to 1 usb-gadget layer in the future which can be kept close to the linux development.
Also, if this is the way to go, could someone confirm which version of the Linux Gadget framework ether.c and friends are based on. It appears to be completely different to the latest version.
It is a port from Linux 2.6.27 to U-boot. Latest kernel changes are not integrated yet. But the port was kept quite close to the original code to make it easier to upgrade later on.
Kind Regards,
Remy
participants (2)
-
Daniel Sherwood -
Remy Bohmer