[En-Nut-Discussion] NutOS relocatable?

[Ulrich Prinz]

Wow, lots of cool ideas :)

Indeed, there is an option I already thought about:
The binary image is run through a CRC generator that prepends the image
with a small informational record. This record contains an image or
product ID to avoid flashing the wrong firmware. There is a CRC for the
image and some length and entry vector information.

As the application is small and the CortexM3 has lots of flash but not
enough ram to run the application in, the simple solution turns to be
the following:

With the length in the record I can copy two binaries together. I run
the linker twice with different linker scripts respecting the two flash
locations. The server for the bootloader requests which of the two is
needed for the target and sends out the matching one.
As the serving box is a linux system with tons of flash, it doesn't
matter if the firmware for the slave is 50k or 100k.

But with that solution I will get forward most easy I think.

On the other hand I think that there must be a way for the toolchain to
generate relocateable code. I have boxes with uCLinux running and there
the executebales and libraries are never at the same place. And some of
the system don't have any kind of MMU.

I have to read a bit in the gnu toolchain documentation. It always
helps. In this way I found the gcc compiler switch that fixes a problem
with cortex cores and it really helps!

Ulrich

Am 07.04.2011 19:25, schrieb Nathan Moore:
> I believe that the way relocatable code usually works in C like psudo-code
> is:
> 
>     CODE_BASE = PC & MODULE_CODE_MASK ;  // Calculates the base address for
> the current module from the Program Counter's current value
>     ADDR = CODE_BASE | FUNC_OFFSET;   // Calculate the address of the
> desired function in the currently running code
>     call ADDR;                                              // Call the
> function at it's current location by function pointer stored in a register
> 
> I don't think that there is any real reason that NutOS couldn't run this
> way, and I
> don't know of any compiler limitations for this except that the compiler may
> assume
> an underlying OS's page size when generating the MODULE_CODE_MASK.
> 
> I don't know how to go about telling gcc how to do this correctly, though.
> 
> Nathan
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion