[ECOS] In-built shell for Redboot

[ECOS] In-built shell for Redboot

[Harish Talanki]

eCos Experts,
  Is there a way I can invoke a function call directly from the shell,
with Redboot boot loader.
I want to add bunch of function calls to the code, and be able to
directly invoke them from
command line. Is there any package or configuration option I need to
choose?

  Right now I keep adding new Redboot Commands, to get arround this.

  Any suggestions/pointers would be great.

Thanks,


-- 
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] In-built shell for Redboot

[Andrew Lunn]

On Tue, Jan 30, 2007 at 02:09:52PM -0700, Harish Talanki wrote:
> eCos Experts,
>   Is there a way I can invoke a function call directly from the shell,
> with Redboot boot loader.

> I want to add bunch of function calls to the code, and be able to
> directly invoke them from
> command line. Is there any package or configuration option I need to
> choose?
> 
>   Right now I keep adding new Redboot Commands, to get arround this.

What is the difference between adding a redboot command and calling a
function? All a redboot command does is call a function.

          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] In-built shell for Redboot

[wang cui]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 1955 bytes --]

I think he want to call function by name directly without a warpper of 
"RedBoot_cmd()" macro.

Actually VxWorks provide this function. It strips all symbles from 
application image, then generate a source file contains all symbles, then 
add it into project and rebuild it. Then user can call all functions 
directly from VxWorks shell.
However, I think Redboot style is good enough.

But what I am thinking about is: Can we divide the shell functionality from 
Redboot and create a new package(suppose to be RedShell)?
Because we always need a shell in application, and there are very many 
things have been implemented in Redboot. If so, we can reduce a lot of work 
in writing application shell.

>From: Andrew Lunn <andrew@lunn.ch>
>To: Harish Talanki <htalanki@comtechefdata.com>
>CC: ecos-discuss@ecos.sourceware.org
>Subject: Re: [ECOS] In-built shell for Redboot
>Date: Tue, 30 Jan 2007 22:46:25 +0100
>
>On Tue, Jan 30, 2007 at 02:09:52PM -0700, Harish Talanki wrote:
> > eCos Experts,
> >   Is there a way I can invoke a function call directly from the shell,
> > with Redboot boot loader.
>
> > I want to add bunch of function calls to the code, and be able to
> > directly invoke them from
> > command line. Is there any package or configuration option I need to
> > choose?
> >
> >   Right now I keep adding new Redboot Commands, to get arround this.
>
>What is the difference between adding a redboot command and calling a
>function? All a redboot command does is call a function.
>
>           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
>

_________________________________________________________________
Ãâ·ÑÏÂÔØ MSN Explorer:   http://explorer.msn.com/lccn/  


-- 
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] In-built shell for Redboot

[Andrew Lunn]

On Thu, Feb 01, 2007 at 01:56:43AM +0000, wang cui wrote:
> I think he want to call function by name directly without a warpper of 
> "RedBoot_cmd()" macro.
> 
> Actually VxWorks provide this function. It strips all symbles from 
> application image, then generate a source file contains all symbles, then 
> add it into project and rebuild it. Then user can call all functions 
> directly from VxWorks shell.
> However, I think Redboot style is good enough.
> 
> But what I am thinking about is: Can we divide the shell functionality from 
> Redboot and create a new package(suppose to be RedShell)?
> Because we always need a shell in application, and there are very many 
> things have been implemented in Redboot. If so, we can reduce a lot of work 
> in writing application shell.

A lot of people have talked about shells, but nobody has ever written
a nice, clean, extendable shell package. What needs to happen is
somebody needs to write down a design of such a package and ask for
comments. Then implement it and again ask for comments.

          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] In-built shell for Redboot

[Harish Talanki]

Yes, vxWorks does it, and its convinience for run-time debugging &
examining of various tasks. Most of the time, we include debug symbols
during
development, and take them out completely for production. Having this
form
of shell environment make it easy to debug in runtime system,
especially 
for networking apps.

My thanks to everyone for your valuable suggestion.

>>> "wang cui" <iucgnaw@msn.com> 01/31/07 6:56 PM >>>
I think he want to call function by name directly without a warpper of

"RedBoot_cmd()" macro.

Actually VxWorks provide this function. It strips all symbles from 
application image, then generate a source file contains all symbles,
then 
add it into project and rebuild it. Then user can call all functions 
directly from VxWorks shell.
However, I think Redboot style is good enough.

But what I am thinking about is: Can we divide the shell functionality
from 
Redboot and create a new package(suppose to be RedShell)?
Because we always need a shell in application, and there are very many

things have been implemented in Redboot. If so, we can reduce a lot of
work 
in writing application shell.

