[ECOS] Downloadable tasks?

[ECOS] Downloadable tasks?

[Tony Armitstead]

Hi,

I am considering using eCos in a KS32C50100 (ARM) application which 
requires down-loadable code images each of which contains 2 threads. My 
ideas are:

1. Product contains a boot ROM which downloads the eCos kernel along with 
some resident threads (basically host communications stuff). The eCos 
kernel is then installed and effectively takes over the operation of the 
target.

2. The eCos kernel would be extended to support a 'remote' kernel API 
interface accessed via SWI 'calls'

3. The downloaded images would be downloaded and their threads created 
within eCos. Each image would have a table giving the location, stack ..... 
of the threads within the image. Or maybe just an initialisation call which 
would create the threads using the remote API interface. Each downloaded 
image would be linked with a library of eCos API calls which just SWI down 
to the resident eCos kernel.

I have looked through the 'Native kernel C language API' calls and nothing 
jumps out at me as being a major problem. Note that each image would be 
linked with its own version of the C runtime library so I don't need to 
patch through all those calls as well! None of the images need to do device 
IO so I should be able to get the RTL footprint down to a reasonable level 
for each image.

So, does anyone have any thoughts on this - or maybe already done it (for ARM)!



/======================================================\
| Tony Armitstead BSc        EMail: tonya@noral.com    |
| Development Manager        Phone: +44 (0)1254 295807 |
| Noral Micrologics            Fax: +44 (0)1254 295801 |
| WEB: http://www.noral.com   FTP: ftp://ftp.noral.com |
\======================================================/

[ECOS] Re: Downloadable tasks?

[Richard Panton]

On Tue, 23 Jan 2001, Tony Armitstead wrote:

> Hi,
> 
> I am considering using eCos in a KS32C50100 (ARM) application which 
> requires down-loadable code images each of which contains 2 threads. My 
> ideas are:
> 
> 2. The eCos kernel would be extended to support a 'remote' kernel API 
> interface accessed via SWI 'calls'
> 
> 3. The downloaded images would be downloaded and their threads created 
> within eCos. Each image would have a table giving the location, stack ..... 
> of the threads within the image. Or maybe just an initialisation call which 
> would create the threads using the remote API interface. Each downloaded 
> image would be linked with a library of eCos API calls which just SWI down 
> to the resident eCos kernel.
> 
> So, does anyone have any thoughts on this - or maybe already done it (for ARM)!

I've been looking at similar enhancements. Some of the issues you may wish
to consider:

*	SWI handler needs to be enhanced to take and return arguments.

