[ECOS] General Q: Calling RedBoot CLI function from eCos app

[ECOS] General Q: Calling RedBoot CLI function from eCos app

[John Mills]

All -

I have an eCos app which is stored in FLASH, compressed, expanded into RAM 
for execution. I'm using RedBoot[ROM] as my environment. I would like to 
call the RedBoot CLI command "version" from my eCos app, then parse the 
returned results.

1. Is this possible, and
2. Where can I learn how to invoke the RedBoot function and to intercept 
its output?

TIA for background and guidance.

 - John Mills


-- 
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] General Q: Calling RedBoot CLI function from eCos app

[Gary Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Mills wrote:
> All -
> 
> I have an eCos app which is stored in FLASH, compressed, expanded into RAM 
> for execution. I'm using RedBoot[ROM] as my environment. I would like to 
> call the RedBoot CLI command "version" from my eCos app, then parse the 
> returned results.
> 
> 1. Is this possible, and
> 2. Where can I learn how to invoke the RedBoot function and to intercept 
> its output?

There is no [direct] support for calling RedBoot commands from eCos, sorry.

Just curious - what information are you interested in getting/parsing?  It
may be available some other way.

- --
- ------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGXa4TmaKbSsQGV8ARAjA7AJ9IzzmOg/KLZPz8OR7J58vKrc/ikQCfRQ6b
LcKC22AzwYuGTQUwEtPafaU=
=W/Vh
-----END PGP SIGNATURE-----

-- 
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] General Q: Calling RedBoot CLI function from eCos app

[Andrew Lunn]

Hi Gary

> > I have an eCos app which is stored in FLASH, compressed, expanded into RAM 
> > for execution. I'm using RedBoot[ROM] as my environment. I would like to 
> > call the RedBoot CLI command "version" from my eCos app, then parse the 
                                  ^^^^^^^

As far as im aware, it is not accessable via the VV.

   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] General Q: Calling RedBoot CLI function from eCos app

[Andrew Lunn]

On Wed, May 30, 2007 at 07:12:34PM +0200, Andrew Lunn wrote:
> Hi Gary
> 
> > > I have an eCos app which is stored in FLASH, compressed, expanded into RAM 
> > > for execution. I'm using RedBoot[ROM] as my environment. I would like to 
> > > call the RedBoot CLI command "version" from my eCos app, then parse the 
>                                   ^^^^^^^
> 
> As far as im aware, it is not accessable via the VV.

Upps. Now i need to correct myself.....

#include <cyg/hal/hal_if.>

    char *version = CYGACC_CALL_IF_MONITOR_VERSION();

probably works.

         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] General Q: Calling RedBoot CLI function from eCos app

[John Mills]

Andrew -

Thanks. I had stumbled on the corresponding 'hal_if.h' entry and was
hoping I could link it from eCos code.

 - John Mills

On Wed, 30 May 2007, Andrew Lunn wrote:

> On Wed, May 30, 2007 at 07:12:34PM +0200, Andrew Lunn wrote:

> > > > I have an eCos app which is stored in FLASH, compressed, expanded into RAM 
> > > > for execution. I'm using RedBoot[ROM] as my environment. I would like to 
> > > > call the RedBoot CLI command "version" from my eCos app, then parse the 

> > As far as im aware, it is not accessable via the VV.
> 
> Upps. Now i need to correct myself.....
> 
> #include <cyg/hal/hal_if.>
> 
>     char *version = CYGACC_CALL_IF_MONITOR_VERSION();


-- 
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] General Q: Calling RedBoot CLI function from eCos app

[John Mills]

Andrew -

Thanks for the lead, but in my eCos app that macro just expands to NULL.  
The same code line works perfectly in RedBoot's 'main.c', however.

I would also like to pass some of RedBoot's net-related config data to my 
app as well -- 'version' looked like a useful and relatively easy step in 
that direction.

Other ideas welcome, naturally.

 - John Mills

On Wed, 30 May 2007, Andrew Lunn wrote:

> #include <cyg/hal/hal_if.>
 