>From: Andrew Lunn <andrew@lunn.ch>
>To: Harish Talanki <htalanki@comtechefdata.com>
>CC: ecos-discuss@ecos.sourceware.org 
>Subject: Re: [ECOS] In-built shell for Redboot
>Date: Tue, 30 Jan 2007 22:46:25 +0100
>
>On Tue, Jan 30, 2007 at 02:09:52PM -0700, Harish Talanki wrote:
> > eCos Experts,
> >   Is there a way I can invoke a function call directly from the
shell,
> > with Redboot boot loader.
>
> > I want to add bunch of function calls to the code, and be able to
> > directly invoke them from
> > command line. Is there any package or configuration option I need
to
> > choose?
> >
> >   Right now I keep adding new Redboot Commands, to get arround
this.
>
>What is the difference between adding a redboot command and calling a
>function? All a redboot command does is call a function.
>
>           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 
>

_________________________________________________________________
???? MSN Explorer:   http://explorer.msn.com/lccn/  



-- 
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] In-built shell for Redboot

[Sergei Gavrikov]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3801 bytes --]



On Thu, 1 Feb 2007, wang cui wrote:

> I think he want to call function by name directly without a warpper of
> "RedBoot_cmd()" macro.
>
> Actually VxWorks provide this function. It strips all symbles from
> application image, then generate a source file contains all symbles,
> then add it into project and rebuild it. Then user can call all
> functions directly from VxWorks shell.  However, I think Redboot style
> is good enough.
>
> But what I am thinking about is: Can we divide the shell functionality
> from Redboot and create a new package(suppose to be RedShell)?
> Because we always need a shell in application, and there are very many
> things have been implemented in Redboot. If so, we can reduce a lot of
> work in writing application shell.
>

Would we like to follow the subject "In-built shell for RedBoot" ...

Ah, this idea does scratch the RedBoot body (or spirit? :)! I saw/see
neither LiloShell nor GrubShell, but, with TAB button on LILO start,
for example, it's possible to select an `init' process as a parameter.
Sometimes, they add to parameters 'init=/bin/sh'. It looks like that
it's possible to add same choice on RedBoot startup to replace default
RedBoot's CLI loop. It would be a cool feature, but, what do they
(RedBoot experts) think about?

Though, looking the RedBoot's 'cyg_start' entry, it seems that was done.
There is one conditional call of the 'cyg_plf_redboot_startup' there. That
piece has been called before a start of the RedBoot's event loop, while
(true) {...}. And RedBoot had madden a lot of initial work (all needed
things for most of us) since a reset. More that, RedBoot gives us an
abstract I/O with virtual channels (serial, ethernet), TFTP/HTTP clients,
FLASH support, etc. Therefore, everybody can just put his own event loop
in his own redboot platform startup function and using the '_rb_gets'
will have a fun with a lovely interpreter (= shell).

I had a fun with an embedded Tcl shell in RedBoot from that point, for
example.  Though, there was 'malloc' evil there. Another limitation of
such "In-built shell for Redboot", there won't be any kernel things there.
But, for some tasks that's a solution.  Ah, if I would have an objloader
for ARM like Anthnony has for PowerPC (services/objloader) ...

There is yet another issue with such a tweak, that's the RedBoot's
'do_version' call. We cannot hide the RedHat's copyright notice, can we?

Sergei

>> From: Andrew Lunn <andrew@lunn.ch>
>> To: Harish Talanki <htalanki@comtechefdata.com>
>> CC: ecos-discuss@ecos.sourceware.org
>> Subject: Re: [ECOS] In-built shell for Redboot
>> Date: Tue, 30 Jan 2007 22:46:25 +0100
>> 
>> On Tue, Jan 30, 2007 at 02:09:52PM -0700, Harish Talanki wrote:
>> > eCos Experts,
>> >   Is there a way I can invoke a function call directly from the shell,
>> > with Redboot boot loader.
>> 
>> > I want to add bunch of function calls to the code, and be able to
>> > directly invoke them from
>> > command line. Is there any package or configuration option I need to
>> > choose?
>> >
>> >   Right now I keep adding new Redboot Commands, to get arround this.
>> 
>> What is the difference between adding a redboot command and calling a
>> function? All a redboot command does is call a function.
>>
>>           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
>> 
>
> _________________________________________________________________
> цБ╥яобть MSN Explorer:   http://explorer.msn.com/lccn/ 
>
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>

[-- Attachment #2: 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

Re: [ECOS] In-built shell for Redboot

[wang cui]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 2343 bytes --]

I am not a expert in Shell technology, but I'd like to see a general 
purpose shell functionality can be used both in Redboot and app. :-)
Andrew described many necessary requirement of shell in another mail, I 
strongly agree with him.
Could we port a common shell from GNU world? That will be fantastic.

