[Bug ld/31124] AVR: Support new Emulations for Devices with FLMAP

[gjl at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31124

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
Closed as completed.

See also https://gcc.gnu.org/PR112944

Below is a snip from the new comments in ./ld/scripttempl/avr.sc:

_______________________________________________________________

HAVE_FLMAP
==========

The .rodata section is located in program memory. Devices from
the AVR64* and AVR128* families (from avrxmega2 and avrxmega4)
see a 32k segment of their program memory in their RAM address
space.  Which 32k segment is visible is determined by the
bit-field NVMCTRL_CTRLB.FLMAP.
Output section .rodata is placed in MEMORY region rodata.
The LMA of the .rodata section can be set by means of:

__RODATA_FLASH_START__ specifies the byte address of the
    rodata LMA.

__flmap specifies which 32k block is visible in RAM provided
    __RODATA_FLASH_START__ is undefined
    When __flmap and __RODATA_FLASH_START__ are undefined, then an
    emulation-specific default is used (the last 32k block).


MAYBE_FLMAP
===========

For devices from avrxmega2 and avrxmega4: The user can chose whether
or not .rodata is located in flash (if HAVE_FLMAP) or located in
in RAM (if not HAVE_FLMAP by means of -mrodata-in-ram).  This is
achieved by new emulations avrxmega2_flmap and avrxmega4_flmap that
are selected by compiler option -mno-rodata-in-ram.

In order to facilitate initialization of NVMCTRL_CTRLB.FLMAP and
NVMCTRL_CTRLB.FLMAPLOCK in the startup code irrespective of
HAVE_FLMAP, the following symbols are used / defined in order to
communicate with the startup code.
Notice that the hardware default for FLMAP is the last 32k block,
so that explicit initialization of FLMAP is only required when the
user wants to deviate from the defaults.

__flmap = HAVE_FLMAP
          ? given by __flmap resp. __RODATA_FLASH_START__ >> 15
          : 0;

__flmap_value = __flmap << __flmap_bpos;

__flmap_value_with_lock = __flmap__value | __flmap_lock_mask;

__flmap_init_label = HAVE_FLMAP
                     ? __flmap_init_start
                     : __flmap_noinit_start;
    Supposed to be used as a jump target for RJMP so that the code
    can initialize FLMAP / skip initialization of FLMAP depending
    on the chosen emulation, and without the need to support two code
    versions of crt<mcu>.o for the two possible emulations.

__flmap_lock is a bool provided by the user when FLMAP should be
    protected from any further changes.

__flmap_lock_mask is an 8-bit mask like NVMCTRL_FLMAPLOCK_bm
    provided by the user which is set in __flmap_value_with_lock
    when __flmap_lock is on.

__do_init_flmap = HAVE_FLMAP ? 1 : 0;
    Whether or not FLMAP is supposed to be initialized according
    to, and for the purpose of, .rodata in flash.

Apart from that, the compiler (device-specs actually) defines the
following macros:

__AVR_HAVE_FLMAP__
    Defined if a device has the NVMCTRL_CTRLB.FLMAP bitfield
    *AND* if it's unknown at compile-time / assembler-time whether
    emulation avrxmega* is used or avrxmega*_flmap.

-- 
You are receiving this mail because:
You are on the CC list for the bug.