>     char *version = CYGACC_CALL_IF_MONITOR_VERSION();

      diag_printf(version);

> probably works.


-- 
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] General Q: Calling RedBoot CLI function from eCos app

[Andrew Lunn]

On Wed, May 30, 2007 at 02:11:43PM -0500, John Mills wrote:
> Andrew -
> 
> Thanks for the lead, but in my eCos app that macro just expands to NULL.  
> The same code line works perfectly in RedBoot's 'main.c', however.

What is the value of CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_VERSION in you
application? See hal/common/current/src/hal_if.c

             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] General Q: Calling RedBoot CLI function from eCos app

[John Mills]

Andrew -

Thanks for the reply.

On Wed, 30 May 2007, Andrew Lunn wrote:

> On Wed, May 30, 2007 at 02:11:43PM -0500, John Mills wrote:
> > Andrew -
> > 
> > Thanks for the lead, but in my eCos app that macro just expands to NULL.  
> > The same code line works perfectly in RedBoot's 'main.c', however.
> 
> What is the value of CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_VERSION in you
> application? See hal/common/current/src/hal_if.c

I find in my package configuration:

/home/jmills/depot/trapeze/ECOSBUILD/dist/install/include/pkgconf/hal.h:
 #define CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_VERSION 1

If I understand your track here, that would activate the following lines
in 'hal_if.c':

#ifdef CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_VERSION
    CYGACC_CALL_IF_MONITOR_VERSION_SET(0);
#endif

which, I suppose, would in turn cause
    CYGACC_CALL_IF_MONITOR_VERSION() to resolve as '0', or NULL.

Hence my <null> print string.

Is that sensible?

 - John


-- 
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] General Q: Calling RedBoot CLI function from eCos app

[Andrew Lunn]

On Wed, May 30, 2007 at 04:03:14PM -0500, John Mills wrote:
> Andrew -
> 
> Thanks for the reply.
> 
> On Wed, 30 May 2007, Andrew Lunn wrote:
> 
> > On Wed, May 30, 2007 at 02:11:43PM -0500, John Mills wrote:
> > > Andrew -
> > > 
> > > Thanks for the lead, but in my eCos app that macro just expands to NULL.  
> > > The same code line works perfectly in RedBoot's 'main.c', however.
> > 
> > What is the value of CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_VERSION in you
> > application? See hal/common/current/src/hal_if.c
> 
> I find in my package configuration:
> 
> /home/jmills/depot/trapeze/ECOSBUILD/dist/install/include/pkgconf/hal.h:
>  #define CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_VERSION 1
> 
> If I understand your track here, that would activate the following lines
> in 'hal_if.c':
> 
> #ifdef CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_VERSION
>     CYGACC_CALL_IF_MONITOR_VERSION_SET(0);
> #endif
> 
> which, I suppose, would in turn cause
>     CYGACC_CALL_IF_MONITOR_VERSION() to resolve as '0', or NULL.
> 
> Hence my <null> print string.
> 
> Is that sensible?

Yes, that is what i was thinking.  So the next question is why is it
set to 1?

            cdl_option CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_VERSION {
                display       "Claim version virtual vectors"
                default_value { CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE }
                description   "
                    This option will cause the version
                    virtual vectors to be claimed."
            }

Is CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE true?

            cdl_option CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE {
                display       "Initialize whole of virtual vector table"
                default_value { CYG_HAL_STARTUP != "RAM" || !CYGSEM_HAL_USE_ROM_MONITOR }
 
do you have a RAM image? Is CYGSEM_HAL_USE_ROM_MONITOR true?

   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] eCos configuration question (was Re: [ECOS] General Q ...)

[John Mills]

Leaving aside my responses to Andrew cut in below:

 1. How should I set or clear this switch in my *.ecc files? I don't
recognize the entry in 'configtool'. Should I edit the *.ecc and 
regenerate the tree? Edit the affected 'hal.h'?

 2. In general, is there a listing in eCos or RedBoot docs about these 
[fairly obscure] switches?

Thanks for any guidance.

 - Mills

On Wed, 30 May 2007, Andrew Lunn wrote:

> > On Wed, 30 May 2007, Andrew Lunn wrote:

> > > What is the value of CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_VERSION in you
> > > application? See hal/common/current/src/hal_if.c

> > I find in my package configuration:
  >/home/jmills/depot/trapeze/ECOSBUILD/dist/install/include/pkgconf/hal.h:
  >  #define CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_VERSION 1

> ...  So the next question is why is it set to 1?

  If it was a clear decision, the reasons are lost in the mists of time!

>             cdl_option CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_VERSION {
>                 display       "Claim version virtual vectors"
>                 default_value { CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE }
>                 description   "
>                     This option will cause the version
>                     virtual vectors to be claimed."
>             }


> Is CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE true?
  Yes:
  ../trapeze/ECOSBUILD/dist/install/include/pkgconf/hal.h:
    #define CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE 1

>             cdl_option CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE {
>                 display       "Initialize whole of virtual vector table"
>                 default_value { CYG_HAL_STARTUP != "RAM" ||
>                                 !CYGSEM_HAL_USE_ROM_MONITOR }
  
> do you have a RAM image?

  Not of RedBoot. Our eCos app is expanded into RAM for execution, but 
  RedBoot lives in FLASH.

> Is CYGSEM_HAL_USE_ROM_MONITOR true?
  Apparently not, if I 'grep'ed right.

 - John Mills


-- 
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] eCos configuration question (was Re: [ECOS] General Q ...)

[Gary Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Mills wrote:
> Leaving aside my responses to Andrew cut in below:
> 
>  1. How should I set or clear this switch in my *.ecc files? I don't
> recognize the entry in 'configtool'. Should I edit the *.ecc and 
> regenerate the tree? Edit the affected 'hal.h'?

You could edit the .ecc file and rerun 'ecosconfig tree'.  Editing the
hal.h file is useless as it may get regenerated.

More importantly, it would be useful to find out why this is being
set the way it is.  You can figure this out by reading the .ecc file.

> 
>  2. In general, is there a listing in eCos or RedBoot docs about these 
> [fairly obscure] switches?

Probably not much beyond the CDL files themselves.

Of course, if you want to contribute some documentation on the subject,
it would always be welcome :-)

> 
> Thanks for any guidance.
> 
>  - Mills
> 
> On Wed, 30 May 2007, Andrew Lunn wrote:
> 
>>> On Wed, 30 May 2007, Andrew Lunn wrote:
> 
>>>> What is the value of CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_VERSION in you
>>>> application? See hal/common/current/src/hal_if.c
> 
>>> I find in my package configuration:
>   >/home/jmills/depot/trapeze/ECOSBUILD/dist/install/include/pkgconf/hal.h:
>   >  #define CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_VERSION 1
> 
>> ...  So the next question is why is it set to 1?
> 
>   If it was a clear decision, the reasons are lost in the mists of time!
> 
>>             cdl_option CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_VERSION {
>>                 display       "Claim version virtual vectors"
>>                 default_value { CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE }
>>                 description   "
>>                     This option will cause the version
>>                     virtual vectors to be claimed."
>>             }
> 
> 
>> Is CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE true?
>   Yes:
>   ../trapeze/ECOSBUILD/dist/install/include/pkgconf/hal.h:
>     #define CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE 1
> 
>>             cdl_option CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE {
>>                 display       "Initialize whole of virtual vector table"
>>                 default_value { CYG_HAL_STARTUP != "RAM" ||
>>                                 !CYGSEM_HAL_USE_ROM_MONITOR }
>   
>> do you have a RAM image?
> 
>   Not of RedBoot. Our eCos app is expanded into RAM for execution, but 
>   RedBoot lives in FLASH.
> 
>> Is CYGSEM_HAL_USE_ROM_MONITOR true?
>   Apparently not, if I 'grep'ed right.
> 
>  - John Mills
> 
> 


- --
- ------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGXuM0maKbSsQGV8ARAtdAAJ9hypuhBhuEsph2vLkVuUy3MfyA4gCcDwx9
P6Z0n4Vxz+p3mVG1+A0jL88=
=meV8
-----END PGP SIGNATURE-----

-- 
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] eCos configuration question (was Re: [ECOS] General Q ...)

