[U-Boot-Users] ethernet over usb
Hello,
I need to allow my board to TFTP data through an USB connection.
I'm just writing the USB device support for Alchemy au1100 and then I'm going to port usbnet from linux to u-boot in order to add a new "usbnet" device.
I'd like to know if someone else is doing something similar or is interested at this project in order to join the efforts.
Ciao,
Rodolfo
Rodolfo Giometti wrote:
Hello,
I need to allow my board to TFTP data through an USB connection.
I'm just writing the USB device support for Alchemy au1100 and then I'm going to port usbnet from linux to u-boot in order to add a new "usbnet" device.
I'd like to know if someone else is doing something similar or is interested at this project in order to join the efforts.
Ciao,
Rodolfo
Greetings Rodolfo.
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.
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.
Alternatively you may really need to implement Ethernet over the USB.
If you want to do that then there are probably two things to consider.
1. RNDIS - the Microsoft standard, works with Linux too. 2. CDC Ethernet - A USB standard that Microsoft has chosen not to implement in Windows (AFAIK) and is Linux (and possibly *BSD) only.
If going for Ethernet over the USB I'd suggest the thing to do is something similar as has been done in usbtty.c, with some high level Ethernet device (usb_ethernet.c ?) that knows about the cdc_ethernet and rndis_ethernet protocols.
I'd be happy to collaborate with you to implement the 'other' one or both of the above; i.e. if you do RNDIS I'll do CDC ethernet or vice-versa, I'd say with two people working on it, it would be fairly easy to do.
Bryan
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?
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?
Alternatively you may really need to implement Ethernet over the USB. [snip]
I see. But for the moment it's sufficient to me just transferring files. :)
Thanks a lot for your message,
Rodolfo
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
In message 20060912132058.GB31470@gundam.enneenne.com you wrote:
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?
Right. U-Boot represents to the outside world as a serial adapter.
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? You must be joking.
To be honest: I think you make a fundamental mistake - U-Boot is not an general purpose OS, it is a boot loader. For requirements like yours it is usually *much* easier and faster (both in terms of development and reachable performance) to boot a small, dedicated Linux kernelk and use a real OS.
Best regards,
Wolfgang Denk
On Tue, Sep 12, 2006 at 06:17:52PM +0200, Wolfgang Denk wrote:
To be honest: I think you make a fundamental mistake - U-Boot is not an general purpose OS, it is a boot loader. For requirements like yours it is usually *much* easier and faster (both in terms of development and reachable performance) to boot a small, dedicated Linux kernelk and use a real OS.
But during developing stages I have no kernel to use so I have to load it from my host system using the bootloader.
Currently, developing stages are: compile the kernel, transfer it to the target machine through the ethernet device and then try the boot, but on my current board I have no ethernet at all, just the USBdev and I'd like to have a way to transfer my developing kernel through USB line.
Ciao,
Rodolfo
In message 20060912162552.GA4183@gundam.enneenne.com you wrote:
Currently, developing stages are: compile the kernel, transfer it to the target machine through the ethernet device and then try the boot, but on my current board I have no ethernet at all, just the USBdev and I'd like to have a way to transfer my developing kernel through USB line.
As mentioned before, using a serial link might be much easier. Remember that USB is fast, i. e. you are not limited to baudrates like 115kbps or so.
Best regards,
Wolfgang Denk
Bryan O'Donoghue wrote:
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.
Just reading what I said there, I'll expand a little bit.
Since you want to TFTP over the USB, from your point of view, there is no reason not to use CDC_ACM/g_serial and just do a kermit binary transfer and save yourself the effort of doing Ethernet over the USB.
All you'd really have to do is implement usbdcore_au1100 and just do a straight forward kermit binary transfer .. with the 8xx and both CDC_ACM and g_serial, it works well enough for me.
Still if you are going to do some of the ethernet side ... it would be a good excuse for me, to stay out of the pub !
Bryan
On Tue, Sep 12, 2006 at 02:39:45PM +0100, Bryan O'Donoghue wrote:
Since you want to TFTP over the USB, from your point of view, there is no reason not to use CDC_ACM/g_serial and just do a kermit binary transfer and save yourself the effort of doing Ethernet over the USB.
All you'd really have to do is implement usbdcore_au1100 and just do a straight forward kermit binary transfer .. with the 8xx and both CDC_ACM and g_serial, it works well enough for me.
Let me explain better my situation. My board have a serial line and an USBdev as I/O interfaces. In linux I'm going to use the serial line for the console and the USBdev for rootfs and other network activities. I'd like to do the same into u-boot in order to have a serial console and a TFTP file transfer.
Do you think that I can use the current implemented software (apart the usbdcore_au1100) for my purposes?
Still if you are going to do some of the ethernet side ... it would be a good excuse for me, to stay out of the pub !
:)
Thanks,
Rodolfo
Rodolfo Giometti wrote:
Let me explain better my situation. My board have a serial line and an USBdev as I/O interfaces. In linux I'm going to use the serial line for the console and the USBdev for rootfs and other network activities. I'd like to do the same into u-boot in order to have a serial console and a TFTP file transfer.
Do you think that I can use the current implemented software (apart the usbdcore_au1100) for my purposes?
I don't believe so. If you want to tftp 'stuff' I don't see how implementing cdc_ethernet/RNDIS could be avoided, unless there is some way to plug host side tftpd into a serial console like /dev/ttyUSB0 !
Bryan
participants (3)
-
Bryan O'Donoghue -
Rodolfo Giometti -
Wolfgang Denk