>
>Would we like to follow the subject "In-built shell for RedBoot" ...
>
>Ah, this idea does scratch the RedBoot body (or spirit? :)! I 
>saw/see
>neither LiloShell nor GrubShell, but, with TAB button on LILO start,
>for example, it's possible to select an `init' process as a 
>parameter.
>Sometimes, they add to parameters 'init=/bin/sh'. It looks like that
>it's possible to add same choice on RedBoot startup to replace 
>default
>RedBoot's CLI loop. It would be a cool feature, but, what do they
>(RedBoot experts) think about?
>
>Though, looking the RedBoot's 'cyg_start' entry, it seems that was 
>done.
>There is one conditional call of the 'cyg_plf_redboot_startup' 
>there. That
>piece has been called before a start of the RedBoot's event loop, 
>while
>(true) {...}. And RedBoot had madden a lot of initial work (all 
>needed
>things for most of us) since a reset. More that, RedBoot gives us an
>abstract I/O with virtual channels (serial, ethernet), TFTP/HTTP 
>clients,
>FLASH support, etc. Therefore, everybody can just put his own event 
>loop
>in his own redboot platform startup function and using the 
>'_rb_gets'
>will have a fun with a lovely interpreter (= shell).
>
>I had a fun with an embedded Tcl shell in RedBoot from that point, 
>for
>example.  Though, there was 'malloc' evil there. Another limitation 
>of
>such "In-built shell for Redboot", there won't be any kernel things 
>there.
>But, for some tasks that's a solution.  Ah, if I would have an 
>objloader
>for ARM like Anthnony has for PowerPC (services/objloader) ...
>
>There is yet another issue with such a tweak, that's the RedBoot's
>'do_version' call. We cannot hide the RedHat's copyright notice, can 
>we?
>
>Sergei
>

_________________________________________________________________
ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£  http://www.hotmail.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] In-built shell for Redboot

[Gary Thomas]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=GB2312, Size: 2889 bytes --]

wang cui wrote:
> I am not a expert in Shell technology, but I'd like to see a general 
> purpose shell functionality can be used both in Redboot and app. :-)
> Andrew described many necessary requirement of shell in another mail, I 
> strongly agree with him.
> Could we port a common shell from GNU world? That will be fantastic.

Sorry, we've been round this bend before.  A generic shell (bash or
whatnot) does not make sense for eCos as there is no notion of programs,
or of forking, or of ...  It's simply not the right tool.

If you need functionality like this, run Linux.

> 
>>
>> Would we like to follow the subject "In-built shell for RedBoot" ...
>>
>> Ah, this idea does scratch the RedBoot body (or spirit? :)! I saw/see
>> neither LiloShell nor GrubShell, but, with TAB button on LILO start,
>> for example, it's possible to select an `init' process as a parameter.
>> Sometimes, they add to parameters 'init=/bin/sh'. It looks like that
>> it's possible to add same choice on RedBoot startup to replace default
>> RedBoot's CLI loop. It would be a cool feature, but, what do they
>> (RedBoot experts) think about?
>>
>> Though, looking the RedBoot's 'cyg_start' entry, it seems that was done.
>> There is one conditional call of the 'cyg_plf_redboot_startup' there. 
>> That
>> piece has been called before a start of the RedBoot's event loop, while
>> (true) {...}. And RedBoot had madden a lot of initial work (all needed
>> things for most of us) since a reset. More that, RedBoot gives us an
>> abstract I/O with virtual channels (serial, ethernet), TFTP/HTTP clients,
>> FLASH support, etc. Therefore, everybody can just put his own event loop
>> in his own redboot platform startup function and using the '_rb_gets'
>> will have a fun with a lovely interpreter (= shell).
>>
>> I had a fun with an embedded Tcl shell in RedBoot from that point, for
>> example.  Though, there was 'malloc' evil there. Another limitation of
>> such "In-built shell for Redboot", there won't be any kernel things 
>> there.
>> But, for some tasks that's a solution.  Ah, if I would have an objloader
>> for ARM like Anthnony has for PowerPC (services/objloader) ...
>>
>> There is yet another issue with such a tweak, that's the RedBoot's
>> 'do_version' call. We cannot hide the RedHat's copyright notice, can we?
>>
>> Sergei
>>
> 
> _________________________________________________________________
> ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£  http://www.hotmail.com 
> 


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

RE: [ECOS] In-built shell for Redboot

[Chris Zimman]

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

> A lot of people have talked about shells, but nobody has ever written
> a nice, clean, extendable shell package. What needs to happen is
> somebody needs to write down a design of such a package and ask for
> comments. Then implement it and again ask for comments.

I sent this out originally and never heard back from anyone -- I'm game
for feedback.  It uses a command definition structure similar to
Redboot.

If you don't see the attachment on here for whatever reason, please let
me know and I can send it individually.

--Chris