[John Mills]

Gary -

Thanks for the help.

On Thu, 31 May 2007, Gary Thomas wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> John Mills wrote:
> > Leaving aside my responses to Andrew cut in below:
> > 
> >  1. How should I set or clear this switch in my *.ecc files? I don't
> > recognize the entry in 'configtool'. Should I edit the *.ecc and 
> > regenerate the tree? Edit the affected 'hal.h'?
> 
> You could edit the .ecc file and rerun 'ecosconfig tree'.  Editing the
> hal.h file is useless as it may get regenerated.

> More importantly, it would be useful to find out why this is being
> set the way it is.  You can figure this out by reading the .ecc file.

Good point. In fact I seem to be picking at a minor side-effect of a 
rather general setting here, so I had better "expect the unexpected".

> >  2. In general, is there a listing in eCos or RedBoot docs about these 
> > [fairly obscure] switches?
> 
> Probably not much beyond the CDL files themselves.
> 
> Of course, if you want to contribute some documentation on the subject,
> it would always be welcome :-)

 So far, I don't even know enough to be very dangerous, much less very 
helpful!


-- 
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: eCos configuration question (was Re: [ECOS] General Q ...)

[Andrew Lunn]

On Thu, May 31, 2007 at 09:50:50AM -0500, John Mills wrote:
> Leaving aside my responses to Andrew cut in below:
> 
>  1. How should I set or clear this switch in my *.ecc files? I don't
> recognize the entry in 'configtool'. Should I edit the *.ecc and 
> regenerate the tree? Edit the affected 'hal.h'?

You should never need to edit a .h file. I personally never use the
gui tool. I find it much easier just to edit the ecos.ecc file and use
ecosconfig

> > Is CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE true?
>   Yes:
>   ../trapeze/ECOSBUILD/dist/install/include/pkgconf/hal.h:
>     #define CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE 1

I would expect this to be true for your Redboot true, but false for
you application tree. Look at your application ecos.ecc. Does it get
the value from the default_value statement, or has it been set by the
user_value? That will tell you if somebody has deliberately changed
it, or it is derived from other configuration settings.
 
> >             cdl_option CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE {
> >                 display       "Initialize whole of virtual vector table"
> >                 default_value { CYG_HAL_STARTUP != "RAM" ||
> >                                 !CYGSEM_HAL_USE_ROM_MONITOR }
>   
> > do you have a RAM image?
> 
>   Not of RedBoot. Our eCos app is expanded into RAM for execution, but 
>   RedBoot lives in FLASH.

So for your RedBoot tree CYG_HAL_STARTUP == ROM and for your
application tree CYG_HAL_STARTUP == RAM
 
> > Is CYGSEM_HAL_USE_ROM_MONITOR true?
>   Apparently not, if I 'grep'ed right.

I would expect this to be false for the RedBoot tree, but true for the
Application tree.

            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: eCos configuration question (was Re: [ECOS] General Q ...)

[Grant Edwards]

On 2007-05-31, Andrew Lunn <andrew@lunn.ch> wrote:
> On Thu, May 31, 2007 at 09:50:50AM -0500, John Mills wrote:
>> Leaving aside my responses to Andrew cut in below:
>> 
>>  1. How should I set or clear this switch in my *.ecc files? I
>>     don't recognize the entry in 'configtool'. Should I edit
>>     the *.ecc and regenerate the tree? Edit the affected
>>     'hal.h'?
>
> You should never need to edit a .h file. I personally never
> use the gui tool.

I don't think any of the "pros" do.  AFAICT, it's just
eye-candy to lessen the initial culture shock for Visual-C
programmers. ;)

> I find it much easier just to edit the ecos.ecc file and use
> ecosconfig

That's what I used to do, but I had a hard time keeping track
of what I had changed from the defaults.  Now I find it easiest
to write a shell script that creates a source tree.  It seems
like a bit of a hassle at first, but you're always sure what
you've got (all your tweaks are in one small file) and you're
always sure you can repeably generate the same source tree.

