Constant at fixed address

Constant at fixed address

[Henrique Coser]

Hello,

I need a help. I'm trying to solve a problem for weeks.
I have a embeded software that is a boot loader. It puts the boot load version at a specific address.
My memmory starts at 0x400000 with 0x1400 size. My constant version string value must be placed @0x401000 with 8bytes length.
If I place this const value into a section like this:

 const unsigned char Version[8] __attribute__ ((section (".bootversion")))  = "V1.0.1a";

I got this error:

section .bootversion LMA [00401000,00401007] overlaps section .text LMA [00400000,00401013]collect2.exe(0,0): error: ld returned 1 exit status

I have already tried to split flash memmory using linker script but it does not worked.
I wish to find something like "automatic" split.

For example, this code was compiled using ARM Keil. With ARM Keil I have the attribute that makes all the magic :
 const unsigned char Version[8] __attribute__((at(0x0401000))) = "V1.0.1a";

I dont know if is possible to have something as pratical as ARM Keil attribute in GCC.

I really need make this thing work.
If this is not the best channel to ask, please, could you recommend me one?

Thank you very much!



Henrique Coser

Engenharia



TEX Equip.Eletronicos Ind.e Com.Ltda.

Fone: (+5511) 4591-2825

henrique.coser@tex.com.br<mailto:compras@tex.com.br>

MEDIR PARA MELHORAR!

Re: Constant at fixed address

[Martin Sebor]

On 2/25/22 09:01, Henrique Coser wrote:
> Hello,
> 
> I need a help. I'm trying to solve a problem for weeks.
> I have a embeded software that is a boot loader. It puts the boot load version at a specific address.
> My memmory starts at 0x400000 with 0x1400 size. My constant version string value must be placed @0x401000 with 8bytes length.
> If I place this const value into a section like this:
> 
>   const unsigned char Version[8] __attribute__ ((section (".bootversion")))  = "V1.0.1a";
> 
> I got this error:
> 
> section .bootversion LMA [00401000,00401007] overlaps section .text LMA [00400000,00401013]collect2.exe(0,0): error: ld returned 1 exit status
> 
> I have already tried to split flash memmory using linker script but it does not worked.
> I wish to find something like "automatic" split.
> 
> For example, this code was compiled using ARM Keil. With ARM Keil I have the attribute that makes all the magic :
>   const unsigned char Version[8] __attribute__((at(0x0401000))) = "V1.0.1a";
> 
> I dont know if is possible to have something as pratical as ARM Keil attribute in GCC.

GCC for the AVR target supports a couple of attributes that can be
used to pin a variable declaration to a fixed address: address and
io.  It doesn't look to me like they're put in their own sections
like in the ARM Keil compiler (but the section attribute can be
used for that).

Beside your use case, exposing at least the address attribute in all
targets would make would also solve a long-standing problem with GCC
issuing warnings for accesses to hardwired addresses).

I suggest opening an enhancement request in Bugzilla.

Martin


> 
> I really need make this thing work.
> If this is not the best channel to ask, please, could you recommend me one?
> 
> Thank you very much!
> 
> 
> 
> Henrique Coser
> 
> Engenharia
> 
> 
> 
> TEX Equip.Eletronicos Ind.e Com.Ltda.
> 
> Fone: (+5511) 4591-2825
> 
> henrique.coser@tex.com.br<mailto:compras@tex.com.br>
> 
> MEDIR PARA MELHORAR!

Re: Constant at fixed address

[David Brown]

On 25/02/2022 17:45, Martin Sebor via Gcc-help wrote:
> On 2/25/22 09:01, Henrique Coser wrote:
>> Hello,
>>
>> I need a help. I'm trying to solve a problem for weeks.
>> I have a embeded software that is a boot loader. It puts the boot load
>> version at a specific address.
>> My memmory starts at 0x400000 with 0x1400 size. My constant version
>> string value must be placed @0x401000 with 8bytes length.
>> If I place this const value into a section like this:
>>
>>   const unsigned char Version[8] __attribute__ ((section
>> (".bootversion")))  = "V1.0.1a";
>>
>> I got this error:
>>
>> section .bootversion LMA [00401000,00401007] overlaps section .text
>> LMA [00400000,00401013]collect2.exe(0,0): error: ld returned 1 exit
>> status
>>
>> I have already tried to split flash memmory using linker script but it
>> does not worked.
>> I wish to find something like "automatic" split.
>>
>> For example, this code was compiled using ARM Keil. With ARM Keil I
>> have the attribute that makes all the magic :
>>   const unsigned char Version[8] __attribute__((at(0x0401000))) =
>> "V1.0.1a";
>>
>> I dont know if is possible to have something as pratical as ARM Keil
>> attribute in GCC.
> 
> GCC for the AVR target supports a couple of attributes that can be
> used to pin a variable declaration to a fixed address: address and
> io.  It doesn't look to me like they're put in their own sections
> like in the ARM Keil compiler (but the section attribute can be
> used for that).
> 
> Beside your use case, exposing at least the address attribute in all
> targets would make would also solve a long-standing problem with GCC
> issuing warnings for accesses to hardwired addresses).
> 
> I suggest opening an enhancement request in Bugzilla.
> 
> Martin
> 
> 

