From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from spam02.hesby.net (spam01.hesby.net [81.29.32.152]) by sourceware.org (Postfix) with ESMTP id 8BEF43858C83 for ; Mon, 28 Feb 2022 15:50:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8BEF43858C83 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=hesbynett.no Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hesbynett.no Received: from [192.168.0.63] (unknown [79.161.10.130]) by spam02.hesby.net (Halon) with ESMTPSA id 22aa3e68-98ae-11ec-920b-506b8dfa0e58; Mon, 28 Feb 2022 16:50:23 +0100 (CET) Subject: Re: Constant at fixed address To: Henrique Coser , Martin Sebor , "gcc-help@gcc.gnu.org" References: <723b5ea5-7cbb-a36e-0734-9cae443eda70@gmail.com> <16a27a10-fef4-c561-a01a-dbd3a03d1e8f@hesbynett.no> From: David Brown Message-ID: <01882772-82d4-859f-5b2e-78b8a982a1b5@hesbynett.no> Date: Mon, 28 Feb 2022 16:50:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3028.5 required=5.0 tests=BAYES_00, FOREIGN_BODY1, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2022 15:50:28 -0000 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/ > > */MEDIR PARA MELHORAR!/* > ------------------------------------------------------------------------ > *De:* David Brown > *Enviado:* 26 de fevereiro de 2022 15:57 > *Para:* Henrique Coser ; Martin Sebor > ; 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.