[arm-gnu] not a gnu question per se, but related (linker script help)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[arm-gnu] not a gnu question per se, but related (linker script help)



Good evening,

This isn't a gcc question per se, but it is regarding building a linker script 
for a bootloader that locks elements in place.

The scenario is a bootloader for an ARM7TDMI-S variant (LPC2103). The chip has 
32k of on-chip Flash and has some ROM in it which contains a bootloader of its 
own, including in-application programming routines to program the Flash from 
within an app running on the LPC.

I've created a little bootloader that sits in Flash segment 0 and essentially 
verifies that the image in the rest of Flash is good before jumping to it. If 
the image is found to have an invalid checksum, or a newer image is found in 
some off-chip SPI Flash, the bootloader will reflash the LPC flash with the image 
in SPI flash.

This is working well, but since 32k isn't a lot of storage and I'm already 
restricting myself to 28k of updateable flash (the bootloader won't ever be 
able to be changed), I'm cramming some base functionality into that first 4k 
which anything in the remaining flash would be able to call. Kind of like a set 
of library functions that the bootloader provides to whatever it's booting.

In order to isolate bootloader changes from affecting the application's ability 
to use bootloader functions, I'm thinking of creating a jump table much the 
same as the ARM's exception table. The idea is certainly not new; I know from 
my ancient history that the Commodore 64 used the same idea to provide a fixed 
set of addresses for functions.

Is there a slick way of creating this jump table using the linker? Do I just 
create a section in my boot.s file, populate it with branch instructions to the 
functions, and then use PROVIDE() statements in the linker? Is there a better 
way? This is all thumb code, and I know that branches in thumb are limited to 
2kB, so maybe I should be using an ARM jump table instead since the bootloader 
functions can occupy anything in the first 4k of Flash? Should I be looking at 
this differently?

Regards,
Andrew