I second that request - it would definitely be convenient to be able to
put a variable or section at a specific address without having to modify
a linker script.  This is a feature that most embedded toolchains (Keil,
IAR, etc.) support.

Note that the attributes for the AVR here don't do what is needed, as
far as I can see - it looks like they declare the variable at the given
address, but that does not mean that there will be an absolute section
allocated in the link.  In other words, using the AVR "address"
attribute to put "Version" at address 0x0401000 will not actually put
the initialised data there, nor will it prevent the address being used
by anything else that is linked to that memory area.

The example for the "address" attribute is :

	volatile int porta __attribute__((address (0x600)));

The effect of this is very similar to the more common and portable
version used for other targets:

	#define porta *((volatile int *) 0x600)

Henrique needs more than that here.

AFAIK, Henrique, the only way to achieve your needs are a modified
linker script.  It's not hard to do that, but of course it looks hard
the first time you do it!  Post a copy of your current linker script and
I can try to give you ideas for modification.

AW: Constant at fixed address

[stefan]

> -----Ursprüngliche Nachricht-----
> Von: Gcc-help <gcc-help-bounces+bebbo=bejy.net@gcc.gnu.org> Im
> Auftrag von David Brown
> Gesendet: Freitag, 25. Februar 2022 18:57
> An: Martin Sebor <msebor@gmail.com>; Henrique Coser
> <henrique.coser@tex.com.br>; gcc-help@gcc.gnu.org
> Betreff: Re: Constant at fixed address
> 
> On 25/02/2022 17:45, Martin Sebor via Gcc-help wrote:
> > On 2/25/22 09:01, Henrique Coser wrote:
> >> Hello,
> >>
> >> I need a help. I'm trying to solve a problem for weeks.
> >> I have a embeded software that is a boot loader. It puts the boot
> >> load version at a specific address.
> >> My memmory starts at 0x400000 with 0x1400 size. My constant version
> >> string value must be placed @0x401000 with 8bytes length.
> >> If I place this const value into a section like this:
> >>
> >>   const unsigned char Version[8] __attribute__ ((section
> >> (".bootversion")))  = "V1.0.1a";
> >>
> >> I got this error:
> >>
> >> section .bootversion LMA [00401000,00401007] overlaps section .text
> >> LMA [00400000,00401013]collect2.exe(0,0): error: ld returned 1 exit
> >> status
> >>
> >> I have already tried to split flash memmory using linker script but
> >> it does not worked.
> >> I wish to find something like "automatic" split.
> >>
> >> For example, this code was compiled using ARM Keil. With ARM Keil I
> >> have the attribute that makes all the magic :
> >>   const unsigned char Version[8] __attribute__((at(0x0401000))) =
> >> "V1.0.1a";
> >>
> >> I dont know if is possible to have something as pratical as ARM Keil
> >> attribute in GCC.
> >
> > GCC for the AVR target supports a couple of attributes that can be
> > used to pin a variable declaration to a fixed address: address and io.
> > It doesn't look to me like they're put in their own sections like in
> > the ARM Keil compiler (but the section attribute can be used for
> > that).
> >
> > Beside your use case, exposing at least the address attribute in all
> > targets would make would also solve a long-standing problem with GCC
> > issuing warnings for accesses to hardwired addresses).
> >
> > I suggest opening an enhancement request in Bugzilla.
> >
> > Martin
> >
> >
> 
> I second that request - it would definitely be convenient to be able to put a
> variable or section at a specific address without having to modify a linker
> script.  This is a feature that most embedded toolchains (Keil, IAR, etc.)
> support.
> 
> Note that the attributes for the AVR here don't do what is needed, as far as I
> can see - it looks like they declare the variable at the given address, but that
> does not mean that there will be an absolute section allocated in the link.  In
> other words, using the AVR "address"
> attribute to put "Version" at address 0x0401000 will not actually put the
> initialised data there, nor will it prevent the address being used by anything
> else that is linked to that memory area.
> 
> The example for the "address" attribute is :
> 
> 	volatile int porta __attribute__((address (0x600)));
> 
> The effect of this is very similar to the more common and portable version
> used for other targets:
> 
> 	#define porta *((volatile int *) 0x600)
> 
> Henrique needs more than that here.
> 
> AFAIK, Henrique, the only way to achieve your needs are a modified linker
> script.  It's not hard to do that, but of course it looks hard the first time you
> do it!  Post a copy of your current linker script and I can try to give you ideas
> for modification.
> 
> 

