* [ECOS] new ecosconfig tool @ 2001-02-17 21:54 di yan 2001-02-18 6:06 ` Lewin A.R.W. Edwards 2001-02-19 6:29 ` Bart Veer 0 siblings, 2 replies; 17+ messages in thread From: di yan @ 2001-02-17 21:54 UTC (permalink / raw) To: ecos-discuss Hi all, I encountered a problem when I use new ecosconfig. 1. check out ecos 1.3.1. 2. update ecos to current. 3. using new ecosconfig tool(download from anonycvs) in Linux platform. ecosconfig list There are some warmings like: """" ecos.db, package CYGPKG_HAL_POWERPC: warning Version subdirectory 'cvs' does not have a CDL script ' hal_powerpc.cdl'. """" There is not such a problem when I use the old ecosconfig (with ecos-1.3.1). Thanks for your help in advance. Di __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] new ecosconfig tool 2001-02-17 21:54 [ECOS] new ecosconfig tool di yan @ 2001-02-18 6:06 ` Lewin A.R.W. Edwards 2001-02-19 6:29 ` Bart Veer 1 sibling, 0 replies; 17+ messages in thread From: Lewin A.R.W. Edwards @ 2001-02-18 6:06 UTC (permalink / raw) To: di yan, ecos-discuss Hello Di, >1. check out ecos 1.3.1. >2. update ecos to current. >3. using new ecosconfig tool(download from anonycvs) >in Linux platform. >ecosconfig list I don't get those errors. Maybe it is something odd/different about _updating_ rather than _checking out latest_. Try just cd /opt and checkout latest eCos sources. You'll end up with a directory "/opt/ecos", set ECOS_REPOSITORY=/opt/ecos/packages and try again "ecosconfig list". I currently have both eCos 1.3.1 and current CVS sources on my development system. I have replaced ecos-1.3.1/tools/bin/ecosconfig with the latest version, so my PATH is constant at /tools/H-i686-pc-linux-gnu/bin:/opt/ecos-1.3.1/tools/bin and I simply change ECOS_REPOSITORY when switching between versions. === Lewin A.R.W. Edwards (Embedded Engineer) Work: http://www.digi-frame.com/ Personal: http://www.zws.com/ and http://www.larwe.com/ "Und setzet ihr nicht das Leben ein, Nie wird euch das Leben gewonnen sein." ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] new ecosconfig tool 2001-02-17 21:54 [ECOS] new ecosconfig tool di yan 2001-02-18 6:06 ` Lewin A.R.W. Edwards @ 2001-02-19 6:29 ` Bart Veer 2001-02-19 6:33 ` Lewin A.R.W. Edwards 2001-02-19 13:32 ` [ECOS] USB host mode support? Tim Michals 1 sibling, 2 replies; 17+ messages in thread From: Bart Veer @ 2001-02-19 6:29 UTC (permalink / raw) To: diyan1; +Cc: ecos-discuss >>>>> "Di" == di yan <diyan1@yahoo.com> writes: Di> Hi all, Di> I encountered a problem when I use new ecosconfig. Di> 1. check out ecos 1.3.1. Di> 2. update ecos to current. Di> 3. using new ecosconfig tool(download from anonycvs) Di> in Linux platform. Di> ecosconfig list Di> There are some warmings like: Di> """" Di> ecos.db, package CYGPKG_HAL_POWERPC: warning Di> Version subdirectory 'cvs' does not have a CDL Di> script ' hal_powerpc.cdl'. Di> """" Di> There is not such a problem when I use the old Di> ecosconfig (with ecos-1.3.1). Di> Thanks for your help in advance. The relevant subdirectories should actually be "CVS" rather than "cvs". The configuration tools know about the special nature of CVS subdirectories and will ignore them, but the current code does not check for cvs. I am confused that there are any releases of CVS for Linux that use "cvs" subdirectories - it would be more believable under Windows where such things can depend on the particular filesystem being used. If you can rename the directories to CVS without problems, that should eliminate the warnings. Bart ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] new ecosconfig tool 2001-02-19 6:29 ` Bart Veer @ 2001-02-19 6:33 ` Lewin A.R.W. Edwards 2001-02-19 6:53 ` [ECOS] Still having problems getting networking up Bart Veer 2001-02-19 22:13 ` [ECOS] new ecosconfig tool di yan 2001-02-19 13:32 ` [ECOS] USB host mode support? Tim Michals 1 sibling, 2 replies; 17+ messages in thread From: Lewin A.R.W. Edwards @ 2001-02-19 6:33 UTC (permalink / raw) To: bartv, diyan1; +Cc: ecos-discuss > Di> Version subdirectory 'cvs' does not have a CDL > >check for cvs. I am confused that there are any releases of CVS for >Linux that use "cvs" subdirectories - it would be more believable >under Windows where such things can depend on the particular Do you think that maybe the target directory could be on a partition mounted as "msdos" (in which case it's going to fail anyway...)? === Lewin A.R.W. Edwards (Embedded Engineer) Work: http://www.digi-frame.com/ Personal: http://www.zws.com/ and http://www.larwe.com/ "Und setzet ihr nicht das Leben ein, Nie wird euch das Leben gewonnen sein." ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] Still having problems getting networking up 2001-02-19 6:33 ` Lewin A.R.W. Edwards @ 2001-02-19 6:53 ` Bart Veer 2001-02-19 22:13 ` [ECOS] new ecosconfig tool di yan 1 sibling, 0 replies; 17+ messages in thread From: Bart Veer @ 2001-02-19 6:53 UTC (permalink / raw) To: larwe; +Cc: ecos-discuss > On a related note, would it be possible for the list to be > reconfigured so that the Reply-to: is the list address, rather than > the poster's address? This has been requested before and rejected. The authorative text on the issue is http://www.unicom.com/pw/reply-to-harmful.html Bart ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] new ecosconfig tool 2001-02-19 6:33 ` Lewin A.R.W. Edwards 2001-02-19 6:53 ` [ECOS] Still having problems getting networking up Bart Veer @ 2001-02-19 22:13 ` di yan 2001-02-23 9:47 ` Jonathan Larmour 1 sibling, 1 reply; 17+ messages in thread From: di yan @ 2001-02-19 22:13 UTC (permalink / raw) To: Lewin A.R.W. Edwards, bartv; +Cc: ecos-discuss Thank you very much for your help. You are right. My machine has two OSes (window98 and linux). I check out ecos in window98. (because the few support for internal modem in Linux). Then I copy the whole tree to Linux. I rename the cvs to CVS. It works fine. Is there better way to avoid this manually change? Thanks, Di --- "Lewin A.R.W. Edwards" <larwe@larwe.com> wrote: > > > Di> Version subdirectory 'cvs' does not > have a CDL > > > >check for cvs. I am confused that there are any > releases of CVS for > >Linux that use "cvs" subdirectories - it would be > more believable > >under Windows where such things can depend on the > particular > > Do you think that maybe the target directory could > be on a partition > mounted as "msdos" (in which case it's going to fail > anyway...)? > > > === Lewin A.R.W. Edwards (Embedded Engineer) > Work: http://www.digi-frame.com/ > Personal: http://www.zws.com/ and > http://www.larwe.com/ > > "Und setzet ihr nicht das Leben ein, > Nie wird euch das Leben gewonnen sein." > __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] new ecosconfig tool 2001-02-19 22:13 ` [ECOS] new ecosconfig tool di yan @ 2001-02-23 9:47 ` Jonathan Larmour 0 siblings, 0 replies; 17+ messages in thread From: Jonathan Larmour @ 2001-02-23 9:47 UTC (permalink / raw) To: di yan; +Cc: ecos-discuss di yan wrote: > > Thank you very much for your help. > > You are right. My machine has two OSes (window98 and > linux). I check out ecos in window98. (because the few > support for internal modem in Linux). Then I copy the > whole tree to Linux. > > I rename the cvs to CVS. It works fine. > > Is there better way to avoid this manually change? You can maybe set up your Windows 98 machine as a proxy to the internet.... There is a tool called "Internet Connection Sharing" that is supplied in Windows 98 Second Edition (or you may be able to download it from Microsoft) which I believe should allow you to access the internet from your Linux box via your Windows machine. Unfortunately that's the extent of my knowledge so you'll have to try and sort the rest out yourself, or on Windows help groups. Jifl -- Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine ^ permalink raw reply [flat|nested] 17+ messages in thread
* [ECOS] USB host mode support? 2001-02-19 6:29 ` Bart Veer 2001-02-19 6:33 ` Lewin A.R.W. Edwards @ 2001-02-19 13:32 ` Tim Michals 2001-02-20 5:26 ` Bart Veer 1 sibling, 1 reply; 17+ messages in thread From: Tim Michals @ 2001-02-19 13:32 UTC (permalink / raw) To: egcs; +Cc: ecos-discuss All, Is this in the works? Tim ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] USB host mode support? 2001-02-19 13:32 ` [ECOS] USB host mode support? Tim Michals @ 2001-02-20 5:26 ` Bart Veer 2001-02-20 5:32 ` Tim Michals 0 siblings, 1 reply; 17+ messages in thread From: Bart Veer @ 2001-02-20 5:26 UTC (permalink / raw) To: tim; +Cc: ecos-discuss >>>>> "Tim" == Tim Michals <tim@cygnetinc.com> writes: Tim> All, Tim> Is this in the works? Not as far as I know. In some ways eCos and USB host support do not really go together. USB involves plug and play so you cannot know in advance what USB peripherals may get plugged in - including ones that have not even been invented yet at the time you ship your eCos-based product. This implies that you will need to load appropriate device drivers at run-time, and eCos does not support dynamic loading of code. There may be specific applications where this does not matter, especially if you know in advance exactly what is going to be connected to the USB bus, but for a general-purpose host solution you would be looking at something like embedded Linux rather than eCos. Of course when it comes to developing USB peripherals, eCos may well be a sensible choice. Red Hat has recently contributed USB slave support. Bart ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [ECOS] USB host mode support? 2001-02-20 5:26 ` Bart Veer @ 2001-02-20 5:32 ` Tim Michals 2001-02-20 5:54 ` Lewin A.R.W. Edwards 2001-02-21 6:42 ` Bart Veer 0 siblings, 2 replies; 17+ messages in thread From: Tim Michals @ 2001-02-20 5:32 UTC (permalink / raw) To: bartv; +Cc: ecos-discuss Thank you for your reply. I have been using eCOS for the past year and I'm amazed at the growth of features. My complements to the chef's of Red Hat! Also, I'm in the middle of doing using the current USB client side for an ARM implementation. I think as more embedded systems grow there will be a need for host mode USB. At this time I'm going to try a do a host mode version. Do you see any big issues in porting BSD or Linux implementation to eCOS? Tim -----Original Message----- From: Bart Veer [ mailto:bartv@redhat.com ] Sent: Tuesday, February 20, 2001 7:25 AM To: tim@cygnetinc.com Cc: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] USB host mode support? >>>>> "Tim" == Tim Michals <tim@cygnetinc.com> writes: Tim> All, Tim> Is this in the works? Not as far as I know. In some ways eCos and USB host support do not really go together. USB involves plug and play so you cannot know in advance what USB peripherals may get plugged in - including ones that have not even been invented yet at the time you ship your eCos-based product. This implies that you will need to load appropriate device drivers at run-time, and eCos does not support dynamic loading of code. There may be specific applications where this does not matter, especially if you know in advance exactly what is going to be connected to the USB bus, but for a general-purpose host solution you would be looking at something like embedded Linux rather than eCos. Of course when it comes to developing USB peripherals, eCos may well be a sensible choice. Red Hat has recently contributed USB slave support. Bart ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [ECOS] USB host mode support? 2001-02-20 5:32 ` Tim Michals @ 2001-02-20 5:54 ` Lewin A.R.W. Edwards 2001-02-20 6:17 ` Tim Michals 2001-02-21 6:42 ` Bart Veer 1 sibling, 1 reply; 17+ messages in thread From: Lewin A.R.W. Edwards @ 2001-02-20 5:54 UTC (permalink / raw) To: ecos-discuss Hi Tim, >I think as more embedded systems grow there will be a need for host mode >USB. At this time I'm going to try a do a host mode version. Do you see >any big issues in porting BSD or Linux implementation to eCOS? I'm curious to know what kind of USB peripherals you think will be important to support in embedded systems. It would be pretty easy to add generic HID support, but almost every other device you can think of is proprietary. There are some generic chipsets e.g. for ATA interfaces and scanners, but often the implementation is customized so a vanilla driver won't work properly. Basically you're buying into the whole minefield of maintaining a general-purpose operating system, when consumers call you and say "My new widget no worky when I plug it in". So at that point it makes perfect sense (to me to cross over to a GP OS like Linux, as Bart said. As another BTW, although eCos doesn't explicitly support dynamic loading, it is possible to implement it with some magic. I have a (grossly imperfect) module-loader as a work-in-progress. The reason I need one is because we wish to allow developers to write add-on modules for our product without wiping the whole OS out of flash. I seem to recall someone (Grant Edwards?) writing about a similar need on the list some weeks ago. === Lewin A.R.W. Edwards (Embedded Engineer) Work: http://www.digi-frame.com/ Personal: http://www.zws.com/ and http://www.larwe.com/ "Und setzet ihr nicht das Leben ein, Nie wird euch das Leben gewonnen sein." ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [ECOS] USB host mode support? 2001-02-20 5:54 ` Lewin A.R.W. Edwards @ 2001-02-20 6:17 ` Tim Michals 2001-02-20 7:10 ` Andrew Lunn 2001-02-20 7:41 ` Lewin A.R.W. Edwards 0 siblings, 2 replies; 17+ messages in thread From: Tim Michals @ 2001-02-20 6:17 UTC (permalink / raw) To: Lewin A.R.W. Edwards, ecos-discuss Lewin, >I'm curious to know what kind of USB peripherals you think will be >important to support in embedded systems. It would be pretty easy to add >generic HID support, but almost every other device you can think of is >proprietary. There are some generic chipsets e.g. for ATA interfaces and >scanners, but often the implementation is customized so a vanilla driver >won't work properly. Basically you're buying into the whole minefield of >maintaining a general-purpose operating system, when consumers call you and >say "My new widget no worky when I plug it in". So at that point it makes >perfect sense (to me to cross over to a GP OS like Linux, as Bart said. Mostly wireless USB devices, the idea is still to keep the OS very small and able to do some type of plugNPlay. ie download a new OS if required. Dynamic loading would be nice. I agree to some of the ideas of Linux, but the issue is we have a size issue. Yes, USB is a pain to support on the host side. But as devices become more internet and device aware this will become a requirement. 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? >As another BTW, although eCos doesn't explicitly support dynamic loading, >it is possible to implement it with some magic. I have a (grossly >imperfect) module-loader as a work-in-progress. The reason I need one is >because we wish to allow developers to write add-on modules for our product >without wiping the whole OS out of flash. I seem to recall someone (Grant >Edwards?) writing about a similar need on the list some weeks ago. Thanks -----Original Message----- From: ecos-discuss-owner@sources.redhat.com [ mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of Lewin A.R.W. Edwards Sent: Tuesday, February 20, 2001 7:53 AM To: ecos-discuss@sources.redhat.com Subject: RE: [ECOS] USB host mode support? Hi Tim, >I think as more embedded systems grow there will be a need for host mode >USB. At this time I'm going to try a do a host mode version. Do you see >any big issues in porting BSD or Linux implementation to eCOS? I'm curious to know what kind of USB peripherals you think will be important to support in embedded systems. It would be pretty easy to add generic HID support, but almost every other device you can think of is proprietary. There are some generic chipsets e.g. for ATA interfaces and scanners, but often the implementation is customized so a vanilla driver won't work properly. Basically you're buying into the whole minefield of maintaining a general-purpose operating system, when consumers call you and say "My new widget no worky when I plug it in". So at that point it makes perfect sense (to me to cross over to a GP OS like Linux, as Bart said. As another BTW, although eCos doesn't explicitly support dynamic loading, it is possible to implement it with some magic. I have a (grossly imperfect) module-loader as a work-in-progress. The reason I need one is because we wish to allow developers to write add-on modules for our product without wiping the whole OS out of flash. I seem to recall someone (Grant Edwards?) writing about a similar need on the list some weeks ago. === Lewin A.R.W. Edwards (Embedded Engineer) Work: http://www.digi-frame.com/ Personal: http://www.zws.com/ and http://www.larwe.com/ "Und setzet ihr nicht das Leben ein, Nie wird euch das Leben gewonnen sein." ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] USB host mode support? 2001-02-20 6:17 ` Tim Michals @ 2001-02-20 7:10 ` Andrew Lunn 2001-02-20 7:41 ` Lewin A.R.W. Edwards 1 sibling, 0 replies; 17+ messages in thread From: Andrew Lunn @ 2001-02-20 7:10 UTC (permalink / raw) To: Tim Michals; +Cc: Lewin A.R.W. Edwards, ecos-discuss > Mostly wireless USB devices ? Isn't that Bluetooth? Or do you mean a wireless network adapter which is connected to the host via USB instead of being a PCI card? > 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? I've not looked, but i would be very supprised if this is true. I expect the devices us loadable kernel modules, like pcmcia does. When you plug in a new device is will load the correct kernel module for the device. Andrew ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [ECOS] USB host mode support? 2001-02-20 6:17 ` Tim Michals 2001-02-20 7:10 ` Andrew Lunn @ 2001-02-20 7:41 ` Lewin A.R.W. Edwards 2001-02-20 9:50 ` Tim Michals 1 sibling, 1 reply; 17+ messages in thread From: Lewin A.R.W. Edwards @ 2001-02-20 7:41 UTC (permalink / raw) To: Tim Michals, ecos-discuss Hi Tim, >>I'm curious to know what kind of USB peripherals you think will be >Mostly wireless USB devices, the idea is still to keep the OS very small and >able to do some type of plugNPlay. ie download a new OS if required. >Dynamic loading would be nice. Hmm, I see. FWIW, the way we solved the need for wireless networking is to put Ethernet on the appliance and tell users to buy an Ethernet-to-wireless-flavor-of-the-month adapter. My experience as a consumer of a couple of appliances with host-side USB is that the instruction manual says "You can use the USB ports to plug in a mouse or external keyboard. At some stage, a future civilization with may develop a semi-working driver for one printer that will be obsolete by the time the driver for our proprietary OS becomes available", and in V1.001 of the device the port is left unpopulated due to lack of interest. As Bart said, if you can specify exactly what people are going to plug in there, it's a bit different because you can build in your own drivers. (You're at the mercy of those other companies though - every time they update their product, you need new drivers). But you're probably not going to get Red Hat to write those drivers for you and put them into eCos - at least, not for free :) >I agree to some of the ideas of Linux, but the issue is we have a size issue. What's your flash/ROM budget (actually, is it flash or ROM?) Can you store the OS compressed in flash/ROM and decompress it all to RAM? Can you get really funky and implement a compressed overlay type system where a small overlay manager is always in RAM, and the required code for whatever the user is doing is decompressed on-the-fly out of flash? (Works quite well with highly modal systems). >Yes, USB is a pain to support on the host side. But as devices >become more internet and device aware this will become a requirement. Your devices or devices in general? I don't think host-side USB is applicable to the vast majority of systems, simply because most embedded systems are either standalone appliances or peripherals, hence either no USB or slave-side USB. Until a decent completely vendor-independent standard is evolved for the common case devices (serial, LAN, storage, &c) it simply won't be possible to implement true "plug and play" USB without proprietary drivers. To my knowledge, the only class of devices that can be implemented generically right now is the HID class, which means basically keyboards, mice and joysticks. From our understanding, Internet connectivity for an embedded appliance means Ethernet for the office environment, or one of a number of competing wireless protocols in the home environment. >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? Much like the other poster, I haven't actually tried it as yet but in Linux many items can either be compiled into the kernel or dynamically loaded. You could keep your kernel size as small as possible and dyna-load the module for whatever pludule the user has poked at you. I'm very interested in your comments because they touch on issues that we have discussed internally at my company in the past. I formed certain opinions, and it would be useful to compare these with the opinions of others. === Lewin A.R.W. Edwards (Embedded Engineer) Work: http://www.digi-frame.com/ Personal: http://www.zws.com/ and http://www.larwe.com/ "Und setzet ihr nicht das Leben ein, Nie wird euch das Leben gewonnen sein." ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [ECOS] USB host mode support? 2001-02-20 7:41 ` Lewin A.R.W. Edwards @ 2001-02-20 9:50 ` Tim Michals 2001-02-20 10:11 ` Lewin A.R.W. Edwards 0 siblings, 1 reply; 17+ messages in thread From: Tim Michals @ 2001-02-20 9:50 UTC (permalink / raw) To: Lewin A.R.W. Edwards, ecos-discuss Lewin, >What's your flash/ROM budget 4M of ROM and 8M RAM. Yes I agree with the issues of drivers for USB are a pain, because devices are changing, no standards. Question for you mentioned: Hmm, I see. FWIW, the way we solved the need for wireless networking is to put Ethernet on the appliance and tell users to buy an Ethernet-to-wireless-flavor-of-the-month adapter. My experience as a consumer of a couple of appliances with host-side USB is that the instruction manual says "You can use the USB ports to plug in a mouse or external keyboard. At some stage, a future civilization with may develop a semi-working driver for one printer that will be obsolete by the time the driver for our proprietary OS becomes available", and in V1.001 of the device the port is left unpopulated due to lack of interest. So you have done this? Yes, a true embedded LinuxOS maybe the way to go, but, I'm trying to avoid this. What would be my best embedded Linux for ARM? Thanks Tim -----Original Message----- From: Lewin A.R.W. Edwards [ mailto:larwe@larwe.com ] Sent: Tuesday, February 20, 2001 9:40 AM To: Tim Michals; ecos-discuss@sources.redhat.com Subject: RE: [ECOS] USB host mode support? Hi Tim, >>I'm curious to know what kind of USB peripherals you think will be >Mostly wireless USB devices, the idea is still to keep the OS very small and >able to do some type of plugNPlay. ie download a new OS if required. >Dynamic loading would be nice. Hmm, I see. FWIW, the way we solved the need for wireless networking is to put Ethernet on the appliance and tell users to buy an Ethernet-to-wireless-flavor-of-the-month adapter. My experience as a consumer of a couple of appliances with host-side USB is that the instruction manual says "You can use the USB ports to plug in a mouse or external keyboard. At some stage, a future civilization with may develop a semi-working driver for one printer that will be obsolete by the time the driver for our proprietary OS becomes available", and in V1.001 of the device the port is left unpopulated due to lack of interest. As Bart said, if you can specify exactly what people are going to plug in there, it's a bit different because you can build in your own drivers. (You're at the mercy of those other companies though - every time they update their product, you need new drivers). But you're probably not going to get Red Hat to write those drivers for you and put them into eCos - at least, not for free :) >I agree to some of the ideas of Linux, but the issue is we have a size issue. What's your flash/ROM budget (actually, is it flash or ROM?) Can you store the OS compressed in flash/ROM and decompress it all to RAM? Can you get really funky and implement a compressed overlay type system where a small overlay manager is always in RAM, and the required code for whatever the user is doing is decompressed on-the-fly out of flash? (Works quite well with highly modal systems). >Yes, USB is a pain to support on the host side. But as devices >become more internet and device aware this will become a requirement. Your devices or devices in general? I don't think host-side USB is applicable to the vast majority of systems, simply because most embedded systems are either standalone appliances or peripherals, hence either no USB or slave-side USB. Until a decent completely vendor-independent standard is evolved for the common case devices (serial, LAN, storage, &c) it simply won't be possible to implement true "plug and play" USB without proprietary drivers. To my knowledge, the only class of devices that can be implemented generically right now is the HID class, which means basically keyboards, mice and joysticks. From our understanding, Internet connectivity for an embedded appliance means Ethernet for the office environment, or one of a number of competing wireless protocols in the home environment. >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? Much like the other poster, I haven't actually tried it as yet but in Linux many items can either be compiled into the kernel or dynamically loaded. You could keep your kernel size as small as possible and dyna-load the module for whatever pludule the user has poked at you. I'm very interested in your comments because they touch on issues that we have discussed internally at my company in the past. I formed certain opinions, and it would be useful to compare these with the opinions of others. === Lewin A.R.W. Edwards (Embedded Engineer) Work: http://www.digi-frame.com/ Personal: http://www.zws.com/ and http://www.larwe.com/ "Und setzet ihr nicht das Leben ein, Nie wird euch das Leben gewonnen sein." ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: [ECOS] USB host mode support? 2001-02-20 9:50 ` Tim Michals @ 2001-02-20 10:11 ` Lewin A.R.W. Edwards 0 siblings, 0 replies; 17+ messages in thread From: Lewin A.R.W. Edwards @ 2001-02-20 10:11 UTC (permalink / raw) To: Tim Michals, ecos-discuss > >What's your flash/ROM budget >4M of ROM and 8M RAM. Ow. If it's really ROM and not flash, and you have no rewritable non-volatile storage, then you're in trouble and my feeling is that a rethink is in order. You won't be able to update your drivers without a ROM swap (which is doable, of course, but _expensive_). If your only aim is to add wireless support for some specific protocol, it will be _so_ much easier to buy a prefab wireless module. The memory budget isn't impossible for embedded Linux, but I'm no expert on it so I'll bow out in favor of those who are. The only distribution I've played with for a reasonable length of time is ucLinux. Whichever distribution you go with will be tempered strongly by your host CPU (you only mentioned that it's an ARM; did you really mean StrongARM [seems plausible given the talk of host-side USB]). You might want to look at Royal Linux (I've installed it once, haven't played with it much; I only mention it because I know it supports ARM). >Ethernet-to-wireless-flavor-of-the-month adapter. My experience as a >consumer of a couple of appliances with host-side USB is that the >instruction manual says "You can use the USB ports to plug in a mouse or > >So you have done this? Have we done what? I mention above that I have bought/owned a couple of appliances (set-top box, Internet appliance) that had host-side USB, and it went the way you might expect - too much engineering cost to support additional peripherals, so it's just a decorative hole in the box. As for our own products, we decided that wireless is too infant and non-standardized right now. Also it is not an accepted standard in the way that Ethernet is. We don't want to tell our users to buy any specific piece of wireless hardware in order to talk to us, so we went with the lowest common denominator: Ethernet on the appliance, and if they want wireless they gate it themselves. At worst the user has to buy a $5 Ethernet card to talk to us. This approach also reduces the ongoing support issues greatly; a big consideration for us. === Lewin A.R.W. Edwards (Embedded Engineer) Work: http://www.digi-frame.com/ Personal: http://www.zws.com/ and http://www.larwe.com/ "Und setzet ihr nicht das Leben ein, Nie wird euch das Leben gewonnen sein." ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] USB host mode support? 2001-02-20 5:32 ` Tim Michals 2001-02-20 5:54 ` Lewin A.R.W. Edwards @ 2001-02-21 6:42 ` Bart Veer 1 sibling, 0 replies; 17+ messages in thread From: Bart Veer @ 2001-02-21 6:42 UTC (permalink / raw) To: tim; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2001-02-23 9:47 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-02-17 21:54 [ECOS] new ecosconfig tool di yan 2001-02-18 6:06 ` Lewin A.R.W. Edwards 2001-02-19 6:29 ` Bart Veer 2001-02-19 6:33 ` Lewin A.R.W. Edwards 2001-02-19 6:53 ` [ECOS] Still having problems getting networking up Bart Veer 2001-02-19 22:13 ` [ECOS] new ecosconfig tool di yan 2001-02-23 9:47 ` Jonathan Larmour 2001-02-19 13:32 ` [ECOS] USB host mode support? Tim Michals 2001-02-20 5:26 ` Bart Veer 2001-02-20 5:32 ` Tim Michals 2001-02-20 5:54 ` Lewin A.R.W. Edwards 2001-02-20 6:17 ` Tim Michals 2001-02-20 7:10 ` Andrew Lunn 2001-02-20 7:41 ` Lewin A.R.W. Edwards 2001-02-20 9:50 ` Tim Michals 2001-02-20 10:11 ` Lewin A.R.W. Edwards 2001-02-21 6:42 ` Bart Veer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).