________________________________________________________________________
#!/bin/bash
set -x

ecosconfig new foobar net
ecosconfig remove CYGPKG_POSIX
ecosconfig add CYGPKG_IO_I2C
ecosconfig add CYGPKG_FOOBAR_DM2_I2CEEPROM

cat >.tmp$$.cdl <<EOF
cdl_option CYGSEM_HAL_DIAG_MANGLER              {user_value None}
cdl_option CYGPKG_IO_NFILE                      {user_value 256}
cdl_option CYGNUM_FILEIO_NFILE                  {user_value 256}
cdl_option CYGNUM_FILEIO_NFD                    {user_value 256}
cdl_option CYGPKG_NET_MAXSOCKETS                {user_value 256}
cdl_component CYGSEM_KERNEL_SCHED_TIMESLICE     {user_value 0}
cdl_option CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE {user_value 0x20}
cdl_option CYGPKG_NET_MEM_USAGE                 {user_value 0x260000}
cdl_option CYGPKG_NET_NUM_WAKEUP_EVENTS         {user_value 40}
cdl_option CYGPKG_NET_BUILD_HW_TESTS            {user_value 1}
cdl_option CYGPKG_NET_FREEBSD_INET6             {user_value 0}
EOF

echo
echo "Importing CDL settings:"
cat .tmp$$cdl
echo

ecosconfig import .tmp$$.cdl

ecosconfig tree
________________________________________________________________________


-- 
Grant Edwards                   grante             Yow! Half a mind is a
                                  at               terrible thing to waste!
                               visi.com            


-- 
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: eCos configuration question

[Sergei Organov]

Grant Edwards <grante@visi.com> writes:
> On 2007-05-31, Andrew Lunn <andrew@lunn.ch> wrote:
>> On Thu, May 31, 2007 at 09:50:50AM -0500, John Mills wrote:
>>> Leaving aside my responses to Andrew cut in below:
>>> 
>>>  1. How should I set or clear this switch in my *.ecc files? I
>>>     don't recognize the entry in 'configtool'. Should I edit
>>>     the *.ecc and regenerate the tree? Edit the affected
>>>     'hal.h'?
>>
>> You should never need to edit a .h file. I personally never
>> use the gui tool.
>
> I don't think any of the "pros" do.  AFAICT, it's just
> eye-candy to lessen the initial culture shock for Visual-C
> programmers. ;)
>
>> I find it much easier just to edit the ecos.ecc file and use
>> ecosconfig
>
> That's what I used to do, but I had a hard time keeping track
> of what I had changed from the defaults.  Now I find it easiest
> to write a shell script that creates a source tree.  It seems
> like a bit of a hassle at first, but you're always sure what
> you've got (all your tweaks are in one small file) and you're
> always sure you can repeably generate the same source tree.

>
> ________________________________________________________________________
> #!/bin/bash
> set -x
>
> ecosconfig new foobar net
> ecosconfig remove CYGPKG_POSIX
> ecosconfig add CYGPKG_IO_I2C
> ecosconfig add CYGPKG_FOOBAR_DM2_I2CEEPROM
>
> cat >.tmp$$.cdl <<EOF
> cdl_option CYGSEM_HAL_DIAG_MANGLER              {user_value None}
> cdl_option CYGPKG_IO_NFILE                      {user_value 256}
> cdl_option CYGNUM_FILEIO_NFILE                  {user_value 256}
> cdl_option CYGNUM_FILEIO_NFD                    {user_value 256}
> cdl_option CYGPKG_NET_MAXSOCKETS                {user_value 256}
> cdl_component CYGSEM_KERNEL_SCHED_TIMESLICE     {user_value 0}
> cdl_option CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE {user_value 0x20}
> cdl_option CYGPKG_NET_MEM_USAGE                 {user_value 0x260000}
> cdl_option CYGPKG_NET_NUM_WAKEUP_EVENTS         {user_value 40}
> cdl_option CYGPKG_NET_BUILD_HW_TESTS            {user_value 1}
> cdl_option CYGPKG_NET_FREEBSD_INET6             {user_value 0}
> EOF
>
> echo
> echo "Importing CDL settings:"
> cat .tmp$$cdl
> echo
>
> ecosconfig import .tmp$$.cdl
>
> ecosconfig tree

