Re: Binutils/ld: linker script does not work for AVR mega 0 series (avrxmega3)

[Konrad Rosenbaum]

Hi,

thanks for responding Nick.

On 31/10/2022 15:57, Nick Clifton wrote:
> > the linker fails on trying to arrange data/bss segments even with 
> > very few small variables. E.g.:
>
> Please could you file a bug report for this problem here:
>
>   https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils

Will do as soon as I get a login (just requested it) - the process for 
reporting bugs seems a bit .... complicated?


> > avr-g++ -Os -Wl,--gc-sections -B 
> > ~/tronic/atmel-compiler-packs/mega/gcc/dev/atmega3208 
> > -mmcu=atmega3208 -o fw.elf dimmer.o dmx.o input.o ledout.o pwm.o
> > <...>/lib/gcc/avr/12.2.0/../../../../avr/bin/ld: address 0x803004 of 
> > fw.elf section `.bss' is not within region `data'
>
> If you can include these object files as an aid for reproducing the 
> problem, that would be appreciated.

No problem. Meanwhile: the source repository is at 
https://phabricator.silmor.de/source/HarteLEDimm/ (subdir src).


> > I narrowed the problem down to the Linker script avrxmega3.xn - it 
> > somehow messes up the data segment in the MEMORY section at the top. 
> > I was able to get it to link by changing that line:
> >
> > -  data   (rw!x) : ORIGIN = 0x802000, LENGTH = __DATA_REGION_LENGTH__
> > +  data   (rw!x) : ORIGIN = 0x802000, LENGTH = 0x10000
> >
> > The fixed origin seems very dubious to me and I wasn't able to debug 
> > __DATA_REGION_LENGTH__.
>
> It is defined earlier on in script:

[cut]

I actually meant to ask: is there a way to debug the linker script? I.e. 
to output what real values are used and where they come from?


[cut]

> and the definition of DATA_ORIGIN can be found in 
> ld/emulparams/avrxmega3.sh:
>
>   DATA_ORIGIN=0x802000
>
> I am not intimately familiar with the AVR architecture variants, so I 
> do not
> know if this is a reasonable value...

It is the correct value for the AtMega4808, but not the smaller 3208, 
1608 or 808, which all have more or less the same MCU core.

The 0x80.... prefix is actually something that GCC uses to be able to 
reduce its internal virtual machine state to real addresses. In real 
hardware addresses are 16bit and only the last 4 hex digits are used.

The AVR (XMega) platform has one continuous address space for several 
very different memory types: in this particular case it starts with the 
register file (general purpose and then IO registers) at 0x0, then 
EEPROM (for config data). From the other end it starts with program 
flash memory at 0xFFFF, then data SRAM (used for heap/stack). Between 
those two sides is a gap in the middle of the address space. The 
starting address of the SRAM depends on the size of the program flash 
(every family has basically variants with 8, 16, 32, and 48 kBytes of 
flash). Usually the SRAM size is somewhat correlated to the flash size 
(e.g. the 808 has 8kB flash and 2kB SRAM, the 4808 has 48kB flash and 
6kB SRAM; otherwise the two are identical).

In short: for every specific MCU model that is supported you need to 
know what specific instruction set it supports (in this case it is the 
XMega 3 set, the "AtMega zero-series" is a hybrid between Mega and 
XMega) and what the boundary addresses of each memory type are - those 
need to be written down somewhere (like a device-spec file that contains 
parameters like "-Tdata 0x803000" for ld).


    Konrad

OpenPGP_signature
Description: OpenPGP digital signature