Re: [ECOS] VxWorks type embedded "shell" for eCos

[Eric Donnat <e dot donnat at silicomp dot fr>]

On Fri, 6 Feb 2004 11:33:59 -0500 (EST)
Mark Grosberg <mark@nolab.conman.org> wrote:

>
> How about having the shell use the GDB stubs then?
>

After checking a "number of conditions" in any code, shell included, a program can get in the GDB stubs (while(1) HAL_BREAKPOINT). The only matter is the "impact" of such entering to the world of RedBoot on IT handling.

If breaking on an "IDLE" state is no matter: an interesting point is
that until there is no "cont" packet on the wire the current pointer
is usually unchanged, but just by "load". And of course all of this is
true for the app memory.
 
> I think the only thing that GDB can't readily do is download code at
> runtime to a running target (although I could be mistaken about that).
> this could be done by writing a different front end for the GDB stubs,
> then I'm all for it.
> 

Note that from inside a gdb function script, you can send orders to the
GDB stubs, that are "unspecified", i.e. stubs defined. 

With gdb6, I were told that the reverse can be done for file loading.
(the stubs requesting data-file from the hosts).

Everything is almost available in the tools, and much more !

There is even a trick for loading before a gdb6. Here is the overview
line.

1/ hitting HAL_BREAKPOINT from a defined convention.
2/ gdb has been previously attached to the target (similar to attaching
   RedBoot). If not, it is attached at this point. It's current FILE
   context is at least pointing to "mainstream kernel/redboot". In order    to get VV for instance.
3/ gdb order modification of a variable in the VV in order to prevent
   the stubs to corrupting the "critical context".... well a lot need
   to be investigated on that point sure ! Or fetching this "context".
   At least "PC" is of significant importance here.
4/ file "your new file that is an extend of the mainstream kernel.elf"
   (previously build with -Wl,--just-symbols,..... and others .ld ...)
5/ load -> Dynamically loaded.
6/ changing/resetting some values. for instance restoring "PC=PC+xx".
7/ give the mainstream breaked routine the pointer value of the entry pointer loaded, and other datas. (in the VV ?)
8/ add-symbol-file the mainstream kernel.
9/ cont.

encapsulating such a scheme in a gdb defined sequence is trivial,
the gdb scripting facilities may to even more smarter hacks. Gurus
might even know how to get a trick with relocatable thing.

> The tricky part about loading code dynamically is that not all of the eCos
> routines are present in the target; so loaded code may need an OS routine
> that isn't there.

So loading a binary stream is not so tricky, IMHO.
Pre-allocating a certain ABI (a set of "syscall" that need to be in kernel) is also easy. Check for -Wl,--undefined and/or other forcing
linking of abi.S specially made file.

> 
> VxWorks solves this by using config.h to force linking of OS modules in
> the target binary. Its an ugly hack and I'm sure I'm not the only one who
> has been bitten by config.h not pulling in everything required and then
> finding out that you have to rebuild and reboot.
> 
> Perhaps there is a way to use the host linker (which has knowledge of what
> the target is running) to do an additional link pass when uploading new
> code and then upload the code and any parts of eCos that are needed in one
> fell swoop.

I've explained the first points, that's there that something may goes
wrong. How the host linker does now that the board as the right version
of the kernel, or that loading won't crash everything ? That's really
what real dynamic loaders do for us: Checking that loading won't get nuts. That's the dangerous "point", and If you really want something
ultra-small, you'll probably won't get any belt but who's matter ?.

> 
> I certainly wouldn't like to see any code added target side for this. eCos
> is much smaller than VxWorks (at least for the archs I've used) and I
> think we should keep it that way.
> 

Of course, nothing here had been checked. Seems sexy enough
to solve speed-up in build/link/reload scenarios.
But not a deployment solution.

So happy hacking.

-- 
Eric DONNAT

Silicomp Research Institute
195, rue Lavoisier
ZIRST-BP1
38330 Montbonnot-St-Martin (France)

http://www.ri.silicomp.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