Yeah, I do almost the same, except I don't generate file to be imported
on the fly. "ecosconfig import custom.cdl" is indeed great tool! 

BTW, if one has edited 'ecos.ecc', he can get initial version of
'custom.cdl' by issuing:

$ ecosconfig check
$ ecosconfig tree
$ ecosconfig export custom.cdl

-- Sergei.


-- 
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: eCos configuration question (was Re: [ECOS] General Q ...)

[Paul D. DeRocco]

> From: Grant Edwards
> 
> I don't think any of the "pros" do.  AFAICT, it's just 
> eye-candy to lessen the initial culture shock for Visual-C 
> programmers. ;)

Other than just a hackish preference for command lines, is there anything
that ecosconfig can do that configtool can't? The latter seems pretty
useful, as it lets you see all the documentation on options that is
otherwise scattered around a million .cdl files.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com 


-- 
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: eCos configuration question (was Re: [ECOS] General Q ...)

[Gary Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul D. DeRocco wrote:
>> From: Grant Edwards
>>
>> I don't think any of the "pros" do.  AFAICT, it's just 
>> eye-candy to lessen the initial culture shock for Visual-C 
>> programmers. ;)
> 
> Other than just a hackish preference for command lines, is there anything
> that ecosconfig can do that configtool can't? The latter seems pretty
> useful, as it lets you see all the documentation on options that is
> otherwise scattered around a million .cdl files.
> 

I for one rarely do anything that I can't script.  ecosconfig
works perfectly for this, the configtool does not.  For example,
I may build as many as 128 (or more) versions of RedBoot at
one time, each requiring its own configuration, build tree, etc.
If I *had* to do this with the GUI, I'd never get my work done!

- --
- ------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGXwTLmaKbSsQGV8ARAlEZAJ0elS7bIcQJzMakGbnjmG525LtbQgCeJVxx
qq5xo4CJKVxOdYoOt0dz1GQ=
=wt5f
-----END PGP SIGNATURE-----

-- 
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: eCos configuration question (was Re: [ECOS] General Q ...)

[Grant Edwards]

On 2007-05-31, Gary Thomas <gary@mlbassoc.com> wrote:

>> Other than just a hackish preference for command lines, is there anything
>> that ecosconfig can do that configtool can't? The latter seems pretty
>> useful, as it lets you see all the documentation on options that is
>> otherwise scattered around a million .cdl files.
>
> I for one rarely do anything that I can't script.  ecosconfig
> works perfectly for this, the configtool does not.  For example,
> I may build as many as 128 (or more) versions of RedBoot at
> one time, each requiring its own configuration, build tree, etc.
> If I *had* to do this with the GUI, I'd never get my work done!

While I don't have to do 128 versions of anything, I do have to
do 3 or 4 versions at a time, and using the GUI would still
take forever.  As far as documentation goes, I find that when
throubleshooting a configuration, as often as not I want to see
not only the description, but the actual CDL.

-- 
Grant Edwards                   grante             Yow! ... I want FORTY-TWO
                                  at               TRYNEL FLOATATION SYSTEMS
                               visi.com            installed within SIX AND A
                                                   HALF HOURS!!!


-- 
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: eCos configuration question (was Re: [ECOS] General Q ...)

[Andrew Lunn]

On Thu, May 31, 2007 at 10:17:49AM -0700, Paul D. DeRocco wrote:
> > From: Grant Edwards
> > 
> > I don't think any of the "pros" do.  AFAICT, it's just 
> > eye-candy to lessen the initial culture shock for Visual-C 
> > programmers. ;)
> 
> Other than just a hackish preference for command lines, is there anything
> that ecosconfig can do that configtool can't? 

