This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: USB host mode support?


Replying to various postings in this thread.

>>>>> "Tim" == Tim Michals <tim@cygnetinc.com> writes:

    Tim> I think as more embedded systems grow there will be a need
    Tim> for host mode USB. At this time I'm going to try a do a host
    Tim> mode version. Do you see any big issues in porting BSD or
    Tim> Linux implementation to eCOS?

I am afraid I have not looked at the BSD code at all, and only a
little bit at the Linux code in the context of writing a host-side USB
device driver a couple of months back. I do not know what kind of
porting problems there are going to be. In the case of the Linux
implementation you should of course consider the implementations of
the GPL.

>>>>> "Lewin" == Lewin A R W Edwards <larwe@larwe.com> writes:

    Lewin> I'm curious to know what kind of USB peripherals you think
    Lewin> will be important to support in embedded systems. It would
    Lewin> be pretty easy to add generic HID support, but almost every
    Lewin> other device you can think of is proprietary. There are
    Lewin> some generic chipsets e.g. for ATA interfaces and scanners,
    Lewin> but often the implementation is customized so a vanilla
    Lewin> driver won't work properly. Basically you're buying into
    Lewin> the whole minefield of maintaining a general-purpose
    Lewin> operating system, when consumers call you and say "My new
    Lewin> widget no worky when I plug it in". So at that point it
    Lewin> makes perfect sense to me to cross over to a GP OS like
    Lewin> Linux, as Bart said.

Essentially correct. In fact there are standards for other kinds of
USB peripherals, for example there is a standard that is supposed to
cover all kinds of communication equipment from dial-up modems to LANs
and upwards, but in practice most of these standards seem to be
ignored. When I implemented the eCos USB-ethernet support I had to
ignore the communication standard because of a hardware design flaw:
the chip was incapable of fully implementing the standard.

    Lewin> As another BTW, although eCos doesn't explicitly support
    Lewin> dynamic loading, it is possible to implement it with some
    Lewin> magic. I have a (grossly imperfect) module-loader as a
    Lewin> work-in-progress. The reason I need one is because we wish
    Lewin> to allow developers to write add-on modules for our product
    Lewin> without wiping the whole OS out of flash. I seem to recall
    Lewin> someone (Grant Edwards?) writing about a similar need on
    Lewin> the list some weeks ago.

See http://sources.redhat.com/ml/ecos-discuss/2001-01/msg00386.html
and follow-ups. Note that there are different approaches here. One
approach involves running the dynamically loaded code securely, in a
sandbox, with little or no access to hardware.

>>>>> "Tim" == Tim Michals <tim@cygnetinc.com> writes:

    <snip>
    Tim> Mostly wireless USB devices, the idea is still to keep the OS
    Tim> very small and able to do some type of plugNPlay. ie download
    Tim> a new OS if required. Dynamic loading would be nice. I agree
    Tim> to some of the ideas of Linux, but the issue is we have a
    Tim> size issue. Yes, USB is a pain to support on the host side.
    Tim> But as devices become more internet and device aware this
    Tim> will become a requirement.

One idea in this area is embedded devices shipped with just RedBoot,
with an appropriate application downloaded at run-time. For example,
consider a USB peripheral. You plug it in, the host detects this and
loads the appropriate device driver, this device driver loads the
actual application into the peripheral, then the peripheral
disconnects, reconnects as a different kind of USB device, and is now
usable. If the application is reasonable small, say some hundreds of
K, then the delay should be barely noticeable. Obviously there are
many variations on this theme depending on the connectivity being
used.

    Tim> Also, it is still me understanding most of the USB device
    Tim> support under Linux must be compiled, therefore, as you add a
    Tim> new device you must recompile the OS?

Not entirely correct. See e.g.
http://sources.redhat.com/ecos/docs-latest/usb/eth/slave/usbseth-host.html
for details of what is involved in building and loading a new module.
Currently that documentation does assume that you have a configured
and built Linux source tree lying around so that configury and
makefile info can be picked up from that, but you do not actually need
to install that kernel to load the new module.

>>>>> "Andrew" == Andrew Lunn <andrew.lunn@ascom.ch> writes:

    >> Also, it is still me understanding most of the USB device
    >> support under Linux must be compiled, therefore, as you add a
    >> new device you must recompile the OS?

    Andrew> I've not looked, but i would be very supprised if this is
    Andrew> true. I expect the devices us loadable kernel modules,
    Andrew> like pcmcia does. When you plug in a new device is will
    Andrew> load the correct kernel module for the device.

USB device drivers can be dynamically loaded, but unlike pcmcia they
will not be loaded automatically when you plug in the device - there
is no central database to match up application class id's, vendor
id's, etc. with specific device drivers. Instead you have to load the
driver manually. At least, that was the case with the 2.2.16 kernel,
things may have moved on since then.

>>>>> "Tim" == Tim Michals <tim@cygnetinc.com> writes:

    >> What's your flash/ROM budget
    Tim> 4M of ROM and 8M RAM.

Some version of embedded Linux may well be possible, but obviously it
will consume more of that memory than eCos would so there will be less
left for the application(s). 

    <snip>

    Tim> Yes, a true embedded LinuxOS maybe the way to go, but, I'm
    Tim> trying to avoid this. What would be my best embedded Linux
    Tim> for ARM?

Note that Red Hat provides embedded Linux consultancy and porting
services, just as it does for eCos. If that is of interest I can put
you in touch with the appropriate people.

Bart


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]