MCF5282 Position-Independent Code

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

MCF5282 Position-Independent Code

1,615件の閲覧回数
SVC1
Contributor I

Hi,

I am trying to achieve the following scheme on the MCF5282.

  1. Internal Flsah: Sector 0 (16KB): Boot Loader
  2. Internal Flsah: Sector 1 (16KB): Inventory and Sytem Data
  3. Internal Flsah: Sector  2 to 16 inclusively: Image A  (240 Kbytes)
  4. Internal Flsah: Sector 17 to 32 inclusively: Image B (240 Kbytes)

When the system boots up, the BootLoader checks a byte in Sector 1 at a specific address and, based on the value read at a specific address (say 1 or 0),  decides to jump to Image A or Image B.

Thus, I will burn:

  1. Image A starting address 0x0000 8000
  2. Image B starting address 0x0004 4000

The Data of both Image A and B will be in SRAM at specific address.

Questions

  1. Is this scheme possible?
  2. There is very little explanation in “CodeWarrior Build Tools Reference ColdFire Architectures Edition” manual on the Position-Independent Code. Very vague and unclear. Is there more explanation on this Position-Independent Code and data?
  3. How do I set up my linker file for Image A and Image B to be address independent? In other words, I don’t want to have a specific linker file for Image A and a specific linker file for Image B but rather a “generic” linker file for both. Is it possible?
  4. This “generic” linker file should therefore specify the Data that will be at fix address in SRAM. Nevertheless, the address of a) Vector table, b) Constants and c) code, should be relative to the stating address of the image in Flash.

Is this feasible?

 

Thanks,

Simon



Message Edited by SVC1 on 2008-04-11 03:58 PM
ラベル(1)
0 件の賞賛
返信
1 返信

722件の閲覧回数
bkatt
Contributor IV
see this thread:
http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&message.id=3814

You can definitely do it with two linker files and non-PIC code.

When you link PIC code, you don't get a ready-to-execute file. You get a binary plus relocation tables, and the runtime is expected to copy the virgin image to RAM, then walk the relocation tables performing fixups on the code before starting it (in RAM). The only ways this could work with execute from flash would be to write your code so that no relocations are needed, or perform the fixups sometime before writing the flash.

The vector table that is actually used must start on a 1M address boundary, so that limits the vectors to  the start of flash or the start of some other memory area (RAM).

0 件の賞賛
返信