From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Armitstead To: Richard Panton Cc: ecos-discuss@sourceware.cygnus.com Subject: Re: [ECOS] Re: Downloadable tasks? Date: Thu, 25 Jan 2001 07:59:00 -0000 Message-id: <5.0.2.1.0.20010125145133.00a6a130@mail.noral.co.uk> References: <5.0.2.1.0.20010123160652.00a66090@mail.noral.co.uk> X-SW-Source: 2001-01/msg00426.html 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 | \======================================================/