[U-Boot] usbtty Support on AT91SAM9XXX chipsets

[Remy Bohmer]

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!

> 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.

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.

> 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.

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