-----Original Message-----
From: Chris Zimman 
Sent: 24 October 2006 19:19
To: ecos-discuss@ecos.sourceware.org
Subject: eCos shell

A bunch of people had asked me for this a while back.  I had been really
busy, but finally just took the time to sit down and pack this thing up.
It's a simple shell that we've used for some projects, but it has been
flexible enough to allow us to do everything we want while remaining
simple.  I also included some thread wrappers that we've found pretty
useful and a 'ps' for eCos.

There's a README in the file that should be enough to get people going.

--Chris

[-- Attachment #2: shell_export.tar.bz2 --]
[-- Type: application/octet-stream, Size: 13114 bytes --]

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

Re: [ECOS] In-built shell for Redboot

[Andrew Lunn]

> I sent this out originally and never heard back from anyone -- I'm game
> for feedback.  It uses a command definition structure similar to
> Redboot.

Hi Chris 

I took a look at this code when you first posted it. If i remember
correctly there were a few things i didn't like, or at least would
require some work. 

1) It is not an eCos package.  Well in fact i think it should be two
   packages. The shell frame work and your standard commands.

2) I don't like the idea of the thread wrapper. Is this actually
   necessary for the shell? I would remove it if not.

3) You are only allowed one shell. It also seems not so easy to change
   the implementation to support multiple shells. I think this is
   important. I expect people might want to run one on a serial port
   and another on a network port. So you need some way to tell
   SHELL_PRINT which shell to print to etc.

4) I don't particularly like the SHELL_PRINT macros. I would prefer
   real functions, with cyg_ prefixes. They also seem to be in a funny
   place, shell_err.h?

5) You need to abstract out the opening/writing/reading/closing the
   communication pipe from the rest of the shell. It then becomes
   easier to implement a shell on a telnet port, a shell on an SSH
   port, a shell on two tins cans and a piece of string.
              
I know these were not goals of your design, so you did not think about
them. However i think it is necessary to at least address these issues
in a flexible shell framework for any code which gets committed to
anoncvs.

        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] In-built shell for Redboot

[Chris Zimman]

Hi Andrew

(1)  I could make it a package, but it was pulled out of a much larger
piece of code, and hadn't as of yet.  Feel free if you wish.

(2)  The thread wrappers have nothing to do with the shell itself, but
they do provide something very useful (to us at least).  They give a
sort of 'process emulation'.  When you create a thread using the
wrappers, when it exits, it automatically gets cleaned up.

(3)  Yes, it doesn't support multiple shells, but this wouldn't be
terribly hard to add.

(4)  I would rather have macros because I can conditionally compile
stuff out that I don't want without the overhead of having to go into a
function to check eg.

Cyg_xxxxxxx_printf()
{
	if(!debug_enabled) return;

	...
}

Rather, in our code, we could say:

SHELL_DEBUG_PRINT(....)

etc.

And just by either having -DDEBUG or not, we could turn on all kinds of
debugging output and have it stripped for release.

GCC supports variadic macros just fine as far as I can tell, so I don't
see a huge downside.

(5)  I agree, that would be useful

In general, I didn't have the idea of adding a fully fledged shell to
eCos, but rather, we needed something simple that we could interact with
the target platform under.  That's what this provided.

I'm just providing this in case anyone wants to use it, it served our
purposes fine.  If someone wants to write a better and/or more full
fledged shell, by all means do so, but in the mean time, this may prove
useful to some people.

--Chris

-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch] 
Sent: 01 February 2007 11:41
To: Chris Zimman
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] In-built shell for Redboot

> I sent this out originally and never heard back from anyone -- I'm
game
> for feedback.  It uses a command definition structure similar to
> Redboot.

Hi Chris 

I took a look at this code when you first posted it. If i remember
correctly there were a few things i didn't like, or at least would
require some work. 

1) It is not an eCos package.  Well in fact i think it should be two
   packages. The shell frame work and your standard commands.

2) I don't like the idea of the thread wrapper. Is this actually
   necessary for the shell? I would remove it if not.

3) You are only allowed one shell. It also seems not so easy to change
   the implementation to support multiple shells. I think this is
   important. I expect people might want to run one on a serial port
   and another on a network port. So you need some way to tell
   SHELL_PRINT which shell to print to etc.

4) I don't particularly like the SHELL_PRINT macros. I would prefer
   real functions, with cyg_ prefixes. They also seem to be in a funny
   place, shell_err.h?

5) You need to abstract out the opening/writing/reading/closing the
   communication pipe from the rest of the shell. It then becomes
   easier to implement a shell on a telnet port, a shell on an SSH
   port, a shell on two tins cans and a piece of string.
              
I know these were not goals of your design, so you did not think about
them. However i think it is necessary to at least address these issues
in a flexible shell framework for any code which gets committed to
anoncvs.

        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