[ECOS] Re: LPC2xxx patch for support of vectored interrupt controller

[ECOS] Re: LPC2xxx patch for support of vectored interrupt controller

[Andrew Lunn]

On Wed, Aug 22, 2007 at 10:40:26AM +0200, Hans Rosenfeld wrote:
> On Wed, Aug 22, 2007 at 10:24:51AM +0200, Andrew Lunn wrote:
> > > +#ifdef CYGNUM_KERNEL_INTR_TEST_PRIO
> > > +#define PRIO_0 CYGNUM_KERNEL_INTR_TEST_PRIO
> > > +#define PRIO_1 CYGNUM_KERNEL_INTR_TEST_PRIO
> > > +#else
> > > +#define PRIO_0 0
> > > +#define PRIO_1 1
> > > +#endif
> > 
> > I've not spent time to really understand this change. But a first
> > glance suggests this is wrong. Shouldn't it be
> > 
> > #define PRIO_1 (CYGNUM_KERNEL_INTR_TEST_PRIO + 1)
> > 
> > in order to maintain the old behaviour. 
> 
> On the LPC2xxx there is only one interrupt priority (16) that can be
> used more than once. The reason for making this configurable is to make
> this test use only this priority, even if this is different from the old
> behaviour. I don't think this is a problem since the interrupts are never
> triggered in those tests.

I think much better way to do this is:

            cdl_option CYGNUM_KERNEL_INTR_TEST_PRIO_A {
                display       "interrupt priority used by intr0/kintr0 test"
                flavor        data
                default_value 0
                legal_values  0 to 16
                description   "The intr0 and kintr0 tests create several interrupts.
                               This option selects the interrupt priority to be used
                               for these interrupts."
            }

            cdl_option CYGNUM_KERNEL_INTR_TEST_PRIO_B {
                display       "interrupt priority used by intr0/kintr0 test"
                flavor        data
                default_value 1
                legal_values  0 to 16
                description   "The intr0 and kintr0 tests create several interrupts.
                               This option selects the interrupt priority to be used
                               for these interrupts."
            }

and then in the LPC2XXX hal statements like

    requires { is_active(CYGNUM_KERNEL_INTR_TEST_PRIO_A) 
               implies { CYGNUM_KERNEL_INTR_TEST_PRIO_A == 16 } }

    requires { is_active(CYGNUM_KERNEL_INTR_TEST_PRIO_B) 
               implies { CYGNUM_KERNEL_INTR_TEST_PRIO_B == 16 } }

It makes the test more flexible. You can how for example use vectors 5
and 15 which was not possible before.

    Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: LPC2xxx patch for support of vectored interrupt controller

[Hans Rosenfeld]

On Wed, Aug 22, 2007 at 11:18:03AM +0200, Andrew Lunn wrote:
> I think much better way to do this is:
> 
>             cdl_option CYGNUM_KERNEL_INTR_TEST_PRIO_A {
>                 display       "interrupt priority used by intr0/kintr0 test"
>                 flavor        data
>                 default_value 0
>                 legal_values  0 to 16
>                 description   "The intr0 and kintr0 tests create several interrupts.
>                                This option selects the interrupt priority to be used
>                                for these interrupts."
>             }
> 
>             cdl_option CYGNUM_KERNEL_INTR_TEST_PRIO_B {
>                 display       "interrupt priority used by intr0/kintr0 test"
>                 flavor        data
>                 default_value 1
>                 legal_values  0 to 16
>                 description   "The intr0 and kintr0 tests create several interrupts.
>                                This option selects the interrupt priority to be used
>                                for these interrupts."
>             }
> 
> and then in the LPC2XXX hal statements like
> 
>     requires { is_active(CYGNUM_KERNEL_INTR_TEST_PRIO_A) 
>                implies { CYGNUM_KERNEL_INTR_TEST_PRIO_A == 16 } }
> 
>     requires { is_active(CYGNUM_KERNEL_INTR_TEST_PRIO_B) 
>                implies { CYGNUM_KERNEL_INTR_TEST_PRIO_B == 16 } }
> 
> It makes the test more flexible. You can how for example use vectors 5
> and 15 which was not possible before.

Looks good, but I'm unsure about PRIO_A and PRIO_B vs. PRIO_0 and
PRIO_1. I used PRIO_0 where the test used a hardcoded 0, and PRIO_1
where test used a hardcoded 1 (twice). How will PRIO_A and PRIO_B map to
this?


