[ECOS] new ecosconfig tool

[ECOS] new ecosconfig tool

[di yan]

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/

Re: [ECOS] new ecosconfig tool

[Lewin A.R.W. Edwards]

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."

Re: [ECOS] new ecosconfig tool

[Bart Veer]

>>>>> "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

Re: [ECOS] new ecosconfig tool

[Lewin A.R.W. Edwards]

>    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."

Re: [ECOS] Still having problems getting networking up

[Bart Veer]

 > 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

[ECOS] USB host mode support?

[Tim Michals]

All,

Is this in the works?

Tim

Re: [ECOS] new ecosconfig tool

[di yan]

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/

Re: [ECOS] USB host mode support?

[Bart Veer]

>>>>> "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

RE: [ECOS] USB host mode support?

[Tim Michals]

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

RE: [ECOS] USB host mode support?

[Lewin A.R.W. Edwards]

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."

RE: [ECOS] USB host mode support?

[Tim Michals]

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."

Re: [ECOS] USB host mode support?

[Andrew Lunn]

> 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

RE: [ECOS] USB host mode support?

[Lewin A.R.W. Edwards]

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."

RE: [ECOS] USB host mode support?

[Tim Michals]

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."

RE: [ECOS] USB host mode support?

[Lewin A.R.W. Edwards]

> >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."

Re: [ECOS] USB host mode support?

[Bart Veer]

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

Re: [ECOS] new ecosconfig tool

[Jonathan Larmour]

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

RE: [ECOS] Still having problems getting networking up

[Gary Thomas]

On 16-Feb-2001 Lewin A.R.W. Edwards wrote:
> 
>>    Lewin> ecosconfig new edb7xxx
>>     Lewin> ecosconfig add eth_drivers net
>>
>>You should be able to just do "ecosconfig new edb7xxx net" to combine
>>the above two steps, but that is not the problem here.
> 
> Just FYI, it seems that template is currently broken, as eCos won't build 
> successfully with "ecosconfig new edb7xxx net". I'll redo it and send a 
> make.out if you want, but it should be easy to reproduce.
> 

I tried this "six ways from Sunday" against the current [master] sources and 
I could not reproduce your error.

> Anyway, I got everything built OK, but it seems that more configuration is 
> required. When my app starts, it hangs repeating "CS8900: Tx interrupt lost".
> 

If you have an EDB7212 board then you'll need to remove a resistor to get
interrupts to work.  Remove R168 and all jumpers from JP45.

Alternatively, you can try enabling the #define INTS_DONT_WORK in the driver.

> To gather a little more info, I set up a (different from previous) bogus 
> MAC address of 0x00:0x14:0x49:0x18:0x14:0x00 using fconfig, and I enabled 
> boot-time network debugging. Power up and I get several repetitions of this:
> 
> Ethernet send:
> 0x000029E4: FFFF FFFF FFFF 0014  4918 1400 0800        |........I.....  |
> 0x0000C93C: 4500 0148 0002 0000  4011 79A4 0000 0000   |E..H....@.y.....|
> 0x0000C94C: FFFF FFFF 0044 0043  0134 0F6B 0101 0600   |.....D.C.4.k....|
> 0x0000C95C: 5555 3412 0000 0000  0000 0000 0000 0000   |UU4.............|
> 0x0000C96C: 0000 0000 0000 0000  0014 4918 1400 0000   |..........I.....|
> 0x0000C97C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
> 0x0000C98C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
> 0x0000C99C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
> 0x0000C9AC: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
> 0x0000C9BC: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
> 0x0000C9CC: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
> 0x0000C9DC: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
> 0x0000C9EC: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
> 0x0000C9FC: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
> 0x0000CA0C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
> 0x0000CA1C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
> 0x0000CA2C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
> 0x0000CA3C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
> 0x0000CA4C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
> 0x0000CA5C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
> 0x0000CA6C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
> 0x0000CA7C: 0000 0000 0000 0000                        |........        |
> Tx event: 8
> Can't get BOOTP info - network disabled!
> RedBoot>
> 
> The link LED is on, everything should be working I think. Is there 
> something else I've forgotten?
> 
> One issue that I don't understand here is the following quote from 
> < http://sources.redhat.com/ecos/docs-latest/tcpip/tcpip.3.html#pgfId=1132625 >: 
> "This assumes that the MAC address is already defined in the serial EEPROM 
> or however the particular target implements this; there is no (tested) 
> support for setting the MAC address in this release." Does the networking 
> code in eCos [not redboot] read the MAC address set by fconfig and saved in 
> main flash store? If not, then how is it possible to bring up eth0 on the 
> Cirrus board?
> 

Currently, if you run RedBoot and enable the network address (turn on networking
support in RedBoot) then eCos will just use that.  Note: eCos does not get the
ESA from the FLASH, it assumes that RedBoot has set it up.

[ECOS] Still having problems getting networking up

[Lewin A.R.W. Edwards]

>    Lewin> ecosconfig new edb7xxx
>     Lewin> ecosconfig add eth_drivers net
>
>You should be able to just do "ecosconfig new edb7xxx net" to combine
>the above two steps, but that is not the problem here.

Just FYI, it seems that template is currently broken, as eCos won't build 
successfully with "ecosconfig new edb7xxx net". I'll redo it and send a 
make.out if you want, but it should be easy to reproduce.

Anyway, I got everything built OK, but it seems that more configuration is 
required. When my app starts, it hangs repeating "CS8900: Tx interrupt lost".

To gather a little more info, I set up a (different from previous) bogus 
MAC address of 0x00:0x14:0x49:0x18:0x14:0x00 using fconfig, and I enabled 
boot-time network debugging. Power up and I get several repetitions of this:

Ethernet send:
0x000029E4: FFFF FFFF FFFF 0014  4918 1400 0800        |........I.....  |
0x0000C93C: 4500 0148 0002 0000  4011 79A4 0000 0000   |E..H....@.y.....|
0x0000C94C: FFFF FFFF 0044 0043  0134 0F6B 0101 0600   |.....D.C.4.k....|
0x0000C95C: 5555 3412 0000 0000  0000 0000 0000 0000   |UU4.............|
0x0000C96C: 0000 0000 0000 0000  0014 4918 1400 0000   |..........I.....|
0x0000C97C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
0x0000C98C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
0x0000C99C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
0x0000C9AC: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
0x0000C9BC: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
0x0000C9CC: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
0x0000C9DC: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
0x0000C9EC: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
0x0000C9FC: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
0x0000CA0C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
0x0000CA1C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
0x0000CA2C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
0x0000CA3C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
0x0000CA4C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
0x0000CA5C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
0x0000CA6C: 0000 0000 0000 0000  0000 0000 0000 0000   |................|
0x0000CA7C: 0000 0000 0000 0000                        |........        |
Tx event: 8
Can't get BOOTP info - network disabled!
RedBoot>

The link LED is on, everything should be working I think. Is there 
something else I've forgotten?

One issue that I don't understand here is the following quote from 
< http://sources.redhat.com/ecos/docs-latest/tcpip/tcpip.3.html#pgfId=1132625 >: 
"This assumes that the MAC address is already defined in the serial EEPROM 
or however the particular target implements this; there is no (tested) 
support for setting the MAC address in this release." Does the networking 
code in eCos [not redboot] read the MAC address set by fconfig and saved in 
main flash store? If not, then how is it possible to bring up eth0 on the 
Cirrus board?

=== 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."