This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linker support for Harvard Architecture


On 31.07.19 11:59, Haim Shimonovich wrote:
> Hi all,
> 
> 
> I am trying to support a processor that contains 2 address spaces(one
> for code and one for data). The current implementation of the Linker
> prevents me from mapping a code section and a data section to the same
> address. I get the following error: section .data.internal LMA
> [0000000000000000,0000000000002343] overlaps section .text LMA
> [0000000000000000,00000000000002ff]
> 
> Is there a known way to support this kind of memory
> configuration(without using overlays)?

The AVR has a Harvard Architecture, and binutils supports it very
nicely. It's a while since I actively used it, but it adds an offset to
addresses in one memory space to avoid conflict with the other. Ah, yes,
0x00800060 or so is added to data. The third EEPROM address space has
0x00810000 added, so it can be handled as well.

These offsets propagate all the way to the elf and device programming
files¹, and the programming utility uses the offsets to select which
memory type to load. They also show up in avr-objdump, e.g. (In the VMA
column):

$ avr-objdump -h obj/dimmer.elf 

obj/dimmer.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000049a  00000000  00000000  000000b4  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000008  00800060  0000049a  0000054e  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000045  00800068  00800068  00000556  2**0
                  ALLOC
  3 .eeprom       00000008  00810000  00810000  00000556  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  4 .stab         00001b18  00000000  00000000  00000560  2**2
                  CONTENTS, READONLY, DEBUGGING
  5 .stabstr      000000b8  00000000  00000000  00002078  2**0
                  CONTENTS, READONLY, DEBUGGING

The AVR has yet more spaces and offsets, but that's enough for the gist
of it, I guess. (For how it's done in detail, I'm not much help, I'm
afraid.)

¹ Either an srec or ihex file, generally.

A look at the AVR might show whether you would want to follow that path.

Erik


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]