public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Brown <david.brown@hesbynett.no>
To: Henrique Coser <henrique.coser@tex.com.br>,
	Martin Sebor <msebor@gmail.com>,
	"gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>
Subject: Re: Constant at fixed address
Date: Sat, 26 Feb 2022 19:57:00 +0100	[thread overview]
Message-ID: <16a27a10-fef4-c561-a01a-dbd3a03d1e8f@hesbynett.no> (raw)
In-Reply-To: <FR1PR80MB474479F7C5AA397C0631FBD3BD3E9@FR1PR80MB4744.lamprd80.prod.outlook.com>

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.

  reply	other threads:[~2022-02-26 18:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-25 16:01 Henrique Coser
2022-02-25 16:45 ` Martin Sebor
2022-02-25 17:56   ` David Brown
2022-02-25 18:18     ` AW: " stefan
2022-02-26 18:56       ` David Brown
2022-02-25 21:37     ` Henrique Coser
2022-02-26 18:57       ` David Brown [this message]
2022-02-28 15:16         ` Henrique Coser
2022-02-28 15:50           ` David Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16a27a10-fef4-c561-a01a-dbd3a03d1e8f@hesbynett.no \
    --to=david.brown@hesbynett.no \
    --cc=gcc-help@gcc.gnu.org \
    --cc=henrique.coser@tex.com.br \
    --cc=msebor@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).