You are forgetting the unix philosophy. It is not configtool vs
ecosconfig, it is configtool vs ecosconfig+emacs+vim+sed+grep+awk+bash.....

Being able to combine these together gives you something very
flexible, powerful, and extensible.

> The latter seems pretty useful, as it lets you see all the
> documentation on options that is otherwise scattered around a
> million .cdl files.

The document for all loaded packages is in the ecos.ecc file. So you
can use more,less,emacs,vim etc to display and probably more
importantly, search it.

             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] eCos configuration question (was Re: [ECOS] General Q ...)

[Sergei Gavrikov]

On Thu, May 31, 2007 at 09:50:50AM -0500, John Mills wrote:
> Leaving aside my responses to Andrew cut in below:
> 
>  1. How should I set or clear this switch in my *.ecc files? I don't
> recognize the entry in 'configtool'. Should I edit the *.ecc and 
> regenerate the tree? Edit the affected 'hal.h'?
> 
>  2. In general, is there a listing in eCos or RedBoot docs about these 
> [fairly obscure] switches?

I don't use 'configtool' too (I don't know why that was written using
'wxwin' instead 'Tk', I said about :-). So, using 'ecosconfig' every
time, I did find in those days that I edit a few options in ecos.ecc or
even one option!. I decided to keep these recepts (tweaks) in one place:
~/Projects/ecos/ecm (mine). 

I keep such u-ECM (micro ECM) recepts there. I have about 15 recepts for
_my_ target(s).  For example, there is my FGETS.ECM ('fgets' issue,
Thanks Andrew!) in that place.  Sometimes, for example, I need in CLI
(!kernel) program to build an interpreter, so I build 'libtarget.a' as

  ecosconfig new <target> default
  ecosconfig import ~/Projects/ecos/ecm/FGETS.ECM
  ecosconfig tree
  ...

To use bash [TAB complete] on '~/Projects/ecos/ecm' is mean looking for
some recept. I gave them clever names :-)

What that my  FGETS.ECM, for example? That is just 3 lines

#-------------------------------------------------------------->8
cdl_option CYGDAT_IO_SERIAL_TTY_CONSOLE {user_value "\"/dev/tty0\""};
cdl_component CYGPKG_IO_SERIAL_TTY_TTY0 {user_value 1};
cdl_component CYGPKG_IO_SERIAL_DEVICES {user_value 1};
#-------------------------------------------------------------->8

Note: This FGETS.ECM isn't common recept. It's a target related tweak.
      There is /dev/tty0 (my choice) there.

But another tweak is 1-line recept (ROMSTART.ECM) is common recept for
most of us

#-------------------------------------------------------------->8
cdl_component CYG_HAL_STARTUP {user_value ROM};
#-------------------------------------------------------------->8

Etc. ;-)

I think you get the messager, I think, if an 'ecosconfig' syntax would
allows such call

  ecosconfig import - ;# i.e. import 'Tcl lines' = CDLs from stdin

I will like such things

  cat <<_EOF | ecosconfig import -
  # Fine recept to do ...
  cdl_option ...
  cdl_option ...
  _EOF

By same way, it will be easy to "patch" default ecos.ecc by a few of
recepts (tweaks?)

  cat tweak1.ecm tweak2.ecm tweak3.ecm | ecosconfig import -

Well, I think a described here isn't issue for most of young men. But
through months, I think, Stop! I did it, but what I did edit in those
days?!

kind regards,

-- Sergei


-- 
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: eCos configuration question

[Daniel Néri]

Sergei Gavrikov <w3sg@SoftHome.net> writes:

> I think you get the messager, I think, if an 'ecosconfig' syntax would
> allows such call
>
>   ecosconfig import - ;# i.e. import 'Tcl lines' = CDLs from stdin

I once hacked my ecosconfig to add that feature, but I no longer use
it since

   ecosconfig import /dev/stdin

works just as well (on the host platforms I care about).


Best wishes,
-- 
Daniel Néri <daniel.neri@sigicom.se>
Sigicom AB, Stockholm, Sweden


-- 
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: eCos configuration question

[Sergei Gavrikov]