-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: LPC2xxx patch for support of vectored interrupt controller

[Andrew Lunn]

On Wed, Aug 22, 2007 at 11:52:28AM +0200, Hans Rosenfeld wrote:
> On Wed, Aug 22, 2007 at 11:18:03AM +0200, Andrew Lunn wrote:
> > I think much better way to do this is:
> > 
> >             cdl_option CYGNUM_KERNEL_INTR_TEST_PRIO_A {
> >                 display       "interrupt priority used by intr0/kintr0 test"
> >                 flavor        data
> >                 default_value 0
> >                 legal_values  0 to 16
> >                 description   "The intr0 and kintr0 tests create several interrupts.
> >                                This option selects the interrupt priority to be used
> >                                for these interrupts."
> >             }
> > 
> >             cdl_option CYGNUM_KERNEL_INTR_TEST_PRIO_B {
> >                 display       "interrupt priority used by intr0/kintr0 test"
> >                 flavor        data
> >                 default_value 1
> >                 legal_values  0 to 16
> >                 description   "The intr0 and kintr0 tests create several interrupts.
> >                                This option selects the interrupt priority to be used
> >                                for these interrupts."
> >             }
> > 
> > and then in the LPC2XXX hal statements like
> > 
> >     requires { is_active(CYGNUM_KERNEL_INTR_TEST_PRIO_A) 
> >                implies { CYGNUM_KERNEL_INTR_TEST_PRIO_A == 16 } }
> > 
> >     requires { is_active(CYGNUM_KERNEL_INTR_TEST_PRIO_B) 
> >                implies { CYGNUM_KERNEL_INTR_TEST_PRIO_B == 16 } }
> > 
> > It makes the test more flexible. You can how for example use vectors 5
> > and 15 which was not possible before.
> 
> Looks good, but I'm unsure about PRIO_A and PRIO_B vs. PRIO_0 and
> PRIO_1. I used PRIO_0 where the test used a hardcoded 0, and PRIO_1
> where test used a hardcoded 1 (twice). How will PRIO_A and PRIO_B map to
> this?

I wanted to avoid _0 and _1 because it may make reader of the code
think they have the value of 0 and 1! If a reading is interested in
the value, using A and B makes the reader go looking for the actual
value, rather than assume they are 0 and 1. 

In the code i would replace 0 with CYGNUM_KERNEL_INTR_TEST_PRIO_A and
1 with CYGNUM_KERNEL_INTR_TEST_PRIO_B, since the defaults set them to
these values.

  Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: LPC2xxx patch for support of vectored interrupt controller

[Hans Rosenfeld]

On Wed, Aug 22, 2007 at 12:06:26PM +0200, Andrew Lunn wrote:
> I wanted to avoid _0 and _1 because it may make reader of the code
> think they have the value of 0 and 1! If a reading is interested in
> the value, using A and B makes the reader go looking for the actual
> value, rather than assume they are 0 and 1. 

Yes, that was bad style on my part.

> In the code i would replace 0 with CYGNUM_KERNEL_INTR_TEST_PRIO_A and
> 1 with CYGNUM_KERNEL_INTR_TEST_PRIO_B, since the defaults set them to
> these values.

Maybe we should have CYGNUM_KERNEL_INTR_TEST_PRIO_C, too. The tests
create three interrupts.


-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: LPC2xxx patch for support of vectored interrupt controller

[Andrew Lunn]

On Wed, Aug 22, 2007 at 12:51:32PM +0200, Hans Rosenfeld wrote:
> On Wed, Aug 22, 2007 at 12:06:26PM +0200, Andrew Lunn wrote:
> > I wanted to avoid _0 and _1 because it may make reader of the code
> > think they have the value of 0 and 1! If a reading is interested in
> > the value, using A and B makes the reader go looking for the actual
> > value, rather than assume they are 0 and 1. 
> 
> Yes, that was bad style on my part.
> 
> > In the code i would replace 0 with CYGNUM_KERNEL_INTR_TEST_PRIO_A and
> > 1 with CYGNUM_KERNEL_INTR_TEST_PRIO_B, since the defaults set them to
> > these values.
> 
> Maybe we should have CYGNUM_KERNEL_INTR_TEST_PRIO_C, too. The tests
> create three interrupts.

