Re: Device specific linker scripts

Erik Christiansen schrieb:
> On 19.10.13 19:48, Georg-Johann Lay wrote:
>> Dhakshinamoorthy, Soundararajan schrieb:
>>> I am trying to update the linker scripts, with the start address of
>>> boot section, which is different for each device (or atleast i don't
>>> seem to find a way to compute it based on the information available
>>> in binutils )
>> If such linker scripts shall become the default linker scripts then you need
>> 200+ emulations to support the 200+ devices.
> 
> One way to follow Johann's good advice might be to just use:
> 
>   .boot :
>   {
>     *(.boot_vectors)
>     *(.boot)
>   } > text
> 
> and have gcc set --section-start=.boot=0x12345
> That should suffice for now.
> 
> And yes, 4 x 205 = 820 full linker scripts is about what would happen if
> we were, for example, to proliferate what I sometimes do for the
> Atmega64:
> 
> MEMORY
> {
>   text   (rx)   : ORIGIN = 0, LENGTH = 62K
>   boot   (rx)   : ORIGIN = 62K, LENGTH = 2K
>   data   (rw!x) : ORIGIN = 0x800100, LENGTH = 4K
>   eeprom (rw!x) : ORIGIN = 0x810000, LENGTH = 2K
> }
> 
> SECTIONS
> {
> ...
>   }  > text
> 
>   .boot :
>   {
>     *(.boot_vectors)
>     *(.boot)
>   } > boot
> 
>   .data    : AT (ADDR (.text) + SIZEOF (.text))
>   {
> 
> That satisfied my strong preference for documenting the memory layout in
> the linker script. (Having all that information in one place can save
> time when coming back to an old project.)


Wouldn't this cause problems if no bootloader is present and .text 
overlaps empty bootloader section?

Johann


>> Maybe you can have a look at how the tools handle different RAM start: The
>> compiler just calls the linker with Tdata to provide the information.  This
>> you could add a new column to ./gcc/config/avr/avr-mcus.def and use that
>> information appropriately.
> 
> One scary aspect of that approach is this comment in that file:
> 
> /* List of all known AVR MCU types - if updated, it has to be kept
>    in sync in several places (FIXME: is there a better way?):
>     - here;
>     - gas/config/tc-avr.c;

The gas linke is already gone today.

>     - avr-libc.
> ...
> */
> 
> If adding parameter columns, the AVR_MCU macro would also need to be
> extended, at a minimum. And the extra coding work seems unnecessary.
> The "FIXME", above, also suggests that amplifying the syncing task isn't
> the best way forward. I wonder if something along the following lines is
> sufficiently more maintainable to be worth pursuing?
> 
> 1) Don't add device-specific addressing guff to avr-gcc, avr-as, or
>    avr-libc.
> 
> 2) Instead, just transparently emit the received -mcu parameter, as e.g.
>    "/defs/atmega328p" on the avr-ld command line.
>    (Now _that's_ less work, and it's only ever done once in each of
>    avr-gcc and avr-as.)
> 
> 3) Drop into a "defs" directory, a very short definition file for each
>    AVR device, containing legal linker script lines, such as:
> 
>    __boot_start = 0x12345 ;
> 
>    Depending on where defs/ is placed relative to /usr/local/avr/avr/lib/
>    a "-L path" might be needed at point 2. (Again, set and forget.)
> 
> 4) The linker automatically uses the defs/xxx file on the command line to
>    augment the main linker script, (See man ld)
> 
>    For the example in 3) above to solve Soundararajan's issue, the boot
>    section definition in the linker script should be:
> 
>   .boot __boot_start :
>   {
>     *(.boot_vectors)
>     *(.boot)
>   } > text
> 
> 5) Now syncing is automatic, since avr-gcc, avr-as, and avr-libc rely on
>    the linker to do its job without micromanagement.
> 
>    Adding a new device then only involves editing a text file e.g.
>    defs/atmega12345 and plugging in any desired address definitions in
>    linker script syntax.

Still avr-gcc has to be extended to accept -mmcu=atmega12345, so that 
file has to be touched anyway.

Johann


> The role of the architecture based emulations remains untouched.
> The device-specific augmentation file simply tweaks the architecture
> based linker script to the extent that ld supports.
> 
> If it were desired to add the boot section only sometimes, that could be
> done too, given decision making by avr-gcc.
> 
> If nothing else, such notions might stimulate further thought on how
> best to make the AVR toolchain easier to maintain.
> 
> Erik