Daniel Néri wrote:
> Sergei Gavrikov <w3sg@SoftHome.net> writes:
> 
> > I think you get the messager, I think, if an 'ecosconfig' syntax would
> > allows such call
> >
> >   ecosconfig import - ;# i.e. import 'Tcl lines' = CDLs from stdin
> 
> I once hacked my ecosconfig to add that feature, but I no longer use
> it since
> 
>    ecosconfig import /dev/stdin
> 
> works just as well (on the host platforms I care about).

That really works! Thanks for your great TIP!

Sergei

> 
> 
> Best wishes,
> -- 
> Daniel Néri <daniel.neri@sigicom.se>
> Sigicom AB, Stockholm, Sweden
> 
> 


-- 
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: eCos configuration question

[Grant Edwards]

On 2007-06-01, Sergei Gavrikov <w3sg@SoftHome.net> wrote:
> Daniel Néri wrote:
>> Sergei Gavrikov <w3sg@SoftHome.net> writes:
>> 
>> > I think you get the messager, I think, if an 'ecosconfig' syntax would
>> > allows such call
>> >
>> >   ecosconfig import - ;# i.e. import 'Tcl lines' = CDLs from stdin
>> 
>> I once hacked my ecosconfig to add that feature, but I no longer use
>> it since
>> 
>>    ecosconfig import /dev/stdin
>> 
>> works just as well (on the host platforms I care about).
>
> That really works! Thanks for your great TIP!

The more general case is to use /proc/self/fd/N (where N is the
file descriptor number).  If you look, /dev/stdin is just an
indirect symlink to /proc/self/fd/0

-- 
Grant Edwards                   grante             Yow! ... My pants just went
                                  at               on a wild rampage through a
                               visi.com            Long Island Bowling Alley!!


-- 
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: eCos configuration question

[Gary Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Grant Edwards wrote:
> On 2007-06-01, Sergei Gavrikov <w3sg@SoftHome.net> wrote:
>> Daniel Néri wrote:
>>> Sergei Gavrikov <w3sg@SoftHome.net> writes:
>>>
>>>> I think you get the messager, I think, if an 'ecosconfig' syntax would
>>>> allows such call
>>>>
>>>>   ecosconfig import - ;# i.e. import 'Tcl lines' = CDLs from stdin
>>> I once hacked my ecosconfig to add that feature, but I no longer use
>>> it since
>>>
>>>    ecosconfig import /dev/stdin
>>>
>>> works just as well (on the host platforms I care about).
>> That really works! Thanks for your great TIP!
> 
> The more general case is to use /proc/self/fd/N (where N is the
> file descriptor number).  If you look, /dev/stdin is just an
> indirect symlink to /proc/self/fd/0
> 

Perhaps on Linux, but on other *nix systems, /dev/stdin may
not be implemented this way.

- --
- ------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGYC1qmaKbSsQGV8ARAmCRAJwNbae3RuawENDGfobKDG0AKMv/XQCePvRI
SM0wZ9lrNcBnQD72bn/aCH0=
=c2zR
-----END PGP SIGNATURE-----

-- 
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: eCos configuration question

[Grant Edwards]

On 2007-06-01, Gary Thomas <gary@mlbassoc.com> wrote:

>>>>>   ecosconfig import - ;# i.e. import 'Tcl lines' = CDLs from stdin
>>>> I once hacked my ecosconfig to add that feature, but I no longer use
>>>> it since
>>>>
>>>>    ecosconfig import /dev/stdin
>>>>
>>>> works just as well (on the host platforms I care about).
>>> That really works! Thanks for your great TIP!
>> 
>> The more general case is to use /proc/self/fd/N (where N is the
>> file descriptor number).  If you look, /dev/stdin is just an
>> indirect symlink to /proc/self/fd/0
>
> Perhaps on Linux, but on other *nix systems, /dev/stdin may
> not be implemented this way.

There are other *nix systems?

;)

-- 
Grant Edwards                   grante             Yow! It's OKAY -- I'm an
                                  at               INTELLECTUAL, too.
                               visi.com            


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