From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bart Veer To: tim@cygnetinc.com Cc: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] USB host mode support? Date: Wed, 21 Feb 2001 06:42:00 -0000 Message-id: <200102211442.f1LEgCe08083@sheesh.cambridge.redhat.com> References: X-SW-Source: 2001-02/msg00346.html Replying to various postings in this thread. >>>>> "Tim" == Tim Michals 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 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 writes: 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 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 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). 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