Create a new task from a différent binary

Kernel
#1

francoisgervais wrote on Saturday, December 12, 2009:

Hi,
I’m am wondering if it’s possible to create a task from a different binary file. Let say I have my “kernel” running and I’d like to start another task with a file on a sdcard or something compiled by someone else. Like on uClinux when you just execute an elf file and it gets its own process. I’d like to do this so a user don’t have to bundle the kernel to its application.

The way I’m thinking of doing it right now is doing it without an OS and split my RAM and ROM so my kernel would be using the end of the end of the RAM and ROM and the user application the rest of the memory. To load all that I would bootstrap, load my kernel to the end of the memory and init it. Then load the user application and jump to it. Then the kernel would do it’s things using interrupts.

Any body have a better alternative? I’m out of google buzz words to continue my research so please feed me a little.

Thanks
Francois

#2

richard_damon wrote on Saturday, December 12, 2009:

I don’t think you will have any problems with FreeRTOS itself in trying to do this. The one impact on the user program would be that you would have compiled FreeRTOS with a specific set of options (in FreeRTOSconfig.h) and the user has lost the ability to customize this.

Where the difficulty lies is you are in essence needing to do a dynamic link. Your kernel section needs to find a way to know where to find the needed entries to the user program for the tasks it will provide and an entry to initialize the memory used by the user section. The user section will need to have a way to refer back to the routines & data in the kernel that it needs to reference. Note that this includes not only the FreeRTOS functions themselves, but may include the parts of the run time library that FreeRTOS loaded.

If the user is providing just a small piece of code, and your kernel is most of the application, it may be worth the pain to make this happen (unless the tool set already supports this, in which case it may be easy). If the user is providing mostly full application, trying to make it “easier” on them by bundling freeRTOS on the board may be more work then they save from not just including it into their code.

#3

dsnejko wrote on Saturday, December 12, 2009:

It is possible. Not really like in uCLinux but similar to some extend.  I have a kernel image permanent loaded  in the flash memory and applications re\-loadable. There is also a bootloader which  can reload images to fixed addresses including the kernel and  allows start them.  The kernel image and apps compiled separate but shear include files. The key thing is how to link the app without os calls. The kernel image has a table which provides addresses for kernel’s calls. The table location is fixed and known to the application, also the table format and offsets for each function is predefined too and not changing. For the application each os call is replaced with a macro like
move a0, table\_start+call\_offset
jmp (a0)        
The app should be able to initialize memory belonged to os, allocate treads and start the scheduler. The kernel includes FreeRtos and dynamic memory.

#4

francoisgervais wrote on Saturday, December 12, 2009:

Thanks for all your answers,

dsnejko that seems exactly what I want to do. At first, for the communication app to kernel I was thinking of using software interrupt because I though there was no other way. A little like when you’re making calls to the bios on a PC.

I’ll try to do some tests in that direction but if you have any other information on the linking process please let me know. Anything from a website link to a little piece of code. I played a little with linker script in the past but I think that is going to be one step further.

Thanks a lot
Francois

#5

dsnejko wrote on Sunday, December 13, 2009:

I am using CodeWarrior and ColdFire port. All linking is done with assembler so my macro would not work for your toolchain. I have a common file included on both sides. It describes table offsets and  macros for table insertion and calling. Something like this, name it lib_links.inc:  
<pre><code>
    .public _xTaskCreate
    .public _vTaskDelay

   INSERT_LINK: .macro  ref
.org   OFFSET&&ref
.long  ref
   .endm 

    JUMP_LINK:      .macro ref
&&ref:          move.l  _LIB_LINK_TABLE  + OFFSET&&ref, a0
                jmp  (a0)
                    .endm
</code></pre>

The kernel build includes an assembler file similar to:
<pre><code>

.global _LIB_LINK_TABLE
    .include lib_links.inc

.text
_LIB_LINK_TABLE:
_LIB_LINK_TABLE_START:
_FREERTOS_LINK_TABLE:
   INSERT_LINK _xTaskCreate
   INSERT_LINK _vTaskDelay
</code></pre>
The application build includes an assembler file similar to:
<pre><code>
   .extern _LIB_LINK_TABLE
   .include lib_links.inc

   .text
_LIB_LINK_TABLE_APP:
    JUMP_LINK _xTaskCreate
    JUMP_LINK _vTaskDelay
</code></pre>

\_LIB\_LINK\_TABLE is a segment created in the linker command file at fixed location and known for the kernel and the app.

#6

dsnejko wrote on Sunday, December 13, 2009:

Markdown spoiled it

#7

francoisgervais wrote on Sunday, December 13, 2009:

Thanks a lot

#8

dsnejko wrote on Sunday, December 13, 2009:

More readable.

I am using CodeWarrior and ColdFire port. All linking is done with assembler so my macro would not work for your toolchain. I have a common file included on both sides. It describes table offsets and macros for table insertion and calling. Something like this, name it lib_links.inc:
<pre><code>    .public _xTaskCreate
    .public _vTaskDelay
INSERT\_LINK: .macro ref
             .org OFFSET&&ref
             .long ref
             .endm
JUMP\_LINK:   .macro ref
&&ref:       move.l LIB\_LINK\_TABLE + OFFSET&&ref, a0
             jmp (a0)
             .endm</pre></code>

The kernel build includes an assembler file similar to:

<pre><code>  .global \_LIB\_LINK\_TABLE
  .include lib\_links.inc 
  .text
\_LIB\_LINK\_TABLE:
INSERT\_LINK \_xTaskCreate
INSERT\_LINK \_vTaskDelay</pre></code>

The application build includes an assembler file similar to:

<pre><code>
   .extern \_LIB\_LINK\_TABLE
   .include lib\_links.inc
   .text
\_LIB\_LINK\_TABLE_APP:
JUMP\_LINK  \_xTaskCreate
JUMP\_LINK  \_vTaskDelay</pre></code>

\_LIB\_LINK\_TABLE is a segment created in the linker command file at fixed location and known for the kernel and the app.

#9

dsnejko wrote on Sunday, December 13, 2009:

Missed some lines for the definition file:

<pre><code>    .public \_xTaskCreate
    .public \_vTaskDelay
INSERT\_LINK: .macro ref
             .org OFFSET&&ref
             .long ref
             .endm
JUMP\_LINK:   .macro ref
&&ref:       move.l LIB\_LINK\_TABLE + OFFSET&&ref, a0
             jmp (a0)
             .endm   
LINK\_REC\_LEN: .set      4
OFFSET\_xTaskCreate:    .set  (0\*LINK\_REC\_LEN)
OFFSET\_vTaskDelay: .set  (1\*LINK\_REC\_LEN)
</pre></code>

#10

dimasusl wrote on Thursday, November 04, 2010:

I have the same question too