*	Do you need to support THUMB SWIs (have range of 0-255 maximum)?

	( I have a code fragment that can be used to support THUMB or ARM
          SWIs - you're welcome to take this )

*	What mode are the downloadable threads to run in: USER, SYSTEM or
SVC? Anything other than SVC mode requires changes to the context switch
code.

*	What level of protection is there to be between the downloadable
threads. This will be somewhere between none, and complete isolation.

*	You'll need to preallocate SWI numbers to specific functions. What
if a new kernel variant does not support some of these calls?

*	Are the downloadable images re-locateable, or do you have separate
binaries for the same process that can execute in (download space 0) and
(download space 1)?

*	On a similar note, will your eCos kernel pre-allocate memory for
each downloadable task, or will it use some sort of memory allocation to
partition the system at extension load-time?

*	What sort of protection from errant (i.e. buggy) or malicious
downloadable programs are you to have? Note that any thread can execute
the following code sequence to bring down the entire OS:
		
		mov	sp, #0		// Point to invalid stack
		stmfd	sp, {r0-lr}	// cause data fault

	The first action of the data fault routine is to attempt to
	preserve the registers on the (now invalid) stack, hence causing
	another data fault, etc. 

PS. Watch out for alarm functions.....

-- 
Richard Panton              Systems Architect          3G Lab Ltd.
richard.panton@3glab.com    http://www.3glab.org/

Re: [ECOS] Re: Downloadable tasks?

[Tony Armitstead]

Thanks for the comments Richard. See my own comments below:

At 04:12 PM 1/24/01 +0000, Richard Panton wrote:
>On Tue, 23 Jan 2001, Tony Armitstead wrote:
>
> > Hi,
> >
> > I am considering using eCos in a KS32C50100 (ARM) application which
> > requires down-loadable code images each of which contains 2 threads. My
> > ideas are:
> >
> > 2. The eCos kernel would be extended to support a 'remote' kernel API
> > interface accessed via SWI 'calls'
> >
> > 3. The downloaded images would be downloaded and their threads created
> > within eCos. Each image would have a table giving the location, stack 
> .....
> > of the threads within the image. Or maybe just an initialisation call 
> which
> > would create the threads using the remote API interface. Each downloaded
> > image would be linked with a library of eCos API calls which just SWI down
> > to the resident eCos kernel.
> >
> > So, does anyone have any thoughts on this - or maybe already done it 
> (for ARM)!
>
>I've been looking at similar enhancements. Some of the issues you may wish
>to consider:
>
>*       SWI handler needs to be enhanced to take and return arguments.

Does eCos use SWI itself? I tried to follow this through and got to 
__handle_exception. I reckon I need to get in there before this so that I 
can decode the SWI immediate parameter.

>*       Do you need to support THUMB SWIs (have range of 0-255 maximum)?
>
>         ( I have a code fragment that can be used to support THUMB or ARM
>           SWIs - you're welcome to take this )

I do not use thumb code at all. (Is that thumbs up or down!)

>*       What mode are the downloadable threads to run in: USER, SYSTEM or
>SVC? Anything other than SVC mode requires changes to the context switch
>code.

SVC is fine.

>*       What level of protection is there to be between the downloadable
>threads. This will be somewhere between none, and complete isolation.

None. ARM7 has no MMU and no process protection mechanism.

>*       You'll need to preallocate SWI numbers to specific functions. What
>if a new kernel variant does not support some of these calls?

Good point for a generic implementation. However I am probably going to be 
'well matched' between the resident kernel and the downloaded images so I 
dont think this will upset me.

>*       Are the downloadable images re-locateable, or do you have separate
>binaries for the same process that can execute in (download space 0) and
>(download space 1)?
>
>*       On a similar note, will your eCos kernel pre-allocate memory for
>each downloadable task, or will it use some sort of memory allocation to
>partition the system at extension load-time?

My thoughts are that they will be linked images but not located. We can 
then locate the image during the download process. There will be a resident 
thread which the host communicates with. This thread can allocate the 
required memory for an image and then the located image can be placed into 
memory and initialised etc...

A completely different approach is available to us here. We will always 
know the set of images required in the system - but the image set is 
configurable by the user. So we could link/locate eCos with the images and 
then send down a single image containing the complete application. However 
this needs our interface software to invoke a linker to build this final 
image. We would then need this linker/locater to run on several host 
platforms (Win32  + unix + Solaris .....).

>*       What sort of protection from errant (i.e. buggy) or malicious
>downloadable programs are you to have? Note that any thread can execute
>the following code sequence to bring down the entire OS:
>
>                 mov     sp, #0          // Point to invalid stack
>                 stmfd   sp, {r0-lr}     // cause data fault
>
>         The first action of the data fault routine is to attempt to
>         preserve the registers on the (now invalid) stack, hence causing
>         another data fault, etc.

Well we (specifically me) will be writing the images and if I write buggy 
or malicious code I will severely reprimand myself!

>PS. Watch out for alarm functions.....

What is the issue here? Only thing I could think of is a 'pointer to a 
function' issue but since the ARM7 is a simple non MMU core I don't see a 
problem. What am I missing?

Many thanks for your input.


>--
>Richard Panton              Systems Architect          3G Lab Ltd.
>richard.panton@3glab.com    http://www.3glab.org/


/======================================================\
| Tony Armitstead BSc        EMail: tonya@noral.com    |
| Development Manager        Phone: +44 (0)1254 295807 |
| Noral Micrologics            Fax: +44 (0)1254 295801 |
| WEB: http://www.noral.com   FTP: ftp://ftp.noral.com |
\======================================================/