This is the mail archive of the
mailing list for the eCos project.
Using a RedBoot USB driver also in eCos applications
- From: "Martin Schachinger" <schachie at gmx dot at>
- To: ecos-discuss at ecos dot sourceware dot org
- Date: Mon, 29 Sep 2008 19:10:32 +0200
- Subject: [ECOS] Using a RedBoot USB driver also in eCos applications
we are using eCos/RedBoot on our own built PowerPC 5200 platform quite a time.
It is equipped with a PLX NET 2272 USB2.0 Chip for USB communication.
For the PLX NET 2272 we are using a third party driver from PLX Technology.
Currently we have added USB download support to the RedBoot 'load' command
simply by adding the USB driver source code files including our USB enumeration
configuration to RedBoot.
I know thats quite a dirty hack but it workes fine for us.
Now we have the challenge to replace the whole RS232 console interface by USB
since the acceptance for RS232 is very low within our customers.
The goal we want to reach is that RedBoot and our "real" application
communicates only over one USB interface.
We think about to put all the Low-Level USB driver source code into a package
Then initialize the USB driver (using polling mode)
in the very beginning of RedBoot to switch the
console/debug output with CYGACC_CALL_IF_SET_CONSOLE_COMM and
CYGACC_CALL_IF_SET_DEBUG_COMM to the USB driver.
With that all I/O with diag_* is routed to USB (I think that is no problem
since I built something similar with a PCI interface on an other hardware
We are also thinking about to use a generic USB serial driver for CONSOLE and
DEBUG COMM channel to have the benefit of using any available terminal
program like minicom or TeraTerm without additional coding effort on the host
But in addition to that our application (which is loaded and started within
Redboot) should simply register some more USB pipes to communicate also with
Here the problem is that the application cant initialize the USB driver again
since the pipes used by RedBoot for CONSOLE_COMM and DEBUG_COMM would be
So we tought about to let the application access the USB driver (which allready
runs in context of RedBoot) only over virtual vector calls to registrate some
more pipes and do all the send/receive functionality over that. The application
should also switch the USB driver to interrupt mode for normal operation.
Use case Summary:
1) Our board is connected only over USB interface to the host.
2) RedBoot can be controlled normaly via RedBoot prompt to download and start
an application (like it works currently on the RS232 interface).
3) If the application is started it will accesses the USB driver via virtual
vector calls to registrates some more pipes and do all the communication.
Do you think this will be the right approach?
Freundliche Grüße / Best regards
GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss