[U-Boot-Users] ethernet over usb

[Bryan O'Donoghue]

Rodolfo Giometti wrote:
> On Tue, Sep 12, 2006 at 02:31:56PM +0100, Bryan O'Donoghue wrote:
>> If you look in Das U-Boot USB git tree you will see an implementation of 
>> Linux-Gserial and CDC ACM. Somebody from TI did the original 
>> implementation of g_serial and I added in CDC ACM.
> 
> Great! But let me understand, you added CDC into g_serial or what? I'm
> a bit confused... Did you transfer the file through something similar
> to a serial line or similar to an ethernet?

There is a slight modification of usbtty.c in this tree.

http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=shortlog;h=testing-USB

The main thing changed was the addition of

1. Flow control to usbtty
2. Allow control transfers to preempt BULK IN/OUT transfers and then to 
finish off the Rx/Tx of data.

That's really important because USB (BULK) guarantees data delivery.

What that means from a practical point of view is that yes you can 
transfer something large like u-boot.bin using a USB link between your 
host machine and your U-Boot slave. For this I used kermit on my Linux 
host and the corresponding kermit rx command in U-Boot.

Without flow control you wouldn't be able to do that. Also usbtty 
doesn't just throw away data it couldn't send (when it gets pre-empted 
by a control transfer for example), it simply yields to the control 
transfer, does what it has to do and continues to send/receive data, so 
there is no data loss. This allows you to use gserial/cdc_acm for data 
you care about, like u-boot.bin for example.

As it happens g_serial has better throughput then cdc_acm, because a 
host machine sends periodic control requests to a cdc_acm device, hence 
transferring a large file like u-boot.bin from host machine to 
bootloader will be slightly slower using cdc_acm as the bootloader must 
service control requests every so often.

>> I've actually transferred u-boot.bin over such a link via USB as part of 
>> my testing for usbdcore_mpc8xx, so if the transfer of files is what you 
>> are after perhaps just implementing usbdcore_au1100 yourself and using 
>> the higher layer usbtty.c would suffice, for your purposes.
> 
> As first step this is my target. However I need RNDIS also. Do you
> think adding it could be "easy" at this point of developing?

Easy ? Hmm... at least not difficult (probably) !

I think RNDIS support is the more chunky of the two protocols to 
implement but, I'd say it could be done fairly quickly; five days work 
maybe.

CDC Ethernet would take less time still, I should think.


Bryan

-- 
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.