Isn't this already possible by using a section:

   volatile int porta __attribute__((__section("section_600")));

and using an appropriate linker script?

SECTIONS
{
  .section_600 0x600: {
   *(.section_600)
...


Stefan

Re: AW: Constant at fixed address

[David Brown]

On 25/02/2022 19:18, stefan@franke.ms wrote:
> 
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Gcc-help <gcc-help-bounces+bebbo=bejy.net@gcc.gnu.org> Im
>> Auftrag von David Brown
>> Gesendet: Freitag, 25. Februar 2022 18:57
>> An: Martin Sebor <msebor@gmail.com>; Henrique Coser
>> <henrique.coser@tex.com.br>; gcc-help@gcc.gnu.org
>> Betreff: Re: Constant at fixed address
>>
>> On 25/02/2022 17:45, Martin Sebor via Gcc-help wrote:
>>> On 2/25/22 09:01, Henrique Coser wrote:
>>>> Hello,
>>>>
>>>> I need a help. I'm trying to solve a problem for weeks.
>>>> I have a embeded software that is a boot loader. It puts the boot
>>>> load version at a specific address.
>>>> My memmory starts at 0x400000 with 0x1400 size. My constant version
>>>> string value must be placed @0x401000 with 8bytes length.
>>>> If I place this const value into a section like this:
>>>>
>>>>   const unsigned char Version[8] __attribute__ ((section
>>>> (".bootversion")))  = "V1.0.1a";
>>>>
>>>> I got this error:
>>>>
>>>> section .bootversion LMA [00401000,00401007] overlaps section .text
>>>> LMA [00400000,00401013]collect2.exe(0,0): error: ld returned 1 exit
>>>> status
>>>>
>>>> I have already tried to split flash memmory using linker script but
>>>> it does not worked.
>>>> I wish to find something like "automatic" split.
>>>>
>>>> For example, this code was compiled using ARM Keil. With ARM Keil I
>>>> have the attribute that makes all the magic :
>>>>   const unsigned char Version[8] __attribute__((at(0x0401000))) =
>>>> "V1.0.1a";
>>>>
>>>> I dont know if is possible to have something as pratical as ARM Keil
>>>> attribute in GCC.
>>>
>>> GCC for the AVR target supports a couple of attributes that can be
>>> used to pin a variable declaration to a fixed address: address and io.
>>> It doesn't look to me like they're put in their own sections like in
>>> the ARM Keil compiler (but the section attribute can be used for
>>> that).
>>>
>>> Beside your use case, exposing at least the address attribute in all
>>> targets would make would also solve a long-standing problem with GCC
>>> issuing warnings for accesses to hardwired addresses).
>>>
>>> I suggest opening an enhancement request in Bugzilla.
>>>
>>> Martin
>>>
>>>
>>
>> I second that request - it would definitely be convenient to be able to put a
>> variable or section at a specific address without having to modify a linker
>> script.  This is a feature that most embedded toolchains (Keil, IAR, etc.)
>> support.
>>
>> Note that the attributes for the AVR here don't do what is needed, as far as I
>> can see - it looks like they declare the variable at the given address, but that
>> does not mean that there will be an absolute section allocated in the link.  In
>> other words, using the AVR "address"
>> attribute to put "Version" at address 0x0401000 will not actually put the
>> initialised data there, nor will it prevent the address being used by anything
>> else that is linked to that memory area.
>>
>> The example for the "address" attribute is :
>>
>> 	volatile int porta __attribute__((address (0x600)));
>>
>> The effect of this is very similar to the more common and portable version
>> used for other targets:
>>
>> 	#define porta *((volatile int *) 0x600)
>>
>> Henrique needs more than that here.
>>
>> AFAIK, Henrique, the only way to achieve your needs are a modified linker
>> script.  It's not hard to do that, but of course it looks hard the first time you
>> do it!  Post a copy of your current linker script and I can try to give you ideas
>> for modification.
>>
>>
> 
> Isn't this already possible by using a section:
> 
>    volatile int porta __attribute__((__section("section_600")));
> 
> and using an appropriate linker script?
> 
> SECTIONS
> {
>   .section_600 0x600: {
>    *(.section_600)
> ...
> 
> 
> Stefan
> 

Exactly, yes.  The point is that with gcc (and standard binutils) you
need to modify (or suppliment) the linker script to do this.  The OP is
used to a toolchain where you can specify this using an attribute in the
compiler alone, which is neater.

RE: Constant at fixed address

[Henrique Coser]

[-- Attachment #1: Type: text/plain, Size: 3978 bytes --]

Martin and David,  thank you for your answers.

Attached is the linker script that I use.

In Keil, where I did the first version of the boot loader I can assure you that a constant value is placed and correctly filled when use __attribute__((at(0x0401000)))
I don't know how they do this but they do!

I would be grateful If you could help me editting this script.

Thank you very much.



Henrique Coser

Engenharia



TEX Equip.Eletronicos Ind.e Com.Ltda.

Fone: (+5511) 4591-2825

henrique.coser@tex.com.br<mailto:compras@tex.com.br>

MEDIR PARA MELHORAR!
________________________________
De: David Brown <david.brown@hesbynett.no>
Enviado: 25 de fevereiro de 2022 14:56
Para: Martin Sebor <msebor@gmail.com>; Henrique Coser <henrique.coser@tex.com.br>; gcc-help@gcc.gnu.org <gcc-help@gcc.gnu.org>
Assunto: Re: Constant at fixed address

On 25/02/2022 17:45, Martin Sebor via Gcc-help wrote:
> On 2/25/22 09:01, Henrique Coser wrote:
>> Hello,
>>
>> I need a help. I'm trying to solve a problem for weeks.
>> I have a embeded software that is a boot loader. It puts the boot load
>> version at a specific address.
>> My memmory starts at 0x400000 with 0x1400 size. My constant version
>> string value must be placed @0x401000 with 8bytes length.
>> If I place this const value into a section like this:
>>
>>   const unsigned char Version[8] __attribute__ ((section
>> (".bootversion")))  = "V1.0.1a";
>>
>> I got this error:
>>
>> section .bootversion LMA [00401000,00401007] overlaps section .text
>> LMA [00400000,00401013]collect2.exe(0,0): error: ld returned 1 exit
>> status
>>
>> I have already tried to split flash memmory using linker script but it
>> does not worked.
>> I wish to find something like "automatic" split.
>>
>> For example, this code was compiled using ARM Keil. With ARM Keil I
>> have the attribute that makes all the magic :
>>   const unsigned char Version[8] __attribute__((at(0x0401000))) =
>> "V1.0.1a";
>>
>> I dont know if is possible to have something as pratical as ARM Keil
>> attribute in GCC.
>
> GCC for the AVR target supports a couple of attributes that can be
> used to pin a variable declaration to a fixed address: address and
> io.  It doesn't look to me like they're put in their own sections
> like in the ARM Keil compiler (but the section attribute can be
> used for that).
>
> Beside your use case, exposing at least the address attribute in all
> targets would make would also solve a long-standing problem with GCC
> issuing warnings for accesses to hardwired addresses).
>
> I suggest opening an enhancement request in Bugzilla.
>
> Martin
>
>

I second that request - it would definitely be convenient to be able to
put a variable or section at a specific address without having to modify
a linker script.  This is a feature that most embedded toolchains (Keil,
IAR, etc.) support.

Note that the attributes for the AVR here don't do what is needed, as
far as I can see - it looks like they declare the variable at the given
address, but that does not mean that there will be an absolute section
allocated in the link.  In other words, using the AVR "address"
attribute to put "Version" at address 0x0401000 will not actually put
the initialised data there, nor will it prevent the address being used
by anything else that is linked to that memory area.

The example for the "address" attribute is :

        volatile int porta __attribute__((address (0x600)));

The effect of this is very similar to the more common and portable
version used for other targets:

        #define porta *((volatile int *) 0x600)

Henrique needs more than that here.

AFAIK, Henrique, the only way to achieve your needs are a modified
linker script.  It's not hard to do that, but of course it looks hard
the first time you do it!  Post a copy of your current linker script and
I can try to give you ideas for modification.




[-- Attachment #2: sam3s4b_flash.ld --]
[-- Type: application/octet-stream, Size: 3166 bytes --]

/* ---------------------------------------------------------------------------- */
/*                  Atmel Microcontroller Software Support                      */
/*                       SAM Software Package License                           */
/* ---------------------------------------------------------------------------- */
/* Copyright (c) %copyright_year%, Atmel Corporation                                        */
/*                                                                              */
/* All rights reserved.                                                         */
/*                                                                              */
/* Redistribution and use in source and binary forms, with or without           */
/* modification, are permitted provided that the following condition is met:    */
/*                                                                              */
/* - Redistributions of source code must retain the above copyright notice,     */
/* this list of conditions and the disclaimer below.                            */
/*                                                                              */
/* Atmel's name may not be used to endorse or promote products derived from     */
/* this software without specific prior written permission.                     */
/*                                                                              */
/* DISCLAIMER:  THIS SOFTWARE IS PROVIDED BY ATMEL "AS IS" AND ANY EXPRESS OR   */
/* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF */
/* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT ARE   */
/* DISCLAIMED. IN NO EVENT SHALL ATMEL BE LIABLE FOR ANY DIRECT, INDIRECT,      */
/* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT */
/* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,  */
/* OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF    */
/* LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING         */
/* NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, */
/* EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.                           */
/* ---------------------------------------------------------------------------- */

/*------------------------------------------------------------------------------
 *      Linker script for running in internal FLASH on the ATSAM3S4B
 *----------------------------------------------------------------------------*/

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
SEARCH_DIR(.)

/* Memory Spaces Definitions */
MEMORY
{
  rom (rx)  : ORIGIN = 0x00400000, LENGTH = 0x000013F6      
  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 0x0000C000
}

/* The stack size used by the application. NOTE: you need to adjust according to your application. */
STACK_SIZE = DEFINED(STACK_SIZE) ? STACK_SIZE : 0x400;

/* The heapsize used by the application. NOTE: you need to adjust according to your application. */
HEAP_SIZE = DEFINED(HEAP_SIZE) ? HEAP_SIZE : 0x200;

INCLUDE sam3s_flash.ld

[-- Attachment #3: sam3s_flash.ld --]
[-- Type: application/octet-stream, Size: 4898 bytes --]

/* ---------------------------------------------------------------------------- */
/*                  Atmel Microcontroller Software Support                      */
/*                       SAM Software Package License                           */
/* ---------------------------------------------------------------------------- */
/* Copyright (c) %copyright_year%, Atmel Corporation                                        */
/*                                                                              */
/* All rights reserved.                                                         */
/*                                                                              */
/* Redistribution and use in source and binary forms, with or without           */
/* modification, are permitted provided that the following condition is met:    */
/*                                                                              */
/* - Redistributions of source code must retain the above copyright notice,     */
/* this list of conditions and the disclaimer below.                            */
/*                                                                              */
/* Atmel's name may not be used to endorse or promote products derived from     */
/* this software without specific prior written permission.                     */
/*                                                                              */
/* DISCLAIMER:  THIS SOFTWARE IS PROVIDED BY ATMEL "AS IS" AND ANY EXPRESS OR   */
/* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF */
/* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT ARE   */
/* DISCLAIMED. IN NO EVENT SHALL ATMEL BE LIABLE FOR ANY DIRECT, INDIRECT,      */
/* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT */
/* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,  */
/* OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF    */
/* LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING         */
/* NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, */
/* EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.                           */
/* ---------------------------------------------------------------------------- */

/* Section Definitions */
SECTIONS
{
    .text :
    {
        . = ALIGN(4);
        _sfixed = .;
        KEEP(*(.vectors .vectors.*))
        *(.text .text.* .gnu.linkonce.t.*)
        *(.glue_7t) *(.glue_7)
        *(.rodata .rodata* .gnu.linkonce.r.*)
        *(.ARM.extab* .gnu.linkonce.armextab.*)

        /* Support C constructors, and C destructors in both user code
           and the C library. This also provides support for C++ code. */
        . = ALIGN(4);
        KEEP(*(.init))
        . = ALIGN(4);
        __preinit_array_start = .;
        KEEP (*(.preinit_array))
        __preinit_array_end = .;

        . = ALIGN(4);
        __init_array_start = .;
        KEEP (*(SORT(.init_array.*)))
        KEEP (*(.init_array))
        __init_array_end = .;

        . = ALIGN(0x4);
        KEEP (*crtbegin.o(.ctors))
        KEEP (*(EXCLUDE_FILE (*crtend.o) .ctors))
        KEEP (*(SORT(.ctors.*)))        
		KEEP (*crtend.o(.ctors))

        . = ALIGN(4);
        KEEP(*(.fini))
				
        . = ALIGN(4);
        __fini_array_start = .;
        KEEP (*(.fini_array))
        KEEP (*(SORT(.fini_array.*)))
        __fini_array_end = .;

		

        KEEP (*crtbegin.o(.dtors))
        KEEP (*(EXCLUDE_FILE (*crtend.o) .dtors))
        KEEP (*(SORT(.dtors.*)))
        KEEP (*crtend.o(.dtors))

        . = ALIGN(4);
        _efixed = .;            /* End of text section */
    } > rom

    /* .ARM.exidx is sorted, so has to go in its own output section.  */
    PROVIDE_HIDDEN (__exidx_start = .);
    .ARM.exidx :
    {
      *(.ARM.exidx* .gnu.linkonce.armexidx.*)
    } > rom
    PROVIDE_HIDDEN (__exidx_end = .);

	. = ALIGN(4);
    _etext = .;
   
	.relocate : AT (_etext)
    {
        . = ALIGN(4);
        _srelocate = .;
        *(.ramfunc .ramfunc.*);
        *(.data .data.*);
        . = ALIGN(4);
        _erelocate = .;
    } > ram

    /* .bss section which is used for uninitialized data */
    .bss (NOLOAD) :
    {
        . = ALIGN(4);
        _sbss = . ;
        _szero = .;
        *(.bss .bss.*)
        *(COMMON)
        . = ALIGN(4);
        _ebss = . ;
        _ezero = .;
    } > ram

    /* stack section */
    .stack (NOLOAD):
    {
        . = ALIGN(8);
        _sstack = .;
        . = . + STACK_SIZE;
        . = ALIGN(8);
        _estack = .;
    } > ram

    /* heap section */
    .heap (NOLOAD):
    {
        . = ALIGN(8);
         _sheap = .;
        . = . + HEAP_SIZE;
        . = ALIGN(8);
        _eheap = .;
    } > ram

    . = ALIGN(4);
    _end = . ;
    _ram_end_ = ORIGIN(ram) + LENGTH(ram) -1 ;
}

Re: Constant at fixed address

[David Brown]

On 25/02/2022 22:37, Henrique Coser wrote:
> Martin and David,  thank you for your answers.
> 
> Attached is the linker script that I use.
> 
> In Keil, where I did the first version of the boot loader I can assure you that a constant value is placed and correctly filled when use __attribute__((at(0x0401000)))
> I don't know how they do this but they do!
> 
> I would be grateful If you could help me editting this script.
> 
> Thank you very much.
> 
> 

The length of your "rom" space in sam3s4b_flash.ld does not make much
sense.  I haven't used Atmel's SAM devices, but I'd be surprised to see
one with a little under 12 K flash.

The linker files you attached are not, I think, the ones you used when
you got the link error - they don't have any mention of the
".bootversion" section.  So all I can do is show a typical way to have
this set up in a linker file.



Your "rom" section starts with :

   .text :
    {
        . = ALIGN(4);
        _sfixed = .;
        KEEP(*(.vectors .vectors.*))
        *(.text .text.* .gnu.linkonce.t.*)
        ...
    } > rom

That will put the ".vectors" section(s) first, at the start of rom, then
everything after it.

What you need to have is the fixed sections, then everything that can be
freely allocated:

   .headers :
    {
        FILL(0xff)
        . = ALIGN(4);
        _sfixed = .;
        KEEP(*(.vectors .vectors.*))
        . = 0x1000;
        KEEP(*(.bootversion .bootversion.*))
    } > rom

   .text :
    {
        . = ALIGN(4);
        *(.text .text.* .gnu.linkonce.t.*)
        ...
    } > rom


Then the main ".text" and other flash sections get put after the
bootversion section, and you don't get an overlap.

This wastes the space between the vectors and the fixed .bootversion
section, but you could put other data there if you like (maybe some of
the arrays used for constructors or initialisation).  Don't bother
unless you are tight for space.

RE: Constant at fixed address

[Henrique Coser]

David,

Sorry, I was not clear enough about my system.

The Atmel , sam3s4b that I use has more memmory than that.
I have limited the flash since this part of code is a boot loader that is separeted of main application.
During firmware upgrade only the main application is erased and the boot loader  remains in the memmory.

Boot loader area must be lower than 5KB (0x1400) to keep space enough for main application.
So If I change the script as you propoused, I will not have space enough for boot loader.

The section is not declared into the script, is declared as a linker parameter :

 -Wl,-section-start=.bootversion=0x00401000

I have already tried to make a "hole" in memmory.
Imagine that you have a splited flash, like if you have two memmory banks, how should I change the script to automatically distribute the code between these two "memmory banks"?

If I find a way to make this split , I can put the boot loader version in the middle.
What I wanted is something that can do this as easy as Keil does.
I know that Keil will make it and will work, but since is the trial version, I can not embed this solution using Keil.

Thank you very much for all attention that you gave.



Henrique Coser

Engenharia



TEX Equip.Eletronicos Ind.e Com.Ltda.

Fone: (+5511) 4591-2825

henrique.coser@tex.com.br<mailto:compras@tex.com.br>

MEDIR PARA MELHORAR!
________________________________
De: David Brown <david.brown@hesbynett.no>
Enviado: 26 de fevereiro de 2022 15:57
Para: Henrique Coser <henrique.coser@tex.com.br>; Martin Sebor <msebor@gmail.com>; gcc-help@gcc.gnu.org <gcc-help@gcc.gnu.org>
Assunto: Re: Constant at fixed address

On 25/02/2022 22:37, Henrique Coser wrote:
> Martin and David,  thank you for your answers.
>
> Attached is the linker script that I use.
>
> In Keil, where I did the first version of the boot loader I can assure you that a constant value is placed and correctly filled when use __attribute__((at(0x0401000)))
> I don't know how they do this but they do!
>
> I would be grateful If you could help me editting this script.
>
> Thank you very much.
>
>

The length of your "rom" space in sam3s4b_flash.ld does not make much
sense.  I haven't used Atmel's SAM devices, but I'd be surprised to see
one with a little under 12 K flash.

The linker files you attached are not, I think, the ones you used when
you got the link error - they don't have any mention of the
".bootversion" section.  So all I can do is show a typical way to have
this set up in a linker file.



Your "rom" section starts with :

   .text :
    {
        . = ALIGN(4);
        _sfixed = .;
        KEEP(*(.vectors .vectors.*))
        *(.text .text.* .gnu.linkonce.t.*)
        ...
    } > rom

That will put the ".vectors" section(s) first, at the start of rom, then
everything after it.

What you need to have is the fixed sections, then everything that can be
freely allocated:

   .headers :
    {
        FILL(0xff)
        . = ALIGN(4);
        _sfixed = .;
        KEEP(*(.vectors .vectors.*))
        . = 0x1000;
        KEEP(*(.bootversion .bootversion.*))
    } > rom

   .text :
    {
        . = ALIGN(4);
        *(.text .text.* .gnu.linkonce.t.*)
        ...
    } > rom


Then the main ".text" and other flash sections get put after the
bootversion section, and you don't get an overlap.

This wastes the space between the vectors and the fixed .bootversion
section, but you could put other data there if you like (maybe some of
the arrays used for constructors or initialisation).  Don't bother
unless you are tight for space.

Re: Constant at fixed address

[David Brown]

Hi,

Basically, whoever planned this setup is doing things wrong.  I don't
know if it is too late to change things, but it is a really bad idea to
have a fixed-address section in the middle of your memory.  It is
especially bad when you have so little of it.  The fixed-size section
should be squeezed tightly against existing fixed-size sections (such as
the vector table), or the end of memory.

I believe it is possible to have binutils linker do what you want.  The
trick would be to make to flash regions in your "memory" section:

    MEMORY {
          rom1 (rx)  : ORIGIN = 0x00400000, LENGTH = 0x00001000
          rom2 (rx)  : ORIGIN = 0x00401000, LENGTH = 0x000003F6
    }


Then in your sections you'll have :

    .text1 :
    {
         FILL(0xff)
         . = ALIGN(4);
         _sfixed = .;
         KEEP(*(.vectors .vectors.*))
	
    	 ...  All the flash bits except the following one

         . = ALIGN(4);
         *(.text .text.* .gnu.linkonce.t.*)

     } > rom1


    .text2 :
    {
         KEEP(*(.bootversion .bootversion.*))
         . = ALIGN(4);
         *(.text .text.* .gnu.linkonce.t.*)
    } > rom2

You need to have the linker switch "--enable-non-contigous-regions"
enabled.  You also want the compiler switch "-ffunction-sections", so
that each function gets its own section.

What you will be doing now is putting most of the small sections
(initialisation arrays, etc.) into the first 4K block of flash.  Then
you put all the ".text" sections, which can go anywhere.  (The
initialisation tables need to be kept a bit more together in some
cases.)  The linker will try to put the .text sections into the first
rom1 block, but if it fails it will put them in rom2.

mvh.,

David




On 28/02/2022 16:16, Henrique Coser wrote:
> David,
> 
> Sorry, I was not clear enough about my system.
> 
> The Atmel , sam3s4b that I use has more memmory than that.
> I have limited the flash since this part of code is a boot loader that
> is separeted of main application.
> During firmware upgrade only the main application is erased and the boot
> loader  remains in the memmory.
> 
> Boot loader area must be lower than 5KB (0x1400) to keep space enough
> for main application.
> So If I change the script as you propoused, I will not have space enough
> for boot loader.
> 
> The section is not declared into the script, is declared as a linker
> parameter :
> 
>  -Wl,-section-start=.bootversion=0x00401000
> 
> I have already tried to make a "hole" in memmory.
> Imagine that you have a splited flash, like if you have two memmory
> banks, how should I change the script to automatically distribute the
> code between these two "memmory banks"?
> 
> If I find a way to make this split , I can put the boot loader version
> in the middle.
> What I wanted is something that can do this as easy as Keil does.
> I know that Keil will make it and will work, but since is the trial
> version, I can not embed this solution using Keil.
> 
> Thank you very much for all attention that you gave.
> 
> 
> */Henrique Coser/*
> 
> *Engenharia*
> 
> * *
> 
> *TEX Equip.Eletronicos Ind.e Com.Ltda.*
> 
> *Fone: (+5511) 4591-2825 *
> 
> /henrique.coser@tex.com.br/ <mailto:compras@tex.com.br>
> 
> */MEDIR PARA MELHORAR!/*
> ------------------------------------------------------------------------
> *De:* David Brown <david.brown@hesbynett.no>
> *Enviado:* 26 de fevereiro de 2022 15:57
> *Para:* Henrique Coser <henrique.coser@tex.com.br>; Martin Sebor
> <msebor@gmail.com>; gcc-help@gcc.gnu.org <gcc-help@gcc.gnu.org>
> *Assunto:* Re: Constant at fixed address
>  
> On 25/02/2022 22:37, Henrique Coser wrote:
>> Martin and David,  thank you for your answers.
>> 
>> Attached is the linker script that I use.
>> 
>> In Keil, where I did the first version of the boot loader I can assure you that a constant value is placed and correctly filled when use __attribute__((at(0x0401000)))
>> I don't know how they do this but they do!
>> 
>> I would be grateful If you could help me editting this script.
>> 
>> Thank you very much.
>> 
>> 
> 
> The length of your "rom" space in sam3s4b_flash.ld does not make much
> sense.  I haven't used Atmel's SAM devices, but I'd be surprised to see
> one with a little under 12 K flash.
> 
> The linker files you attached are not, I think, the ones you used when
> you got the link error - they don't have any mention of the
> ".bootversion" section.  So all I can do is show a typical way to have
> this set up in a linker file.
> 
> 
> 
> Your "rom" section starts with :
> 
>    .text :
>     {
>         . = ALIGN(4);
>         _sfixed = .;
>         KEEP(*(.vectors .vectors.*))
>         *(.text .text.* .gnu.linkonce.t.*)
>         ...
>     } > rom
> 
> That will put the ".vectors" section(s) first, at the start of rom, then
> everything after it.
> 
> What you need to have is the fixed sections, then everything that can be
> freely allocated:
> 
>    .headers :
>     {
>         FILL(0xff)
>         . = ALIGN(4);
>         _sfixed = .;
>         KEEP(*(.vectors .vectors.*))
>         . = 0x1000;
>         KEEP(*(.bootversion .bootversion.*))
>     } > rom
> 
>    .text :
>     {
>         . = ALIGN(4);
>         *(.text .text.* .gnu.linkonce.t.*)
>         ...
>     } > rom
> 
> 
> Then the main ".text" and other flash sections get put after the
> bootversion section, and you don't get an overlap.
> 
> This wastes the space between the vectors and the fixed .bootversion
> section, but you could put other data there if you like (maybe some of
> the arrays used for constructors or initialisation).  Don't bother
> unless you are tight for space.