O.K.

Could your produce a patch which contains all these changes and a
ChangeLog entry in both the Kernel package and the HAL.

        Thanks
                Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: LPC2xxx patch for support of vectored interrupt controller

[Hans Rosenfeld]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

On Wed, Aug 22, 2007 at 01:12:16PM +0200, Andrew Lunn wrote:
> Could your produce a patch which contains all these changes and a
> ChangeLog entry in both the Kernel package and the HAL.

Done.


-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown

[-- Attachment #2: priorities-kernel.diff --]
[-- Type: text/plain, Size: 5375 bytes --]

Index: ChangeLog
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/arm/lpc2xxx/var/current/ChangeLog,v
retrieving revision 1.7
diff -u -r1.7 ChangeLog
--- ChangeLog	30 Jul 2007 18:09:47 -0000	1.7
+++ ChangeLog	22 Aug 2007 13:34:11 -0000
@@ -1,3 +1,13 @@
+2007-08-22  Hans Rosenfeld  <rosenfeld@grumpf.hope-2000.org>
+
+	* cdl/hal_arm_lpc2xxx.cdl: require interrupt priority 16 for
+	kernel test intr0/kintr0 interrupts
+
 2007-08-17  Hans Rosenfeld  <rosenfeld@grumpf.hope-2000.org>
 
 	* cdl/hal_arm_lpc2xxx.cdl: added VIC component to support
 	configuration of individual interrupt priorities
 
 2007_07-10  Uwe Kindler <uwe_kindler@web.de>
 
 	* cdl/hal_arm_lpc2xxx.cdl: Added option
Index: hal_arm_lpc2xxx.cdl
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/arm/lpc2xxx/var/current/cdl/hal_arm_lpc2xxx.cdl,v
retrieving revision 1.4
diff -u -r1.4 hal_arm_lpc2xxx.cdl
--- hal_arm_lpc2xxx.cdl	30 Jul 2007 18:09:47 -0000	1.4
+++ hal_arm_lpc2xxx.cdl	22 Aug 2007 13:37:42 -0000
@@ -66,6 +66,15 @@
     implements    CYGINT_HAL_ARM_ARCH_ARM7
     implements    CYGINT_HAL_ARM_THUMB_ARCH
 
+    requires { is_active(CYGNUM_KERNEL_INTR_TEST_PRIO_A)
+               implies CYGNUM_KERNEL_INTR_TEST_PRIO_A == 16 }
+    
+    requires { is_active(CYGNUM_KERNEL_INTR_TEST_PRIO_B)
+               implies CYGNUM_KERNEL_INTR_TEST_PRIO_B == 16 }
+
+    requires { is_active(CYGNUM_KERNEL_INTR_TEST_PRIO_C)
+               implies CYGNUM_KERNEL_INTR_TEST_PRIO_C == 16 }
+
     # Let the architectural HAL see this variant's files
     define_proc {
         puts $::cdl_header "#define CYGBLD_HAL_VAR_INTS_H <cyg/hal/hal_var_ints.h>"
Index: ChangeLog
===================================================================
RCS file: /cvs/ecos/ecos/packages/kernel/current/ChangeLog,v
retrieving revision 1.143
diff -u -r1.143 ChangeLog
--- ChangeLog	2 Jul 2007 11:49:09 -0000	1.143
+++ ChangeLog	22 Aug 2007 13:39:40 -0000
@@ -1,3 +1,8 @@
+2007-08-22  Hans Rosenfeld  <rosenfeld@grumpf.hope-2000.org>
+
+	* cdl/kernel.cdl, tests/intr0.cxx, tests/kintr0.c: added options
+	to configure priorities of the interrupts created by intr0 and kintr0
+
 2007-07-02  Gary Thomas  <gary@mlbassoc.com>
 
 	* src/debug/dbg_gdb.cxx: 
Index: intr0.cxx
===================================================================
RCS file: /cvs/ecos/ecos/packages/kernel/current/tests/intr0.cxx,v
retrieving revision 1.13
diff -u -r1.13 intr0.cxx
--- intr0.cxx	11 Aug 2006 09:29:31 -0000	1.13
+++ intr0.cxx	22 Aug 2007 13:40:08 -0000
@@ -97,7 +97,9 @@
 
 static bool flash( void )
 {
-    Cyg_Interrupt intr0 = Cyg_Interrupt(CYGNUM_HAL_ISR_MIN, 0, (CYG_ADDRWORD)333, isr0, dsr0 );
+    Cyg_Interrupt intr0 = Cyg_Interrupt(CYGNUM_HAL_ISR_MIN,
+                                        CYGNUM_KERNEL_INTR_TEST_PRIO_A,
+                                        (CYG_ADDRWORD)333, isr0, dsr0 );
 
     return true;
 }
@@ -134,13 +136,15 @@
     HAL_INTERRUPT_IN_USE( lvl1, in_use );
     Cyg_Interrupt* intr0 = NULL;
     if (!in_use)
-        intr0 = new((void *)&intr0_obj[0]) Cyg_Interrupt( lvl1, 1, (CYG_ADDRWORD)777, isr0, dsr0 );
+        intr0 = new((void *)&intr0_obj[0]) Cyg_Interrupt( lvl1, CYGNUM_KERNEL_INTR_TEST_PRIO_B,
+                                                          (CYG_ADDRWORD)777, isr0, dsr0 );
      
     cyg_vector lvl2 = CYGNUM_HAL_ISR_MIN + ( 15 % CYGNUM_HAL_ISR_COUNT);
     HAL_INTERRUPT_IN_USE( lvl2, in_use );
     Cyg_Interrupt* intr1 = NULL;
     if (!in_use && lvl1 != lvl2)
-        intr1 = new((void *)&intr1_obj[0]) Cyg_Interrupt( lvl2, 1, 888, isr1, dsr1 );
+        intr1 = new((void *)&intr1_obj[0]) Cyg_Interrupt( lvl2, CYGNUM_KERNEL_INTR_TEST_PRIO_C,
+                                                          888, isr1, dsr1 );
 
     // Check these functions at least exist
     Cyg_Interrupt::disable_interrupts();
Index: kintr0.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/kernel/current/tests/kintr0.c,v
retrieving revision 1.12
diff -u -r1.12 kintr0.c
--- kintr0.c	11 Aug 2006 09:29:31 -0000	1.12
+++ kintr0.c	22 Aug 2007 13:40:44 -0000
@@ -103,8 +103,8 @@
     cyg_handle_t handle;
     cyg_interrupt intr;
 
-    cyg_interrupt_create(CYGNUM_HAL_ISR_MIN, 0, (cyg_addrword_t)333, 
-                         isr0, dsr0, &handle, &intr );
+    cyg_interrupt_create(CYGNUM_HAL_ISR_MIN, CYGNUM_KERNEL_INTR_TEST_PRIO_A,
+                         (cyg_addrword_t)333, isr0, dsr0, &handle, &intr );
     cyg_interrupt_delete(handle);
 
     return true;
@@ -156,13 +156,14 @@
     HAL_INTERRUPT_IN_USE( lvl1, in_use );
     intr0 = 0;
     if (!in_use)
-        cyg_interrupt_create(lvl1, 1, (cyg_addrword_t)777, isr0, dsr0, 
-                             &intr0, &intr_obj[0]);
+        cyg_interrupt_create(lvl1, CYGNUM_KERNEL_INTR_TEST_PRIO_B, 
+                             (cyg_addrword_t)777, isr0, dsr0, &intr0, &intr_obj[0]);
     
     HAL_INTERRUPT_IN_USE( lvl2, in_use );
     intr1 = 0;
     if (!in_use && lvl1 != lvl2)
-        cyg_interrupt_create(lvl2, 1, 888, isr1, dsr1, &intr1, &intr_obj[1]);
+        cyg_interrupt_create(lvl2, CYGNUM_KERNEL_INTR_TEST_PRIO_C,
+                             888, isr1, dsr1, &intr1, &intr_obj[1]);
 
     // Check these functions at least exist
 


[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Getting started with ecos

[Scott Moore]

Hi, I just went through the install process. Can I make
A small suggestion?

The install instructions at:

http://ecos.sourceware.org/getstart.html

Don't actually work. Getting the current cygwin install, then
Installing the ecos source, etc, in exactly the order specified,
Will result in a config tool (graphical and command line) that
Has a bug that has (apparently) existed since 2003. Its true
that after looking around the ecoscentric links provided, I was
able to correct this, but after some waste of time.

I realize that work on ECOS has stopped, and perhaps creating a
Version that works with the current cygwin distribution might not
Be in the cards. However, would it not make sense to make it clear
On the instruction page above that you have to go get a fixed
Version of config to make it work?

Thanks,

Scott Moore

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Getting started with ecos

[Andrew Lunn]

> I realize that work on ECOS has stopped

The work on eCos has not stopped. It just appears the maintainer of
the GUI configuration tool is no longer active. 

All the power users of eCos don't use the GUI anyway. They prefer the
CLI tools. So i would recommend using that.

    Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Getting started with ecos

[Scott Moore]

The CLI tool is broken as well (as mentioned in the original post).

What is being suggested is simply to change the web page install
instructions, which don’t work.

Scott 

-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch] 
Sent: Wednesday, August 22, 2007 11:23 AM
To: Scott Moore
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Getting started with ecos

> I realize that work on ECOS has stopped

The work on eCos has not stopped. It just appears the maintainer of the GUI configuration tool is no longer active. 

All the power users of eCos don't use the GUI anyway. They prefer the CLI tools. So i would recommend using that.

    Andrew

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Getting started with ecos

[Andrew Lunn]

On Wed, Aug 22, 2007 at 02:48:41PM -0400, Scott Moore wrote:
> The CLI tool is broken as well (as mentioned in the original post).
> 
> What is being suggested is simply to change the web page install
> instructions, which don?t work.

I didn't realize the CLI tool as well was broken. OK i found the post
from Bart:

http://www.cygwin.com/ml/ecos-patches/2006-07/msg00011.html

I think for eCos 3.0 we need to decouple the host tools from eCos
itself. That would make it easier to provide new versions every time
cygwin breaks something. 

I guess it is also not helped by the fact that most, if not all, of
the maintainers don't use M$. I personally have no interest in
supporting the M$ tools.

     Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Getting started with ecos

[Scott Moore]

Ah, that clarifies a lot, thank you.

Scott 

-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch] 
Sent: Wednesday, August 22, 2007 12:33 PM
To: Scott Moore
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Getting started with ecos

On Wed, Aug 22, 2007 at 02:48:41PM -0400, Scott Moore wrote:
> The CLI tool is broken as well (as mentioned in the original post).
> 
> What is being suggested is simply to change the web page install 
> instructions, which don?t work.

I didn't realize the CLI tool as well was broken. OK i found the post from Bart:

http://www.cygwin.com/ml/ecos-patches/2006-07/msg00011.html

I think for eCos 3.0 we need to decouple the host tools from eCos itself. That would make it easier to provide new versions every time cygwin breaks something. 

I guess it is also not helped by the fact that most, if not all, of the maintainers don't use M$. I personally have no interest in supporting the M$ tools.

     Andrew

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Getting started with eCOS...

[Gary Thomas]

On Mon, 2005-04-04 at 19:18 +0530, Sarvex Jatasra wrote:
> Hi group.
> I am a new member if this group, and trying to learn eCOS. 
> 
> I started with downloading the eCOS source for CygWin on windows along
> with the ecos-elf-i386 tools. I ran the "configtool.exe" and was able to
> build the eCOS library. But I am not able to figure out how to generate
> the final executable and run it on my Pentium 4 processor. 

What final executable?  eCos comes in two parts - the kernel (library)
and your application.  You need to build an application using the 
library you've configured and built.

Have you read the "Getting Started" section of the online documentation?
It goes through this using the sample applications (in the .../examples
directory of the eCos sources).

You could also look at:
  http://www.mlbassoc.com/examples/build_hello.html
but it uses the command line configuration tool (I seldom use the GUI).
The principles are the same though.

Don't forget that to run a program on your x86 processor, you'll 
need some way of loading it - from FLOPPY or via RedBoot or GRUB.
You'll also need to set the startup type appropriately.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Getting started with eCOS...

[Sarvex Jatasra]

Hi group.
I am a new member if this group, and trying to learn eCOS. 

I started with downloading the eCOS source for CygWin on windows along
with the ecos-elf-i386 tools. I ran the "configtool.exe" and was able to
build the eCOS library. But I am not able to figure out how to generate
the final executable and run it on my Pentium 4 processor. 

This is a completely naïve question, but I am stuck with it. Please
provide me further directions on how to proceed with this. Any help is
highly appreciated. 

Sarvex Jatasra
Software Engineer
Acme Technologies

+91-9891989156
+91-9350933295 



--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss