Page 1 Linker Operation Linker Operation Classify all program - PDF document

Assignment for Tues Last Time � Read “Getting the Least out of Your C � Looked at ColdFire and ARM in depth Compiler” – linked to course web page Today m.c a.c Compiler Compiler Tools and toolchains for embedded � m.o a.o libwhatever.a systems � Linkers � Programmers Linker � Booting an embedded CPU � Debuggers system.hex � JTAG All of this stuff is “below” the C compiler in � In-system programmer the stack of tools � Subsequent lectures deal with embedded C Any weak link in the toolchain will hinder � development Debugger Linking Background Linking Linker functions � Each .c file, plus any headers it includes, is � Merge text, data, BSS segments of individual 1. called a “compilation unit” object files Including libraries � � Compiler turns compilation unit into an object file Including processor boot code � Each object (.o) file contains: � Resolve references to code and data 2. � text segment – executable code � Report any errors � data segment – initialized data Locate relocatable code 3. � BSS segment – uninitialized data Follow instructions in linker script � � Other stuff – debugging symbols, etc. � Report any errors � Object files: Result: Binary image ready to be loaded � � Relocatable onto the target system � Code and data addresses are symbolic – not yet bound to physical addresses � Contain unresolved references Page 1

Linker Operation Linker Operation � Classify all program symbols as either: A strong symbol can only appear once 1. � Weak – uninitialized globals � otherwise error Strong – functions and initialized globals � A weak symbol is overridden by a strong 2. symbol of the same name p1.c p2.c � I.e. all references to that name resolve to the weak strong int foo=5; int foo; strong symbol If there are multiple weak symbols, the 3. strong p1() { p2() { strong linker can pick an arbitrary one } } uh oh � Lots more details in CS 4400 Scan object files in order supplied to the � � linker, applying linker rules � Bizarre consequence: Same object file might have to appear on command line multiple times Linker Scripts MCF52233 Linker Script CodeWarrior linker is flexible and powerful � MEMORY { � Needs a “program” to tell it how to link for a given code (RX) : ORIGIN = 0x00000500, embedded platform LENGTH = 0x0003FB00 � Linker script syntax looks just like GNU linker userram (RWX) : ORIGIN = 0x20000400, � Linker script functionality: LENGTH = 0x00007C00 � Put parts of executable into the right parts of } memory � Insert padding to meet alignment requirements SECTIONS { � Define extra symbols ___heap_size = 0x1000; � Do arithmetic ___stack_size = 0x1000; � Keep track of current position in memory as “.” } More Linker Script More Linker Script RAMBAR = 0x20000000; RAMBAR_SIZE = 0x00008000; . data : { FLASHBAR = 0x00000000; FLASHBAR_SIZE = 0x00040000; ___DATA_RAM = .; . = ALIGN(0x4); .vectors : { ___sinit__ = .; mcf5xxx_vectors.s (.text) . = ALIGN (0x4); STATICINIT } >> vectorrom __START_DATA = .; .text : *(.data) { *(.text) . = ALIGN (0x4); . = ALIGN (0x4); __END_DATA = .; *(.rodata) . = ALIGN (0x4); } >> userram ___ROM_AT = .; ___DATA_ROM = .; } >> code Page 2

More Linker Script Loading Programs .bss : � Goal: Set things up so CPU runs the desired { program when powered up __START_BSS = .; *(.bss) . = ALIGN (0x4); How is this done? � *(COMMON) � Make a ROM, plug it in __END_BSS = .; � Burn a PROM / EPROM / EEPROM, plug it in ___BSS_END = .; � Download into RAM or flash ROM using an ISP . = ALIGN(0x4); � “In system programmer” } >> userram � Load new code over a network � Pros and cons of each? Booting a CPU Bootup Steps Disable all interrupts 1. Execute a sequence of steps � � Most processors power up with interrupts off � May run in different orders in different systems � However – may be a soft reboot � Some steps optional Perform RAM and ROM checks 2. Usually want to cope with both hard and � � RAM – “walking 1s” test soft boot � ROM – checksum � No point proceeding if one of these fails Initialize devices to known states 3. Copy initialized data segment from ROM to 4. RAM Clear BSS – uninitialized data segment 5. More Booting MCF52233 Boot Code _asm_startmeup: Initialize the stack move.w #0x2700, SR 6. � Initialize the stack pointer move.l #(___RAMBAR + 0x21), d0 � Create initial stack frame movec d0, RAMBAR1 Initialize the heap 7. Execute constructors and initializers for all 8. move.l #___IPSBAR, d0 global variables add.l #0x1, d0 Enable interrupts 9. move.l d0, 0x40000000 10. Call main() 11. Deal with the fact that main exited move.l #___FLASHBAR, d0 cmp.l #0x00000000, d0 bne change_flashbar add.l #0x61, d0 movec d0, FLASHBAR Page 3

More Boot Code Linker Scripts and Boot Code move.l #___SP_INIT, sp � All code I showed you is in your CodeWarrior project jsr _SYSTEM_SysInit � Plus lots more � You can read it, modify it, etc. movea.l #0, A6 link A6, #0 Example: disassemble fp_coldfire.a and � take a look jsr _main nop nop halt Debugging Debugging Methods Important capabilities: � LEDs under software control � � Observability – See internal processor state � Minimal workable debugging environment � Real-time analysis – Follow execution without � A most unpleasant way to debug complex slowing it down or stopping it software � Run control – Start and stop the processor, set breakpoints, watches, etc. printf() to serial console or LCD � For each debugging method: � Severely perturbs timing, typically � � Generally, a debug printf() is synchronous � Which capabilities does it provide? � Means: Hangs the system until the printf � What are its other pros and cons? completes � Why? More Debugging More Debugging Logic analyzer hooked to external pins � JTAG, BDM, Nexus � � Timing mode – displays logic transitions on pins � Basically just hardware implementations of � State mode – decode executing instructions, bus debugging stubs transactions, etc. � Triggers – give the analyzer conditions on which to start a detailed trace ICE – in-circuit emulator � � Triggers can be highly elaborate � Acts like your embedded processor but provides lots of extra functionality Remote debugger � Runs at full speed � � Typically expensive � Debugging stub runs on embedded processor � Main debugger (e.g., GDB) runs on a separate machine � The two communicate using Ethernet, serial line, or whatever Page 4

More Debugging JTAG – IEEE1149.1 � ROM emulator � Initially for hardware testing, evolved to support software testing � Looks like ROM, actually RAM + processor � At minimum supports rapid loading of new SW Basic idea: � � Can implement breakpoints, execution tracing � Each I/O pin, register, etc. can be “sniffed” by a JTAG cell � JTAG cells are connected in a “JTAG loop” � Simulator � Contents of entire JTAG loop can be read using a � Maximum controllability and observability shift register � Often slow � Can also be written � Hard to interface to the real world � External tool can reconstruct machine state from the JTAG bit stream � Easy to simulate the CPU, hard to simulate everything else JTAG Hardware Debugging JTAG Software Debugging Clock in JTAG out JTAG in Each JTAG cell “sniffs” the state of the corresponding output bit of the IC Program Counter - PC Status Bus Interface JTAG Control Register R1 Addr Bus Interface State Machine JTAG Connector Processor Core Register R2 JTAG bit stream in JTAG bit stream out “SPECIAL” REGISTER SET PC Board Register Rn Bit stream forms one long shift-register Data Bus Interface More JTAG More JTAG Pins: � Advantages of shift-register approach: � � TCK – clock � Simple � TDI – input data stream, sampled on rising edge of TCK � Requires few pins � TDO – output data stream, updated on falling Disadvantage of shift-register approach: � edge of TCK � End up reading and writing a lot of data just to � TRST – Resets JTAG state machine (optional) change one register � TMS – Test mode select: advances JTAG state � JTAG optimizations: machine � Commands – Directly change a single register or JTAG interface modules tend to be � memory cell expensive � Addressable loops – smaller JTAG loops each � “Low cost” solutions may be $2000 containing a subset of the machine state � However, all-software solutions (on the host side) exist � MCF52233 has JTAG Page 5

Summary � Embedded system development is strongly dependent on good tools � There is huge variation in tool quality � Lots of times free tools can be found � Sometimes they suck � Non-free tools can be really expensive � E.g., more than $10K per developer seat � These can suck too You need to understand what the tools do, � what the tradeoffs are, etc. � Generally it’s far better to buy the right tools up front � Saving $$ not worth if it makes the product ship late Page 6