Saturday, September 6, 2008

Retargetting the MSPGCC Linker

by Travis Goodspeed <travis at utk.edu>

BSLCracker 2.0
In this article, I describe the use and modification of GCC linker scripts. In particular, I emphasize their use within MSPGCC to add support for an additional target chip, the MSP430F2274. This technique allows the generation of executables for chips which are presently unsupported by MSPGCC, as well as the creation of executables that are intended to work with a custom bootloader.

Until recently, I had been using IAR's compiler for development of the BSL Password Cracker, which was the subject of my Black Hat USA talk. IAR makes a great compiler, but the proprietary UBROF object format prevented me from exporting debugging symbols to GDB. My requests to the company for a copy of the specification have thus-far yielded nothing.

In switching to MSPGCC, I found myself unable to compile executables for the MSP430F2274 around which I had already based the second major revision of my board. In this article, I will describe a simple method for extending the MSPGCC linker to support a new chip by modifying the definition of one that's presently supported. The same technique is also handy for building an image to be compatible with a custom bootloader, as I'll describe in the next installment of my series on reprogramming the TI EZ430U with custom firmware.

Under the hood, a compiler is built of many separate applications. The first stage is a preprocessor which evaluates macros such as the #include directive. After that, the compiler stage translates preprocessed C into assembly language. A third stage, the assembler, converts assembly language into object files, which are complete except for labels that have been left empty for later insertion. A fourth stage, the linker, combines one or more object files into an executable firmware image. In the case of the MSP430, this image is a complete kernel, which does not rely upon a surrounding kernel or dynamic libraries.

As objects enter the linker, they are not quite complete machine code. This is because, prior to linking, it is impossible to know the entry address of any function. They are quite likely to be re-arranged, with unused functions stripped out entirely.

Also unknown prior to linking is the location of various system boundaries, such as the range of memory which is mapped to Flash ROM, that range which is mapped to RAM, and various ranges of lesser importance. Embedded compilers use linking scripts to specify these regions.

IAR's linker, xlink, scripts in the config/ subdirectory of each target, /opt/iar430/config on my machine but more likely C:/Program Files/IAR Systems/Embedded Workbench 5.0/430/config in Windows. Observe the code memory region of lnk430F2274.xcl as an example:

// -------------------
// Code
// -------------------

-Z(CODE)CSTART,ISR_CODE=8000-FFDD
-P(CODE)CODE=8000-FFDD


The regions themselves are helpfully described in English comments at the top of the file, giving those too lazy to read the datasheets a helping hand. It's also rather nice that these are standard command-line arguments to xlink.

GCC's linker, ld, uses a different format. Regions are described not as beginning and ending absolute addresses, but rather as an absolute beginning address and a length. The corresponding line in my 2274 script is
text (rx) : ORIGIN = 0x8000, LENGTH = 0x7fe0

The first step in retargetting the linker is to adjust the rest of the lines in the MEMORY stanza to values that work. That is nearly all the work that you must do, but converting memory regions is not quite all that you'll have to contend with. In using an MSP430F1612 script as a starting point, I initially overlooked the following line.
PROVIDE (__stack = 0x2500) ;

That line initializes the stack pointer (r1) to be 0x2500. Nothing is mapped to this address, and the entire region reads each byte as 0x5321. As GCC places globals at the bottom of memory, setting this value to the top of memory, which is to say 0x5fe, results in a functional stack.

You can find my first attempt at an MSP430F2274 linker script here. It works for me, but it comes with the usual warranty, by which I mean none. Place it in the working directory and add -T foo.x to your linking gcc line.

In the near future, I intend to add a linker-script importer for msp430static to give context to different regions of memory. Support will exist for GCC and IAR formats, and a standalone mode will allow translation between formats.

5 comments:

Unknown said...

thanks a lot ... :)
I too ran in to same problem (msp430x2274 not being supported by mspgcc) while trying to work with ezmsp430.
now going over to program the module ... :)

Qasim Khan said...


Pretty good post. I just stumbled upon your blog and wanted to say that I have really enjoyed reading your blog posts. Any way I'll be subscribing to your feed and I hope you post again soon. Pubg Tdm Gameplay|
Urdu Novels |
forced marriage Urdu novels

aa said...

GEt services devloped day by day by the way nice article please refer these links as well for finencial help
aol contact number
aol phone number
aol support phone number
aol customer support phone number
aol technical support number
aol mail tech support phone number
aol customer support number

www.aolustec247.com
www.aolustec247.com/how-to-fix-aol-desktop-gold-app
www.aolustec247.com/how-to-install-aol-gold-desktop-app
www.aolustec247.com/how-to-contact-aol-customer-service
aolphonesupport.online

Ramon John said...

The website is looking bit flashy and it catches the visitors eyes. Design is pretty simple and a good user friendly interface.COMMERICAL CLEANING Pageland

jakerise said...

Retargetting, MSPGCC, and linker are terms used in software development, particularly in embedded systems and compiler toolchains. Retargetting involves adapting a compiler or toolchain to support a different hardware architecture or platform, such as a new microcontroller or processor. MSPGCC is a GCC toolchain specifically tailored for MSP430 microcontrollers, including a compiler, assembler, and linker. A linker is a tool that combines multiple object files into a single executable or binary, resolving references and handling address allocation. Retargetting MSPGCC may require modifying the linker script to fit the new hardware requirements. For example, if adapting MSPGCC to work with a new variant of the MSP430 microcontroller with different memory sizes or additional peripherals, the linker script would need to be modified criminal lawyer alexandria va.