This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Linker support for Harvard Architecture
- From: Erik Christiansen <dvalin at internode dot on dot net>
- To: binutils at sourceware dot org
- Date: Wed, 31 Jul 2019 23:01:04 +1000
- Subject: Re: Linker support for Harvard Architecture
- References: <0193ff906759435699d765aeb2228dba@ceva-dsp.com>
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