From hondgm at yahoo.com Wed Apr 4 16:33:56 2012 From: hondgm at yahoo.com (JM) Date: Wed, 4 Apr 2012 09:33:56 -0700 (PDT) Subject: [arm-gnu] Placing variable at absolute address in RAM Message-ID: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> Hello I've researched this, asked on other forums, and so far I'm no closer.?? I'm trying to place a variable at a specific address in RAM on a TI ARM Cortex-M3.? I have good reason for doing so, which I can explain briefly: The micro I'm using, LM3S9B92 has a DMA controller.? There are 32 DMA channels and each channel requires a 16 byte struct in RAM for housekeeping.? These 32 structs are placed into an array, which is 512 bytes if you do the math, and must be placed on a 1024 byte boundary.? Now....the datasheet indicates that the RAM for unused DMA channels can be used for something else.? I'm using only one DMA channel, which is near the end of the list.? If it were near the beginning, this would be easier to recover at least some of the wasted RAM by simply not making the array 32 members long. So what I want to do is reserve 16 bytes of RAM at a strategic location.? It must be 464 bytes from a 1024 byte boundary.? This I believe will allow the lone DMA channel to function and not allocate unused RAM. I believe this will involve the linker script, and possibly Makefile.? I'm ok with Makefile modifications.? The linker file I'm almost clueless on.? Any ideas?? My current linker file is below: MEMORY { ??? FLASH (rx) : ORIGIN = 0x00001000, LENGTH = 252K ??? SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 96K } SECTIONS { ??? .text : ??? { ??????? KEEP(*(.isr_vector)) ??????? *(.text*) ??????? *(.rodata*) ??????? _etext = .; ??? } > FLASH ??? .data : AT (ADDR(.text) + SIZEOF(.text)) ??? { ??????? _data = .; ??????? *(vtable) ??????? *(.data*) ??????? _edata = .; ??? } > SRAM ??? .bss(NOLOAD) : ??? { ??????? _bss = .; ??????? *(.bss*) ??????? *(COMMON) ??????? _ebss = .; ??????? . = ALIGN (8); ?????? _end = .; ??? } > SRAM } /* end of allocated ram _end */ PROVIDE( _HEAP_START = _end ); /* end of the heap -> align 8 byte */ PROVIDE ( _HEAP_END = ALIGN(ORIGIN(SRAM) + LENGTH(SRAM),8) ); -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom_usenet at optusnet.com.au Thu Apr 5 05:24:24 2012 From: tom_usenet at optusnet.com.au (Tom Evans) Date: Thu, 05 Apr 2012 15:24:24 +1000 Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> Message-ID: <4F7D2C88.6030504@optusnet.com.au> JM wrote: > Hello > > I've researched this, asked on other forums, and so far I'm no closer. > > I'm trying to place a variable at a specific address in RAM on a TI ARM > Cortex-M3. I have good reason for doing so, which I can explain briefly: How about just calling malloc() in a loop until you get an allocation that matches all of your addressing requirements, and then free all the ones that didn't. Brutal, but it should work if called very early on in your startup before anything else has got to malloc(). If you don't have "malloc" then you should have something similar managing your heap that could be abused to do this for you. Tom From bob.brusa at gmail.com Thu Apr 5 09:31:47 2012 From: bob.brusa at gmail.com (Bob Brusa) Date: Thu, 05 Apr 2012 09:31:47 +0000 Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> Message-ID: <4F7D6683.8060105@gmail.com> Am 04.04.2012 16:33, schrieb JM: > Hello > > I've researched this, asked on other forums, and so far I'm no closer. > > I'm trying to place a variable at a specific address in RAM on a TI ARM > Cortex-M3. I have good reason for doing so, which I can explain briefly: > > The micro I'm using, LM3S9B92 has a DMA controller. There are 32 DMA > channels and each channel requires a 16 byte struct in RAM for > housekeeping. These 32 structs are placed into an array, which is 512 > bytes if you do the math, and must be placed on a 1024 byte boundary. > Now....the datasheet indicates that the RAM for unused DMA channels can > be used for something else. I'm using only one DMA channel, which is > near the end of the list. If it were near the beginning, this would be > easier to recover at least some of the wasted RAM by simply not making > the array 32 members long. > > So what I want to do is reserve 16 bytes of RAM at a strategic location. > It must be 464 bytes from a 1024 byte boundary. This I believe will > allow the lone DMA channel to function and not allocate unused RAM. > > I believe this will involve the linker script, and possibly Makefile. > I'm ok with Makefile modifications. The linker file I'm almost clueless > on. Any ideas? My current linker file is below: > > MEMORY > { > FLASH (rx) : ORIGIN = 0x00001000, LENGTH = 252K > SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 96K > } > > SECTIONS > { > .text : > { > KEEP(*(.isr_vector)) > *(.text*) > *(.rodata*) > _etext = .; > } > FLASH > > .data : AT (ADDR(.text) + SIZEOF(.text)) > { > _data = .; > *(vtable) > *(.data*) > _edata = .; > } > SRAM > > .bss(NOLOAD) : > { > _bss = .; > *(.bss*) > *(COMMON) > _ebss = .; > . = ALIGN (8); > _end = .; > } > SRAM > } > > /* end of allocated ram _end */ > PROVIDE( _HEAP_START = _end ); > > /* end of the heap -> align 8 byte */ > PROVIDE ( _HEAP_END = ALIGN(ORIGIN(SRAM) + LENGTH(SRAM),8) ); > > > > > > > _______________________________________________ > arm-gnu mailing list > arm-gnu at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu Hi, two years ago I had a similar problem. I needed an area at a fixed address in flash and an other at a known place in ram - with the requirement, that this part of the ram should not be initialized upon startup of the program. And here is what I did: The trick is to define new sections. For the flash case I added the following lines at the beginning of the relevant source: #define EEPromArea 0x400 cyg_uint8 eeprombottom[EEPromArea] __attribute__ ((section (".eeromemu"))); and for the sram case (nvv_t is a user-defined type): nvv_t nvv __attribute__ ((section (".sticky"))); The standard loader file then needs a few modifications - see attachment. Hope this helps. Regards Bob -------------- next part -------------- STARTUP(vectors.o) ENTRY(reset_vector) INPUT(extras.o) GROUP( libtarget.a libgcc.a libsupc++.a ) /* redboot rb_5 uses memory as follows: * RAM 0x00200000..0x002057f8 parameters * RAM 0x0021F300..0x00220000 work-area size 0xD00=3328 ?? where from is this info ?? * Flash 0x00100000..0x00111288 redboot code * Flash 0x00113C00..0x00114000 config-area */ MEMORY { rom : ORIGIN = 0x00114000, LENGTH = 0x6BC00 /* go above redboot rb_5 */ eerom : ORIGIN = 0x0017FC00, LENGTH = 0x00400 /* eerom emulation area */ ram : ORIGIN = 0x00205800, LENGTH = 0x19a00 /* above redboot */ sram (!I): ORIGIN = 0x0021F200, LENGTH = 0x00100 /* for nvv and below ws of redboot */ } SECTIONS { .debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : { *(.debug_pubnames) } .debug_info 0 : { *(.debug_info) } .debug_abbrev 0 : { *(.debug_abbrev) } .debug_line 0 : { *(.debug_line) } .debug_frame 0 : { *(.debug_frame) } .debug_str 0 : { *(.debug_str) } .debug_loc 0 : { *(.debug_loc) } .debug_macinfo 0 : { *(.debug_macinfo) } .note.arm.ident 0 : { KEEP (*(.note.arm.ident)) } /DISCARD/ 0 : { *(.fini_array*) } __reserved_bootmon = 0x00000000; . = __reserved_bootmon + 0x01000; .rom_vectors 0x00114000 : { __rom_vectors_vma = ABSOLUTE(.); . = .; KEEP (*(.vectors)) } > rom __rom_vectors_lma = LOADADDR(.rom_vectors); .ARM.extab ALIGN (0x1) : { PROVIDE (__stext = ABSOLUTE(.)); _stext = ABSOLUTE(.) ; . = .; } > rom /DISCARD/ 0 : { *(.ARM.extab* .gnu.linkonce.armextab.*) } . = ALIGN(8); . = ALIGN(8); __exidx_start = ABSOLUTE(.); .ARM.exidx ALIGN(8) : AT ((LOADADDR (.ARM.extab) + SIZEOF (.ARM.extab) + (8) - 1) & ~ ((8) - 1)) { . = .; } > rom __exidx_end = ABSOLUTE(.); /DISCARD/ 0 : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) } .text ALIGN(8) : AT ((LOADADDR (.ARM.exidx) + SIZEOF (.ARM.exidx) + (8) - 1) & ~ ((8) - 1)) { *(.text*) *(.gnu.warning) *(.gnu.linkonce.t.*) *(.init) *(.glue_7) *(.glue_7t) __CTOR_LIST__ = ABSOLUTE (.); KEEP (*(SORT (.ctors*))) __CTOR_END__ = ABSOLUTE (.); __DTOR_LIST__ = ABSOLUTE (.); KEEP (*(SORT (.dtors*))) __DTOR_END__ = ABSOLUTE (.); } > rom _etext = .; PROVIDE (__etext = .); .fini ALIGN (0x4) : { . = .; *(.fini) } > rom .rodata ALIGN (0x4) : { . = .; *(.rodata*) *(.gnu.linkonce.r.*) } > rom .rodata1 ALIGN (0x4) : { . = .; *(.rodata1) } > rom .fixup ALIGN (0x4) : { . = .; *(.fixup) } > rom .gcc_except_table ALIGN (0x4) : { . = .; } > rom /DISCARD/ 0 : { *(.gcc_except_table*) } .eeromemu 0x0017FC00 (NOLOAD) : { . = .; *(.eeromemu) } > eerom .sticky 0x0021F200 (NOLOAD) : { . = .; *(.sticky) } > sram /* store nvv here */ .fixed_vectors 0x00205800 : { . = .; KEEP (*(.fixed_vectors)) } > ram .data ALIGN (0x4) : AT ((LOADADDR (.gcc_except_table) + SIZEOF (.gcc_except_table) + (4) - 1) & ~ ((4) - 1)) { __ram_data_start = ABSOLUTE (.); *(.data*) *(.data1) *(.gnu.linkonce.d.*) . = ALIGN (4); KEEP(*( SORT (.ecos.table.*))) ; . = ALIGN (4); __init_array_start__ = ABSOLUTE (.); KEEP (*(SORT (.init_array.*))) KEEP (*(SORT (.init_array))) __init_array_end__ = ABSOLUTE (.); *(.dynamic) *(.sdata*) *(.gnu.linkonce.s.*) . = ALIGN (4); *(.2ram.*) } > ram __rom_data_start = LOADADDR (.data); __ram_data_end = .; PROVIDE (__ram_data_end = .); _edata = .; PROVIDE (edata = .); PROVIDE (__rom_data_end = LOADADDR (.data) + SIZEOF(.data)); .bss ALIGN (0x4) : { __bss_start = ABSOLUTE (.); *(.scommon) *(.dynsbss) *(.sbss*) *(.gnu.linkonce.sb.*) *(.dynbss) *(.bss*) *(.gnu.linkonce.b.*) *(COMMON) __bss_end = ABSOLUTE (.); } > ram __heap1 = ALIGN (0x8); . = ALIGN(4); _end = .; PROVIDE (end = .); } From hondgm at yahoo.com Thu Apr 5 10:43:24 2012 From: hondgm at yahoo.com (JM) Date: Thu, 5 Apr 2012 03:43:24 -0700 (PDT) Subject: [arm-gnu] Placing variable at absolute address in RAM Message-ID: <1333622604.70671.YahooMailNeo@web162706.mail.bf1.yahoo.com> Wow, lots of great suggestions, much more than I got at other forums, and quicker, too.? Thank you all and I will be using everything to come up with a solution. > Hello > > I've researched this, asked on other forums, and so far I'm no closer. > > I'm trying to place a variable at a specific address in RAM on a TI ARM > Cortex-M3. I have good reason for doing so, which I can explain briefly: > > The micro I'm using, LM3S9B92 has a DMA controller. There are 32 DMA > channels and each channel requires a 16 byte struct in RAM for > housekeeping. These 32 structs are placed into an array, which is 512 > bytes if you do the math, and must be placed on a 1024 byte boundary. > Now....the datasheet indicates that the RAM for unused DMA channels can > be used for something else. I'm using only one DMA channel, which is > near the end of the list. If it were near the beginning, this would be > easier to recover at least some of the wasted RAM by simply not making > the array 32 members long. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.brusa at gmail.com Thu Apr 5 12:04:26 2012 From: bob.brusa at gmail.com (Bob Brusa) Date: Thu, 05 Apr 2012 12:04:26 +0000 Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <1333622604.70671.YahooMailNeo@web162706.mail.bf1.yahoo.com> References: <1333622604.70671.YahooMailNeo@web162706.mail.bf1.yahoo.com> Message-ID: <4F7D8A4A.7040609@gmail.com> Am 05.04.2012 10:43, schrieb JM: > Wow, lots of great suggestions, much more than I got at other forums, > and quicker, too. Thank you all and I will be using everything to come > up with a solution. > > > > Hello > > > > I've researched this, asked on other forums, and so far I'm no closer. > > > > I'm trying to place a variable at a specific address in RAM on a TI ARM > > Cortex-M3. I have good reason for doing so, which I can explain briefly: > > > > The micro I'm using, LM3S9B92 has a DMA controller. There are 32 DMA > > channels and each channel requires a 16 byte struct in RAM for > > housekeeping. These 32 structs are placed into an array, which is 512 > > bytes if you do the math, and must be placed on a 1024 byte boundary. > > Now....the datasheet indicates that the RAM for unused DMA channels can > > be used for something else. I'm using only one DMA channel, which is > > near the end of the list. If it were near the beginning, this would be > > easier to recover at least some of the wasted RAM by simply not making > > the array 32 members long. > > > > > _______________________________________________ > arm-gnu mailing list > arm-gnu at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu Great you got so many answers. Unfortunately all these people (except Tom) sent their answers to your email-address - instead of mailing back to the list. When answering to the list, everybody can see if there are answers of sufficient significance - and hence stop answering to already answered questions. Just for next time - bob From hondgm at yahoo.com Thu Apr 5 14:02:47 2012 From: hondgm at yahoo.com (JM) Date: Thu, 5 Apr 2012 07:02:47 -0700 (PDT) Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <4F7D2C88.6030504@optusnet.com.au> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D2C88.6030504@optusnet.com.au> Message-ID: <1333634567.11179.YahooMailNeo@web162703.mail.bf1.yahoo.com> ________________________________ From: Tom Evans To: JM Cc: "arm-gnu at codesourcery.com" Sent: Thursday, April 5, 2012 1:24 AM Subject: Re: [arm-gnu] Placing variable at absolute address in RAM >JM wrote: > >Hello > > > >I've researched this, asked on other forums, and so far I'm no closer.? >> I'm trying to place a variable at a specific address in RAM on a TI ARM Cortex-M3.? I have good reason for doing so, which I can explain briefly: >How about just calling malloc() in a loop until you get an allocation that matches all of your addressing requirements, and then free all the ones that didn't. Brutal, but it should work if called >very early on in your startup before anything else has got to malloc(). >If you don't have "malloc" then you should have something similar managing your heap that could be abused to do this for you. >Tom Intriguing idea, but I actually do not use malloc, but rather a replacement I wrote that simply allocates RAM in consecutive chunks of the requested size.? I found malloc was wasting a few kilobytes of RAM so I did it this way.? If I did this in my case, it would leave 400-500 bytes unused. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hondgm at yahoo.com Thu Apr 5 14:12:25 2012 From: hondgm at yahoo.com (JM) Date: Thu, 5 Apr 2012 07:12:25 -0700 (PDT) Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <002501cd12fd$27b23a30$7716ae90$@uniserve.com> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D2C88.6030504@optusnet.com.au> <002501cd12fd$27b23a30$7716ae90$@uniserve.com> Message-ID: <1333635145.18997.YahooMailNeo@web162703.mail.bf1.yahoo.com> I started implementing your suggestion, but realized I have to split off a piece of RAM for HWMAP, which will waste a considerable amount of RAM...unless I'm misunderstanding something.? What I need, ideally,? is to reserve 16 bytes at an arbitrary place in the RAM space.? Unfortunately, since it must be 464 bytes after a 1024 byte boundary, it ends up being "in the middle" somewhere.? About 12K of the 96K is global or statically assigned, and the rest is allocated dynamically in fairly large chunks using a proprietary allocation system. I had no idea this would be so difficult, but apparently GCC doesn't make this easy, unlike other compilers.? Since I'm using the lite (free) compiler, buying one really isn't an option for hobby use. ________________________________ From: Alexander Zakharov To: tom_usenet at optusnet.com.au; 'JM' Cc: arm-gnu at codesourcery.com Sent: Thursday, April 5, 2012 3:24 AM Subject: RE: [arm-gnu] Placing variable at absolute address in RAM This is what I used in a past: In linker? 'helper' file hwmap.ld ............ .dmaRegisters??? ??? ??? 0X70000000??? ??? (NOLOAD): { *(.dmaRegisters)??? ??? ??? } > HWMAP ............ In source file hwmap.c ....... DMA_REGISTERS??? ??? ??? dmaRegisters __attribute__ ((used,section(".dmaRegisters"))); ....... In header file dmaRegisters.h ....... typedef struct { ? /* Something */? } DMA_REGISTERS; extern DMA_REGISTERS??? dmaRegisters; ......... And finally, in a main linker file my_board.ld ...... MEMORY { ? RAM? ? ? (rwx)? : ORIGIN = 0x00000000, LENGTH = 16M ? ROM? ? ? (rwx)? : ORIGIN = 0xFFFFFFFF, LENGTH = 0 ? ALIASMEM (rwx)? : ORIGIN = 0x10000000, LENGTH = 16M ? HWMAP? ? (rw )? : ORIGIN = 0x20000000, LENGTH = 3584M } ...... /* Include hardware registers maps */ ??? INCLUDE hwmap.ld ..... Then you just use dmaRegisters in your code like " dmaRegisters.field = X; " Hope it helps. This way you can 'stick' your variable in any place in a memory - this is how I implemented my hardware registers access in a past, but should work like a charm for your cause. Cheers, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From list-bastian.schick at sciopta.com Thu Apr 5 14:23:59 2012 From: list-bastian.schick at sciopta.com (42Bastian) Date: Thu, 05 Apr 2012 16:23:59 +0200 Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <1333635145.18997.YahooMailNeo@web162703.mail.bf1.yahoo.com> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D2C88.6030504@optusnet.com.au> <002501cd12fd$27b23a30$7716ae90$@uniserve.com> <1333635145.18997.YahooMailNeo@web162703.mail.bf1.yahoo.com> Message-ID: <4F7DAAFF.7050105@sciopta.com> > I had no idea this would be so difficult, but apparently GCC doesn't > make this easy, unlike other compilers. Since I'm using the lite > (free) compiler, buying one really isn't an option for hobby use. The problem is complicated. GCC makes it as easy as other compilers to place a variable somewhere. Your constraints (not wasting RAM) makes is complicated. Try (untested): . = ALIGN(1024); dma_ring = .; /* place some data here e.g.*/ test.o(.data .bss) toto.o(.data .bss) dma_eof_data = .; dma_desc = dma_ring+464; . = dma_desc+16; /* place more stuff */ Check the map file, that dma_desc is >= dma_eof_data. -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + From mdeneen+arm at saucontech.com Thu Apr 5 14:25:58 2012 From: mdeneen+arm at saucontech.com (Mark Deneen) Date: Thu, 5 Apr 2012 10:25:58 -0400 (EDT) Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <1333635145.18997.YahooMailNeo@web162703.mail.bf1.yahoo.com> Message-ID: <616016173.58050364.1333635958592.JavaMail.root@email> I don't think what you are trying to do is possible with GCC. You can specify that you want a variable at a particular address: int32 *var = (int32*)0x8000100; But you can't easily prevent this address from being used by something else. You could try splitting up the ram into 3 sections in the linker script, with one of the sections being the tiny 16 byte section. -M ----- Original Message ----- I started implementing your suggestion, but realized I have to split off a piece of RAM for HWMAP, which will waste a considerable amount of RAM...unless I'm misunderstanding something. What I need, ideally, is to reserve 16 bytes at an arbitrary place in the RAM space. Unfortunately, since it must be 464 bytes after a 1024 byte boundary, it ends up being "in the middle" somewhere. About 12K of the 96K is global or statically assigned, and the rest is allocated dynamically in fairly large chunks using a proprietary allocation system. I had no idea this would be so difficult, but apparently GCC doesn't make this easy, unlike other compilers. Since I'm using the lite (free) compiler, buying one really isn't an option for hobby use. From: Alexander Zakharov To: tom_usenet at optusnet.com.au; 'JM' Cc: arm-gnu at codesourcery.com Sent: Thursday, April 5, 2012 3:24 AM Subject: RE: [arm-gnu] Placing variable at absolute address in RAM This is what I used in a past: In linker 'helper' file hwmap.ld ............ .dmaRegisters 0X70000000 (NOLOAD): { *(.dmaRegisters) } > HWMAP ............ In source file hwmap.c ....... DMA_REGISTERS dmaRegisters __attribute__ ((used,section(".dmaRegisters"))); ....... In header file dmaRegisters.h ....... typedef struct { /* Something */ } DMA_REGISTERS; extern DMA_REGISTERS dmaRegisters; ......... And finally, in a main linker file my_board.ld ...... MEMORY { RAM (rwx) : ORIGIN = 0x00000000, LENGTH = 16M ROM (rwx) : ORIGIN = 0xFFFFFFFF, LENGTH = 0 ALIASMEM (rwx) : ORIGIN = 0x10000000, LENGTH = 16M HWMAP (rw ) : ORIGIN = 0x20000000, LENGTH = 3584M } ...... /* Include hardware registers maps */ INCLUDE hwmap.ld ..... Then you just use dmaRegisters in your code like " dmaRegisters.field = X; " Hope it helps. This way you can 'stick' your variable in any place in a memory - this is how I implemented my hardware registers access in a past, but should work like a charm for your cause. Cheers, Alex _______________________________________________ arm-gnu mailing list arm-gnu at codesourcery.com http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu From hondgm at yahoo.com Thu Apr 5 14:26:19 2012 From: hondgm at yahoo.com (JM) Date: Thu, 5 Apr 2012 07:26:19 -0700 (PDT) Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <4F7D6683.8060105@gmail.com> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D6683.8060105@gmail.com> Message-ID: <1333635979.27356.YahooMailNeo@web162702.mail.bf1.yahoo.com> I'm interested in what you did, but the attached file is formatted badly so I'm having a lot of trouble following it.? One line is 800 characters long; the formatting probably got screwed up.?? I've been coming to the realization that I have to define sections to do this.? But what I don't understand is how, when the RAM is split into three or more sections, will the linker treat the multiple "available" sections.? Let me explain. Out of the 96K RAM, it ends up being allocated roughly like this with one section: 0K - 12K : global and static variables 12K - 96K : available for dynamic allocation I can't place these 16 bytes into the latter area since it's the heap.? But, it can go into the first area.? So say I split it into sections of roughly these sizes: .section1: 0 - 464 bytes: global and static variables .section2: 464 bytes - 480 bytes: DMA structure .section3: 480bytes - 96K: global, static variables, and heap The question is, how do I tell the linker that .section1 and .section2 should be treated equally, that is, both are available for automatic allocation by the linker?? The answer may be in Bob's linker file, but I'm really ignorant about linker files (not that I haven't tried). ________________________________ From: Bob Brusa To: arm-gnu at codesourcery.com Sent: Thursday, April 5, 2012 5:31 AM Subject: Re: [arm-gnu] Placing variable at absolute address in RAM Am 04.04.2012 16:33, schrieb JM: > Hello > > I've researched this, asked on other forums, and so far I'm no closer. > > I'm trying to place a variable at a specific address in RAM on a TI ARM > Cortex-M3. I have good reason for doing so, which I can explain briefly: > > The micro I'm using, LM3S9B92 has a DMA controller. There are 32 DMA > channels and each channel requires a 16 byte struct in RAM for > housekeeping. These 32 structs are placed into an array, which is 512 > bytes if you do the math, and must be placed on a 1024 byte boundary. > Now....the datasheet indicates that the RAM for unused DMA channels can > be used for something else. I'm using only one DMA channel, which is > near the end of the list. If it were near the beginning, this would be > easier to recover at least some of the wasted RAM by simply not making > the array 32 members long. > > So what I want to do is reserve 16 bytes of RAM at a strategic location. > It must be 464 bytes from a 1024 byte boundary. This I believe will > allow the lone DMA channel to function and not allocate unused RAM. > > I believe this will involve the linker script, and possibly Makefile. > I'm ok with Makefile modifications. The linker file I'm almost clueless > on. Any ideas? My current linker file is below: > > MEMORY > { > FLASH (rx) : ORIGIN = 0x00001000, LENGTH = 252K > SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 96K > } > > SECTIONS > { > .text : > { > KEEP(*(.isr_vector)) > *(.text*) > *(.rodata*) > _etext = .; > } > FLASH > > .data : AT (ADDR(.text) + SIZEOF(.text)) > { > _data = .; > *(vtable) > *(.data*) > _edata = .; > } > SRAM > > .bss(NOLOAD) : > { > _bss = .; > *(.bss*) > *(COMMON) > _ebss = .; > . = ALIGN (8); > _end = .; > } > SRAM > } > > /* end of allocated ram _end */ > PROVIDE( _HEAP_START = _end ); > > /* end of the heap -> align 8 byte */ > PROVIDE ( _HEAP_END = ALIGN(ORIGIN(SRAM) + LENGTH(SRAM),8) ); > > > > > > > _______________________________________________ > arm-gnu mailing list > arm-gnu at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu Hi, two years ago I had a similar problem. I needed an area at a fixed address in flash and an other at a known place in ram - with the requirement, that this part of the ram should not be initialized upon startup of the program. And here is what I did: The trick is to define new sections. For the flash case I added the following lines at the beginning of the relevant source: #define EEPromArea??? 0x400 cyg_uint8 eeprombottom[EEPromArea]? __attribute__ ((section (".eeromemu"))); and for the sram case (nvv_t is a user-defined type): nvv_t nvv __attribute__ ((section (".sticky"))); The standard loader file then needs a few modifications - see attachment. Hope this helps. Regards Bob _______________________________________________ arm-gnu mailing list arm-gnu at codesourcery.com http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu -------------- next part -------------- An HTML attachment was scrubbed... URL: From list-bastian.schick at sciopta.com Thu Apr 5 14:31:35 2012 From: list-bastian.schick at sciopta.com (42Bastian) Date: Thu, 05 Apr 2012 16:31:35 +0200 Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <1333635979.27356.YahooMailNeo@web162702.mail.bf1.yahoo.com> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D6683.8060105@gmail.com> <1333635979.27356.YahooMailNeo@web162702.mail.bf1.yahoo.com> Message-ID: <4F7DACC7.30303@sciopta.com> > .section1: 0 - 464 bytes: global and static variables > .section2: 464 bytes - 480 bytes: DMA structure > .section3: 480bytes - 96K: global, static variables, and heap > > > The question is, how do I tell the linker that .section1 and .section2 should be treated equally, that is, both are available for automatic allocation by the linker? The answer may be in Bob's linker file, but I'm really ignorant about linker files (not that I haven't tried). GNU-ld does not do this automagically. You have to do it by hand. -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + From hondgm at yahoo.com Thu Apr 5 14:37:02 2012 From: hondgm at yahoo.com (JM) Date: Thu, 5 Apr 2012 07:37:02 -0700 (PDT) Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <4F7DAAFF.7050105@sciopta.com> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D2C88.6030504@optusnet.com.au> <002501cd12fd$27b23a30$7716ae90$@uniserve.com> <1333635145.18997.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7DAAFF.7050105@sciopta.com> Message-ID: <1333636622.51874.YahooMailNeo@web162704.mail.bf1.yahoo.com> The only reason I mentioned about GCC not making it easy is that apparently at least one compiler makes it easy.? I'm so jealous! With the RealView ARM C Compiler, you may use either pointer definitions (as shown above) or __attribute__((at(address))) keyword to define a variable at a fixed memory address. In contrast to the pointer construct, the following definition also makes a correct memory reservation, so that the area cannot be used twice. int var __attribute__((at(0x40001000))); ________________________________ From: 42Bastian To: arm-gnu at codesourcery.com Sent: Thursday, April 5, 2012 10:23 AM Subject: Re: [arm-gnu] Placing variable at absolute address in RAM > I had no idea this would be so difficult, but apparently GCC doesn't > make this easy, unlike other compilers.? Since I'm using the lite > (free) compiler, buying one really isn't an option for hobby use. The problem is complicated. GCC makes it as easy as other compilers to place a variable somewhere. Your constraints (not wasting RAM) makes is complicated. Try (untested): ??? . = ALIGN(1024); ??? dma_ring = .; ??? /* place some data here e.g.*/ ??? test.o(.data .bss) ??? toto.o(.data .bss) ??? dma_eof_data = .; ??? dma_desc = dma_ring+464; ??? . = dma_desc+16; ??? /* place more stuff */ Check the map file, that dma_desc is >= dma_eof_data. -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + _______________________________________________ arm-gnu mailing list arm-gnu at codesourcery.com http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdeneen+arm at saucontech.com Thu Apr 5 14:39:18 2012 From: mdeneen+arm at saucontech.com (Mark Deneen) Date: Thu, 5 Apr 2012 10:39:18 -0400 (EDT) Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <1333636622.51874.YahooMailNeo@web162704.mail.bf1.yahoo.com> Message-ID: <281732945.58057198.1333636758700.JavaMail.root@email> Is it possible to define the symbol in the linker file? I think I've seen that done before, but it might have been a Microchip modification to GCC/ld. -M ----- Original Message ----- The only reason I mentioned about GCC not making it easy is that apparently at least one compiler makes it easy. I'm so jealous! With the RealView ARM C Compiler, you may use either pointer definitions (as shown above) or __attribute__((at( address ))) keyword to define a variable at a fixed memory address. In contrast to the pointer construct, the following definition also makes a correct memory reservation, so that the area cannot be used twice. int var __attribute__((at(0x40001000))); From: 42Bastian To: arm-gnu at codesourcery.com Sent: Thursday, April 5, 2012 10:23 AM Subject: Re: [arm-gnu] Placing variable at absolute address in RAM The problem is complicated. GCC makes it as easy as other compilers to place a variable somewhere. Your constraints (not wasting RAM) makes is complicated. Try (untested): . = ALIGN(1024); dma_ring = .; /* place some data here e.g.*/ test.o(.data .bss) toto.o(.data .bss) dma_eof_data = .; dma_desc = dma_ring+464; . = dma_desc+16; /* place more stuff */ Check the map file, that dma_desc is >= dma_eof_data. From list-bastian.schick at sciopta.com Thu Apr 5 14:51:18 2012 From: list-bastian.schick at sciopta.com (42Bastian) Date: Thu, 05 Apr 2012 16:51:18 +0200 Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <1333636622.51874.YahooMailNeo@web162704.mail.bf1.yahoo.com> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D2C88.6030504@optusnet.com.au> <002501cd12fd$27b23a30$7716ae90$@uniserve.com> <1333635145.18997.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7DAAFF.7050105@sciopta.com> <1333636622.51874.YahooMailNeo@web162704.mail.bf1.yahoo.com> Message-ID: <4F7DB166.9080800@sciopta.com> Hi > With the RealView ARM C Compiler, you may use either pointer definitions (as shown above) or __attribute__((at(address))) keyword to define a variable at a fixed memory address. In contrast to GCC was not designed for embedded :-) > the pointer construct, the following definition also makes a correct > memory reservation, so that the area cannot be used twice. > int var __attribute__((at(0x40001000))); Yes, this is a missing feature. Feel free to add it to ld (sources are available) ;-) -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + From mdeneen+arm at saucontech.com Thu Apr 5 14:54:24 2012 From: mdeneen+arm at saucontech.com (Mark Deneen) Date: Thu, 5 Apr 2012 10:54:24 -0400 (EDT) Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <4F7DB166.9080800@sciopta.com> Message-ID: <113493368.58064923.1333637664519.JavaMail.root@email> If you pass "-defsym,dmavar=0x80007000", will ld preserve this space or is it possible for it to assign another symbol at that location? -M ----- Original Message ----- Hi > With the RealView ARM C Compiler, you may use either pointer definitions (as shown above) or __attribute__((at(address))) keyword to define a variable at a fixed memory address. In contrast to GCC was not designed for embedded :-) > the pointer construct, the following definition also makes a correct > memory reservation, so that the area cannot be used twice. > int var __attribute__((at(0x40001000))); Yes, this is a missing feature. Feel free to add it to ld (sources are available) ;-) -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + _______________________________________________ arm-gnu mailing list arm-gnu at codesourcery.com http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu From list-bastian.schick at sciopta.com Thu Apr 5 15:01:46 2012 From: list-bastian.schick at sciopta.com (42Bastian) Date: Thu, 05 Apr 2012 17:01:46 +0200 Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <113493368.58064923.1333637664519.JavaMail.root@email> References: <113493368.58064923.1333637664519.JavaMail.root@email> Message-ID: <4F7DB3DA.2080606@sciopta.com> Am 05.04.2012 16:54, schrieb Mark Deneen: > If you pass "-defsym,dmavar=0x80007000", will ld preserve this space or is it possible for it to assign another symbol at that location? It will just define a symbol. No memory allocation. Memory is only allocated between SECTIONS { } -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + From hondgm at yahoo.com Thu Apr 5 16:40:04 2012 From: hondgm at yahoo.com (JM) Date: Thu, 5 Apr 2012 09:40:04 -0700 (PDT) Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <4F7DBE13.3070302@texband.net> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D2C88.6030504@optusnet.com.au> <002501cd12fd$27b23a30$7716ae90$@uniserve.com> <1333635145.18997.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7DAAFF.7050105@sciopta.com> <1333636622.51874.YahooMailNeo@web162704.mail.bf1.yahoo.com> <4F7DBE13.3070302@texband.net> Message-ID: <1333644004.21882.YahooMailNeo@web162703.mail.bf1.yahoo.com> I have come across that one a few times, but it doesn't reserve memory. ________________________________ From: Moses McKnight To: JM Sent: Thursday, April 5, 2012 11:45 AM Subject: Re: [arm-gnu] Placing variable at absolute address in RAM with a quick search I came up with the following link (among many others): http://stackoverflow.com/questions/4067811/how-to-place-a-variable-at-a-given-absolute-address-in-memory-with-gcc This is the way it is done in the CMSIS headers and in the device headers for the LPC chips I'm using. Moses On 04/05/2012 09:37 AM, JM wrote: > The only reason I mentioned about GCC not making it easy is that > apparently at least one compiler makes it easy. I'm so jealous! > > With the RealView ARM C Compiler, you may use either pointer definitions > (as shown above) or *__attribute__((at(/address/)))* keyword to define a > variable at a fixed memory address. In contrast to the pointer > construct, the following definition also makes a correct memory > reservation, so that the area cannot be used twice. > > int var __attribute__((at(0x40001000))); > > > ------------------------------------------------------------------------ > *From:* 42Bastian > *To:* arm-gnu at codesourcery.com > *Sent:* Thursday, April 5, 2012 10:23 AM > *Subject:* Re: [arm-gnu] Placing variable at absolute address in RAM > > >? > I had no idea this would be so difficult, but apparently GCC doesn't >? > make this easy, unlike other compilers. Since I'm using the lite >? > (free) compiler, buying one really isn't an option for hobby use. > > The problem is complicated. GCC makes it as easy as other compilers to > place a variable somewhere. > Your constraints (not wasting RAM) makes is complicated. > > Try (untested): > > . = ALIGN(1024); > dma_ring = .; > /* place some data here e.g.*/ > test.o(.data .bss) > toto.o(.data .bss) > dma_eof_data = .; > dma_desc = dma_ring+464; > . = dma_desc+16; > /* place more stuff */ > > Check the map file, that dma_desc is >= dma_eof_data. > > -- > 42Bastian > + > | http://www.sciopta.com > | Fastest direct message passing kernel. > | IEC61508 certified. > + > _______________________________________________ > arm-gnu mailing list > arm-gnu at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu > > > > > _______________________________________________ > arm-gnu mailing list > arm-gnu at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu -------------- next part -------------- An HTML attachment was scrubbed... URL: From azakharov at uniserve.com Thu Apr 5 07:24:34 2012 From: azakharov at uniserve.com (Alexander Zakharov) Date: Thu, 5 Apr 2012 03:24:34 -0400 Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <4F7D2C88.6030504@optusnet.com.au> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D2C88.6030504@optusnet.com.au> Message-ID: <002501cd12fd$27b23a30$7716ae90$@uniserve.com> This is what I used in a past: In linker 'helper' file hwmap.ld ............ .dmaRegisters 0X70000000 (NOLOAD): { *(.dmaRegisters) } > HWMAP ............ In source file hwmap.c ....... DMA_REGISTERS dmaRegisters __attribute__ ((used,section(".dmaRegisters"))); ....... In header file dmaRegisters.h ....... typedef struct { /* Something */ } DMA_REGISTERS; extern DMA_REGISTERS dmaRegisters; ......... And finally, in a main linker file my_board.ld ...... MEMORY { RAM (rwx) : ORIGIN = 0x00000000, LENGTH = 16M ROM (rwx) : ORIGIN = 0xFFFFFFFF, LENGTH = 0 ALIASMEM (rwx) : ORIGIN = 0x10000000, LENGTH = 16M HWMAP (rw ) : ORIGIN = 0x20000000, LENGTH = 3584M } ...... /* Include hardware registers maps */ INCLUDE hwmap.ld ..... Then you just use dmaRegisters in your code like " dmaRegisters.field = X; " Hope it helps. This way you can 'stick' your variable in any place in a memory - this is how I implemented my hardware registers access in a past, but should work like a charm for your cause. Cheers, Alex -----Original Message----- From: arm-gnu-bounces at codesourcery.com [mailto:arm-gnu-bounces at codesourcery.com] On Behalf Of Tom Evans Sent: Thursday, April 05, 2012 1:24 AM To: JM Cc: arm-gnu at codesourcery.com Subject: Re: [arm-gnu] Placing variable at absolute address in RAM JM wrote: > Hello > > I've researched this, asked on other forums, and so far I'm no closer. > > I'm trying to place a variable at a specific address in RAM on a TI > ARM Cortex-M3. I have good reason for doing so, which I can explain briefly: How about just calling malloc() in a loop until you get an allocation that matches all of your addressing requirements, and then free all the ones that didn't. Brutal, but it should work if called very early on in your startup before anything else has got to malloc(). If you don't have "malloc" then you should have something similar managing your heap that could be abused to do this for you. Tom _______________________________________________ arm-gnu mailing list arm-gnu at codesourcery.com http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu From g.modugno at elettronika.it Thu Apr 5 13:41:49 2012 From: g.modugno at elettronika.it (Giuseppe Modugno) Date: Thu, 05 Apr 2012 15:41:49 +0200 Subject: [arm-gnu] OSBDM support Message-ID: <4F7DA11D.17701.18D4744@g.modugno.elettronika.it> I'm new to ARM processors and Freescale Kinetis... I'm sorry for the dumb questions below. I'm using a Freescale Kinetis (ARM Cortex-M4) demo board with OSBDM interface integrated. I already installed OSDBM driver (downloader from www.pemicro.com website) so I can see correctly two peripherals (OSBDM Debug port and Virtual USB Serial Port). Now I'd like to use CodeSourcery suite for ARM to program (just now I want only program) the internal flash memory of the microcontroller, starting from a SREC file. I know I can use Debug Sprite tool to do that, but I couldn't find the definitive way. I already copied the two driver DLLs (libusb0.dll and osbdm-jm60.dll) in bin subdirectory where arm-none-eabi-sprite.exe and arm-none-eabi-gdb.exe are present. And now? How can I run -sprite and -gdb tools to program the flash? Thank you. ================================= ELETTRONIKA S.r.l. S.S. 96 Km.113 Z.I. 70027 PALO DEL COLLE (BA) - ITALY elettronika at elettronika.it http://www.elettronika.it Tel: +39 080 626755 Fax: +39 080 629262 ================================= Questo documento ? indirizzato esclusivamente al destinatario. Tutte le informazioni ivi contenute, compresi eventuali allegati, sono soggette a riservatezza secondo i termini del D.Lgs. 196/2003 in materia di "privacy" e ne ? proibito l'utilizzo da parte di altri soggetti. Se avesse ricevuto per errore questo messaggio, La preghiamo cortesemente di contattare il mittente al pi? presto e di cancellare il messaggio subito dopo. Grazie. ---- This document is exclusively intended for the stated addressee. All information therein, including any attachment, are reserved as per Italian D.Lgs. 196/2003 about privacy, and cannot be used by third parties. In case you received this message by mistake, please inform the sender and delete the message afterward. Thank you. From moses at texband.net Thu Apr 5 17:04:04 2012 From: moses at texband.net (Moses McKnight) Date: Thu, 05 Apr 2012 12:04:04 -0500 Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <1333644004.21882.YahooMailNeo@web162703.mail.bf1.yahoo.com> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D2C88.6030504@optusnet.com.au> <002501cd12fd$27b23a30$7716ae90$@uniserve.com> <1333635145.18997.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7DAAFF.7050105@sciopta.com> <1333636622.51874.YahooMailNeo@web162704.mail.bf1.yahoo.com> <4F7DBE13.3070302@texband.net> <1333644004.21882.YahooMailNeo@web162703.mail.bf1.yahoo.com> Message-ID: <4F7DD084.9000401@texband.net> Actually, I think it does. That example just reserved 4 bytes (sizeof(int)), but you can just as easily use a struct or probably even an array. Here's an example from the LPC17xx.h header from and NXP cortex-M3 chip. typedef struct { volatile uint32_t mask[512]; } LPC_CANAF_RAM_TypeDef; #define LPC_APB0_BASE (0x40000000UL) #define LPC_CANAF_RAM_BASE (LPC_APB0_BASE + 0x38000) #define LPC_CANAF_RAM ((LPC_CANAF_RAM_TypeDef *) LPC_CANAF_RAM_BASE) See the core_cm3.h file from CMSIS for more examples. If I'm not mistaken when you declare a variable the compiler/linker always reserves enough memory for that type - even when you specify the starting address like this. On 04/05/2012 11:40 AM, JM wrote: > I have come across that one a few times, but it doesn't reserve memory. > > ------------------------------------------------------------------------ > *From:* Moses McKnight > *To:* JM > *Sent:* Thursday, April 5, 2012 11:45 AM > *Subject:* Re: [arm-gnu] Placing variable at absolute address in RAM > > with a quick search I came up with the following link (among many others): > http://stackoverflow.com/questions/4067811/how-to-place-a-variable-at-a-given-absolute-address-in-memory-with-gcc > > This is the way it is done in the CMSIS headers and in the device > headers for the LPC chips I'm using. > > Moses > > On 04/05/2012 09:37 AM, JM wrote: > > The only reason I mentioned about GCC not making it easy is that > > apparently at least one compiler makes it easy. I'm so jealous! > > > > With the RealView ARM C Compiler, you may use either pointer definitions > > (as shown above) or *__attribute__((at(/address/)))* keyword to define a > > variable at a fixed memory address. In contrast to the pointer > > construct, the following definition also makes a correct memory > > reservation, so that the area cannot be used twice. > > > > int var __attribute__((at(0x40001000))); From mdeneen+arm at saucontech.com Thu Apr 5 17:07:36 2012 From: mdeneen+arm at saucontech.com (Mark Deneen) Date: Thu, 5 Apr 2012 13:07:36 -0400 (EDT) Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <4F7DD084.9000401@texband.net> Message-ID: <1654171021.58135080.1333645656645.JavaMail.root@email> In your example, nothing has been declared. Types have been defined, and you have a preprocessor macro mapping a particular address to a type, but nothing has been declared. I don't think that it's doing what you think it is doing. You're fine in this situation simply because you are accessing peripheral registers and not SRAM. -M ----- Original Message ----- Actually, I think it does. That example just reserved 4 bytes (sizeof(int)), but you can just as easily use a struct or probably even an array. Here's an example from the LPC17xx.h header from and NXP cortex-M3 chip. typedef struct { volatile uint32_t mask[512]; } LPC_CANAF_RAM_TypeDef; #define LPC_APB0_BASE (0x40000000UL) #define LPC_CANAF_RAM_BASE (LPC_APB0_BASE + 0x38000) #define LPC_CANAF_RAM ((LPC_CANAF_RAM_TypeDef *) LPC_CANAF_RAM_BASE) See the core_cm3.h file from CMSIS for more examples. If I'm not mistaken when you declare a variable the compiler/linker always reserves enough memory for that type - even when you specify the starting address like this. _______________________________________________ arm-gnu mailing list arm-gnu at codesourcery.com http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu From moses at texband.net Thu Apr 5 17:17:52 2012 From: moses at texband.net (Moses McKnight) Date: Thu, 05 Apr 2012 12:17:52 -0500 Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <1654171021.58135080.1333645656645.JavaMail.root@email> References: <1654171021.58135080.1333645656645.JavaMail.root@email> Message-ID: <4F7DD3C0.1030004@texband.net> Ok, looks like you're right there - bad example. But I think my basic idea is correct. Here is yet another link - see the post by Paul Curtis (he is a compiler writer) near the end. excerpt: struct my_placed_vars *my_vars = (void *)0x40003000; // EASY! #define MY_VAR_1 (my_vars->var_1) #define MY_VAR_2 (my_vars->var_2) COMPLETELY PORTABLE AMONGST ALL COMPILERS FOR THE GIVEN TARGET! On 04/05/2012 12:07 PM, Mark Deneen wrote: > In your example, nothing has been declared. Types have been defined, > and you have a preprocessor macro mapping a particular address to a > type, but nothing has been declared. > > I don't think that it's doing what you think it is doing. You're > fine in this situation simply because you are accessing peripheral > registers and not SRAM. > > -M > > ----- Original Message ----- Actually, I think it does. That example > just reserved 4 bytes (sizeof(int)), but you can just as easily use a > struct or probably even an array. > > Here's an example from the LPC17xx.h header from and NXP cortex-M3 > chip. > > typedef struct { volatile uint32_t mask[512]; } > LPC_CANAF_RAM_TypeDef; > > #define LPC_APB0_BASE (0x40000000UL) #define > LPC_CANAF_RAM_BASE (LPC_APB0_BASE + 0x38000) #define LPC_CANAF_RAM > ((LPC_CANAF_RAM_TypeDef *) LPC_CANAF_RAM_BASE) > > See the core_cm3.h file from CMSIS for more examples. > > If I'm not mistaken when you declare a variable the compiler/linker > always reserves enough memory for that type - even when you specify > the starting address like this. > > > _______________________________________________ arm-gnu mailing list > arm-gnu at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu > From mdeneen+arm at saucontech.com Thu Apr 5 17:22:35 2012 From: mdeneen+arm at saucontech.com (Mark Deneen) Date: Thu, 5 Apr 2012 13:22:35 -0400 (EDT) Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <4F7DD3C0.1030004@texband.net> Message-ID: <857298249.58142741.1333646555849.JavaMail.root@email> Even in this situation, haven't you just allocated space for a pointer to a struct? I don't see how GCC is going to do anything special here. -M ----- Original Message ----- Ok, looks like you're right there - bad example. But I think my basic idea is correct. Here is yet another link - see the post by Paul Curtis (he is a compiler writer) near the end. excerpt: struct my_placed_vars *my_vars = (void *)0x40003000; // EASY! #define MY_VAR_1 (my_vars->var_1) #define MY_VAR_2 (my_vars->var_2) COMPLETELY PORTABLE AMONGST ALL COMPILERS FOR THE GIVEN TARGET! From hondgm at yahoo.com Thu Apr 5 17:33:28 2012 From: hondgm at yahoo.com (JM) Date: Thu, 5 Apr 2012 10:33:28 -0700 (PDT) Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <4F7DD3C0.1030004@texband.net> References: <1654171021.58135080.1333645656645.JavaMail.root@email> <4F7DD3C0.1030004@texband.net> Message-ID: <1333647208.64619.YahooMailNeo@web162706.mail.bf1.yahoo.com> I just tried this again to make sure it doesn't work.? It didn't place my_vars anywhere near where I told it to. By the way, I finally fixed my problem by splitting the SRAM into two unequal pieces, with the tiny DMA section in the middle.? Then I manually assigned various variables to the small 464 byte section, and let the linker handle the 95.5K section.? Tedious but not that bad.? And there's apparently no other option.? ________________________________ From: Moses McKnight To: arm-gnu at codesourcery.com Sent: Thursday, April 5, 2012 1:17 PM Subject: Re: [arm-gnu] Placing variable at absolute address in RAM Ok, looks like you're right there - bad example.? But I think my basic idea is correct.? Here is yet another link - see the post by Paul Curtis (he is a compiler writer) near the end. excerpt: struct my_placed_vars *my_vars = (void *)0x40003000; // EASY! #define MY_VAR_1 (my_vars->var_1) #define MY_VAR_2 (my_vars->var_2) COMPLETELY PORTABLE AMONGST ALL COMPILERS FOR THE GIVEN TARGET! On 04/05/2012 12:07 PM, Mark Deneen wrote: > In your example, nothing has been declared.? Types have been defined, > and you have a preprocessor macro mapping a particular address to a > type, but nothing has been declared. > > I don't think that it's doing what you think it is doing.? You're > fine in this situation simply because you are accessing peripheral > registers and not SRAM. > > -M > > ----- Original Message ----- Actually, I think it does.? That example > just reserved 4 bytes (sizeof(int)), but you can just as easily use a > struct or probably even an array. > > Here's an example from the LPC17xx.h header from and NXP cortex-M3 > chip. > > typedef struct { volatile uint32_t mask[512]; } > LPC_CANAF_RAM_TypeDef; > > #define LPC_APB0_BASE? ? ? ? (0x40000000UL) #define > LPC_CANAF_RAM_BASE? ? (LPC_APB0_BASE + 0x38000) #define LPC_CANAF_RAM > ((LPC_CANAF_RAM_TypeDef *) LPC_CANAF_RAM_BASE) > > See the core_cm3.h file from CMSIS for more examples. > > If I'm not mistaken when you declare a variable the compiler/linker > always reserves enough memory for that type - even when you specify > the starting address like this. > > > _______________________________________________ arm-gnu mailing list > arm-gnu at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu > _______________________________________________ arm-gnu mailing list arm-gnu at codesourcery.com http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu -------------- next part -------------- An HTML attachment was scrubbed... URL: From moses at texband.net Thu Apr 5 17:41:33 2012 From: moses at texband.net (Moses McKnight) Date: Thu, 05 Apr 2012 12:41:33 -0500 Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <857298249.58142741.1333646555849.JavaMail.root@email> References: <857298249.58142741.1333646555849.JavaMail.root@email> Message-ID: <4F7DD94D.80300@texband.net> I guess you're right, and I think I understand the problem better now! Guess I'll go back to my hole now... :) On 04/05/2012 12:22 PM, Mark Deneen wrote: > Even in this situation, haven't you just allocated space for a pointer to a struct? > > I don't see how GCC is going to do anything special here. > > -M > ----- Original Message ----- > Ok, looks like you're right there - bad example. But I think my basic > idea is correct. Here is yet another link - see the post by Paul Curtis > (he is a compiler writer) near the end. > > > excerpt: > > struct my_placed_vars *my_vars = (void *)0x40003000; // EASY! > > #define MY_VAR_1 (my_vars->var_1) > #define MY_VAR_2 (my_vars->var_2) > > COMPLETELY PORTABLE AMONGST ALL COMPILERS FOR THE GIVEN TARGET! > From tom_usenet at optusnet.com.au Fri Apr 6 01:13:59 2012 From: tom_usenet at optusnet.com.au (Tom Evans) Date: Fri, 06 Apr 2012 11:13:59 +1000 Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <1333634567.11179.YahooMailNeo@web162703.mail.bf1.yahoo.com> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D2C88.6030504@optusnet.com.au> <1333634567.11179.YahooMailNeo@web162703.mail.bf1.yahoo.com> Message-ID: <4F7E4357.9060900@optusnet.com.au> On 6/04/2012 12:02 AM, JM wrote: > *From:* Tom Evans >>If you don't have "malloc" then you should have something similar > managing your heap that could be abused to do this for you. > > Intriguing idea, but I actually do not use malloc, but rather > a replacement I wrote that simply allocates RAM in > consecutive chunks of the requested size. A simple sequential allocator for a system that allocates memory but doesn't free it. That's pretty common. This question has nothing to do with the compiler, and all of your questions on use of the linker should be answered in "The Gnu Linker Manual" which comes with a CodeSourcery distribution. > If I did this in my case, it would leave 400-500 > bytes unused. I can think of at least three ways to solve this (before breakfast :-), but I'll only list two. The unnecessarily complicated sledgehammer-and-peanut way is to use the linker to declare THREE separate named memory regions. The "tiny fixed address region" that you need somewhere in the heap, the chunk before and the chunk after. You then modify your custom allocater to be smart enough to allocate from the TWO regions named in the linker. All it has to do is to try to allocate from the first, and if that fails, to allocate from the second instead. The first one will eventually fill up with small requests so you won't be wasting more than a few bytes. That's so simple it'd only take a few lines of code and two static variables at most. The really simple way is to have the Allocator able to handle two regions, and have it hard-allocate the DMA block during its initialisation and thereafter allocate from the region before and the region after like listed previously. That's what I'd do. Tom From hondgm at yahoo.com Fri Apr 6 10:40:25 2012 From: hondgm at yahoo.com (JM) Date: Fri, 6 Apr 2012 03:40:25 -0700 (PDT) Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <4F7E4357.9060900@optusnet.com.au> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D2C88.6030504@optusnet.com.au> <1333634567.11179.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7E4357.9060900@optusnet.com.au> Message-ID: <1333708825.29239.YahooMailNeo@web162703.mail.bf1.yahoo.com> The custom allocator could work, but I can see some problems with that in my application.? Actually setting up the multiple regions in the linker isn't so bad, but I've run into a problem maybe somebody can shed some light on.? I manually chose several static and global variables to go into SRAM1 using "__attribute__ ((section(".sram1")))", and this works pretty well linker-wise.? The problem is, some of these variables no longer function.? I can't say how exactly because they are from a third party library (lwIP) and I haven't debugged yet, but I know if I let the linker allocate automatically, they're ok.?? All these variables that cause issues are static.? However, being static itself doesn't seem to be problematic, that is, some static variables are happy there.? Is there any problem with putting static variables in to region SRAM1 that anyone can see?? I assume there's a simple answer to this.? New linker below: MEMORY { ??? FLASH (rx) : ORIGIN = 0x00001000, LENGTH = 252K ??? SRAM1 (rwx) : ORIGIN = 0x20000000, LENGTH = 464 ??? DMA (rwx) : ORIGIN = 0x200001D0, LENGTH = 16 ??? SRAM2 (rwx) : ORIGIN = 0x200001E0, LENGTH = 97824 } SECTIONS { ??? .text : ??? { ??????? KEEP(*(.isr_vector)) ??????? *(.text*) ??????? *(.rodata*) ??????? _etext = .; ??? } > FLASH ??? .data : AT (ADDR(.text) + SIZEOF(.text)) ??? { ??????? _data = .; ??????? *(vtable) ??????? *(.data*) ??????? _edata = .; ??? } > SRAM2 ??? .bss(NOLOAD) : ??? { ??????? _bss = .; ??????? *(.bss*) ??????? *(COMMON) ??????? _ebss = .; ??????? . = ALIGN (8); ?????? _end = .; ??? } > SRAM2 ??? ??? .dmaRegisters? 0x200001D0 (NOLOAD) : ??? { ??? ??? *(.dmaRegisters) ??? } > DMA??? ??? ??? .sram1? 0x20000000 (NOLOAD) : ??? { ??? ??? *(.sram1) ??? } > SRAM1??? } /* end of allocated ram _end */ PROVIDE( _HEAP_START = _end ); /* end of the heap -> align 8 byte */ PROVIDE ( _HEAP_END = ALIGN(ORIGIN(SRAM2) + LENGTH(SRAM2),8) ); ________________________________ A simple sequential allocator for a system that allocates memory but doesn't free it. That's pretty common. This question has nothing to do with the compiler, and all of your questions on use of the linker should be answered in "The Gnu Linker Manual" which comes with a CodeSourcery distribution. > If I did this in my case, it would leave 400-500 > bytes unused. I can think of at least three ways to solve this (before breakfast :-), but I'll only list two. The unnecessarily complicated sledgehammer-and-peanut way is to use the linker to declare THREE separate named memory regions. The "tiny fixed address region" that you need somewhere in the heap, the chunk before and the chunk after. You then modify your custom allocater to be smart enough to allocate from the TWO regions named in the linker. All it has to do is to try to allocate from the first, and if that fails, to allocate from the second instead. The first one will eventually fill up with small requests so you won't be wasting more than a few bytes. That's so simple it'd only take a few lines of code and two static variables at most. The really simple way is to have the Allocator able to handle two regions, and have it hard-allocate the DMA block during its initialisation and thereafter allocate from the region before and the region after like listed previously. That's what I'd do. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From list-bastian.schick at sciopta.com Fri Apr 6 10:57:38 2012 From: list-bastian.schick at sciopta.com (42Bastian) Date: Fri, 06 Apr 2012 12:57:38 +0200 Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <1333708825.29239.YahooMailNeo@web162703.mail.bf1.yahoo.com> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D2C88.6030504@optusnet.com.au> <1333634567.11179.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7E4357.9060900@optusnet.com.au> <1333708825.29239.YahooMailNeo@web162703.mail.bf1.yahoo.com> Message-ID: <4F7ECC22.5090009@sciopta.com> Hi > I manually chose several static and global variables to go into SRAM1 > using "__attribute__ ((section(".sram1")))", and this works pretty well > linker-wise. The problem is, some of these variables no longer > function. I can't say how exactly because they are from a third party > library (lwIP) and I haven't debugged yet, but I know if I let the > linker allocate automatically, they're ok. For variables that do not go to the standard places .data and .bss you need to initialize them with your own code. If you are lucky, those variables are initialized to zero, so you can do a memset() of SRAM by hand. If initialized you need to enhance your linker script like this: .sram1 : { *(.sram1_data) sram1_bss = .; *(.sram1_bss) } > SRAM1 AT > FLASH sram1_loadaddr = LOADADDR(.sram1); > .data : AT (ADDR(.text) + SIZEOF(.text)) { _data = .; *(vtable) > *(.data*) _edata = .; } > SRAM2 BTW: Better way is .data : { } > SRAM2 AT > FLASH (Leave it to ld to do the calculation.) -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + From list-bastian.schick at sciopta.com Fri Apr 6 11:14:45 2012 From: list-bastian.schick at sciopta.com (42Bastian) Date: Fri, 06 Apr 2012 13:14:45 +0200 Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D2C88.6030504@optusnet.com.au> <1333634567.11179.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7E4357.9060900@optusnet.com.au> <1333708825.29239.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7ECC22.5090009@sciopta.com> Message-ID: <4F7ED025.6090507@sciopta.com> Hi > Maybe i missed some hardware specific part there, but why do not place Yepp. You did. He wrote, the DMA buffer is a list of 32 16byte large descriptors. The whole stuff (32*16bytes) must be aligned on 1024 bytes address. And he uses only one channel somewhere near the end. -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + From hondgm at yahoo.com Fri Apr 6 12:03:38 2012 From: hondgm at yahoo.com (JM) Date: Fri, 6 Apr 2012 05:03:38 -0700 (PDT) Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <4F7ECC22.5090009@sciopta.com> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D2C88.6030504@optusnet.com.au> <1333634567.11179.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7E4357.9060900@optusnet.com.au> <1333708825.29239.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7ECC22.5090009@sciopta.com> Message-ID: <1333713818.19879.YahooMailNeo@web162703.mail.bf1.yahoo.com> Sorry, I'm a little confused.? I'm getting an error bi/4.5.2/../../../../arm-none-eabi/bin/ld.exe: section .data loaded at [00028bc0,00028bcf] overlaps section .sram1 loaded at [00028bc0,00028c7b] collect2: ld returned 1 exit status cs-make: *** [RTOSDemo.axf] Error 1 so something is wrong.? I'm fairly sure I misinterpreted the change you suggested.? MEMORY { ??? FLASH (rx) : ORIGIN = 0x00001000, LENGTH = 252K ??? SRAM1 (rwx) : ORIGIN = 0x20000000, LENGTH = 464 ??? DMA (rwx) : ORIGIN = 0x200001D0, LENGTH = 16 ??? SRAM2 (rwx) : ORIGIN = 0x200001E0, LENGTH = 97824 } SECTIONS { ??? .text : ??? { ??????? KEEP(*(.isr_vector)) ??????? *(.text*) ??????? *(.rodata*) ??????? _etext = .; ??? } > FLASH ??? .sram1 : ??? { ??? ??? *(.sram1_data) ??? ??? sram1_bss = .; ??? ??? *(.sram1_bss) ??? } > SRAM1 AT > FLASH ??? sram1_loadaddr = LOADADDR(.sram1); ??? .data : AT (ADDR(.text) + SIZEOF(.text)) ??? { ??????? _data = .; ??????? *(vtable) ??????? *(.data*) ??????? _edata = .; ??? } > SRAM2 ??? .bss(NOLOAD) : ??? { ??????? _bss = .; ??????? *(.bss*) ??????? *(COMMON) ??????? _ebss = .; ??????? . = ALIGN (8); ?????? _end = .; ??? } > SRAM2 ??? ??? .dmaRegisters? 0x200001D0 (NOLOAD) : ??? { ??? ??? *(.dmaRegisters) ??? } > DMA??? } /* end of allocated ram _end */ PROVIDE( _HEAP_START = _end ); /* end of the heap -> align 8 byte */ PROVIDE ( _HEAP_END = ALIGN(ORIGIN(SRAM2) + LENGTH(SRAM2),8) ); ________________________________ From: 42Bastian To: arm-gnu at codesourcery.com Sent: Friday, April 6, 2012 6:57 AM Subject: Re: [arm-gnu] Placing variable at absolute address in RAM Hi > I manually chose several static and global variables to go into SRAM1 > using "__attribute__ ((section(".sram1")))", and this works pretty well > linker-wise.? The problem is, some of these variables no longer > function.? I can't say how exactly because they are from a third party > library (lwIP) and I haven't debugged yet, but I know if I let the > linker allocate automatically, they're ok. For variables that do not go to the standard places .data and .bss you need to initialize them with your own code. If you are lucky, those variables are initialized to zero, so you can do a memset() of SRAM by hand. If initialized you need to enhance your linker script like this: .sram1 : { ??? *(.sram1_data) ??? sram1_bss = .; ??? *(.sram1_bss) } > SRAM1 AT > FLASH sram1_loadaddr = LOADADDR(.sram1); > .data : AT (ADDR(.text) + SIZEOF(.text)) { _data = .; *(vtable) > *(.data*) _edata = .; } > SRAM2 BTW: Better way is .data : { } > SRAM2 AT > FLASH (Leave it to ld to do the calculation.) -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + _______________________________________________ arm-gnu mailing list arm-gnu at codesourcery.com http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu -------------- next part -------------- An HTML attachment was scrubbed... URL: From krzysztof.wesolowski at rainlabs.pl Fri Apr 6 11:06:59 2012 From: krzysztof.wesolowski at rainlabs.pl (=?ISO-8859-2?Q?Krzysztof_Weso=B3owski?=) Date: Fri, 6 Apr 2012 13:06:59 +0200 Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <4F7ECC22.5090009@sciopta.com> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D2C88.6030504@optusnet.com.au> <1333634567.11179.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7E4357.9060900@optusnet.com.au> <1333708825.29239.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7ECC22.5090009@sciopta.com> Message-ID: Maybe i missed some hardware specific part there, but why do not place whole standard SRAM first and use last 16bytes for DMA? Any reason to place this DMA specific part in first 512bytes? Regards, Krzysztof Weso?owski, http://www.rainlabs.pl http://en.rainlabs.pl On Fri, Apr 6, 2012 at 12:57 PM, 42Bastian wrote: > Hi > >> I manually chose several static and global variables to go into SRAM1 >> using "__attribute__ ((section(".sram1")))", and this works pretty well >> linker-wise. ?The problem is, some of these variables no longer >> function. ?I can't say how exactly because they are from a third party >> library (lwIP) and I haven't debugged yet, but I know if I let the >> linker allocate automatically, they're ok. > > For variables that do not go to the standard places .data and .bss you > need to initialize them with your own code. > > If you are lucky, those variables are initialized to zero, so you can do > a memset() of SRAM by hand. > > If initialized you need to enhance your linker script like this: > > ?.sram1 : { > ? ? ? ?*(.sram1_data) > ? ? ? ?sram1_bss = .; > ? ? ? ?*(.sram1_bss) > ?} > SRAM1 AT > FLASH > > sram1_loadaddr = LOADADDR(.sram1); > >> .data : AT (ADDR(.text) + SIZEOF(.text)) { _data = .; *(vtable) >> *(.data*) _edata = .; } > SRAM2 > > BTW: Better way is > .data : { > > } > SRAM2 AT > FLASH > (Leave it to ld to do the calculation.) > > > -- > 42Bastian > + > | http://www.sciopta.com > | Fastest direct message passing kernel. > | IEC61508 certified. > + > _______________________________________________ > arm-gnu mailing list > arm-gnu at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu From krzysztof.wesolowski at rainlabs.pl Fri Apr 6 11:33:55 2012 From: krzysztof.wesolowski at rainlabs.pl (=?ISO-8859-2?Q?Krzysztof_Weso=B3owski?=) Date: Fri, 6 Apr 2012 13:33:55 +0200 Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <4F7ED025.6090507@sciopta.com> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D2C88.6030504@optusnet.com.au> <1333634567.11179.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7E4357.9060900@optusnet.com.au> <1333708825.29239.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7ECC22.5090009@sciopta.com> <4F7ED025.6090507@sciopta.com> Message-ID: Yes, i missed alignment requirement (thought it is equal to size of DMA storage). Regards, Krzysztof Weso?owski, http://www.rainlabs.pl http://en.rainlabs.pl 2012/4/6 42Bastian : > Hi > >> Maybe i missed some hardware specific part there, but why do not place > > Yepp. You did. He wrote, the DMA buffer is a list of 32 16byte large > descriptors. The whole stuff (32*16bytes) must be aligned on 1024 bytes > address. And he uses only one channel somewhere near the end. > > -- > 42Bastian > + > | http://www.sciopta.com > | Fastest direct message passing kernel. > | IEC61508 certified. > + From list-bastian.schick at sciopta.com Fri Apr 6 15:26:47 2012 From: list-bastian.schick at sciopta.com (42Bastian) Date: Fri, 06 Apr 2012 17:26:47 +0200 Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <1333713818.19879.YahooMailNeo@web162703.mail.bf1.yahoo.com> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D2C88.6030504@optusnet.com.au> <1333634567.11179.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7E4357.9060900@optusnet.com.au> <1333708825.29239.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7ECC22.5090009@sciopta.com> <1333713818.19879.YahooMailNeo@web162703.mail.bf1.yahoo.com> Message-ID: <4F7F0B37.6070201@sciopta.com> Hi > bi/4.5.2/../../../../arm-none-eabi/bin/ld.exe: section .data loaded at [00028bc0,00028bcf] overlaps section .sram1 loaded at [00028bc0,00028c7b] > collect2: ld returned 1 exit status > cs-make: *** [RTOSDemo.axf] Error 1 You should not mix AT > with AT(...). > MEMORY > { > FLASH (rx) : ORIGIN = 0x00001000, LENGTH = 252K > SRAM1 (rwx) : ORIGIN = 0x20000000, LENGTH = 464 > DMA (rwx) : ORIGIN = 0x200001D0, LENGTH = 16 > SRAM2 (rwx) : ORIGIN = 0x200001E0, LENGTH = 97824 > } > > SECTIONS > { > .text : > { > KEEP(*(.isr_vector)) > *(.text*) > *(.rodata*) > _etext = .; > } > FLASH > > .sram1 : > { > *(.sram1_data) > sram1_bss = .; > *(.sram1_bss) > } > SRAM1 AT > FLASH > > sram1_loadaddr = LOADADDR(.sram1); > > .data : AT (ADDR(.text) + SIZEOF(.text)) > { > _data = .; > *(vtable) > *(.data*) > _edata = .; > } > SRAM2 .data : { _data = .; *(vtable) *(.data*) _edata = .; } > SRAM2 AT > FLASH > > .bss(NOLOAD) : > { > _bss = .; > *(.bss*) > *(COMMON) > _ebss = .; > . = ALIGN (8); I suggest to move _ebss after the alignment. > _end = .; > } > SRAM2 > > .dmaRegisters 0x200001D0 (NOLOAD) : > { > *(.dmaRegisters) > } > DMA > > } > > /* end of allocated ram _end */ > PROVIDE( _HEAP_START = _end ); > > /* end of the heap -> align 8 byte */ > PROVIDE ( _HEAP_END = ALIGN(ORIGIN(SRAM2) + LENGTH(SRAM2),8) ); -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + From hondgm at yahoo.com Fri Apr 6 15:56:34 2012 From: hondgm at yahoo.com (JM) Date: Fri, 6 Apr 2012 08:56:34 -0700 (PDT) Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <4F7F0B37.6070201@sciopta.com> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D2C88.6030504@optusnet.com.au> <1333634567.11179.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7E4357.9060900@optusnet.com.au> <1333708825.29239.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7ECC22.5090009@sciopta.com> <1333713818.19879.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7F0B37.6070201@sciopta.com> Message-ID: <1333727794.58050.YahooMailNeo@web162702.mail.bf1.yahoo.com> Thank you, I'm a little closer.? It compiles now.? But I think there could be another problem that was occurring from the start.? I checked the map file for all these variables (structs mostly) that didn't seem to function when in .sram1.? I compiled it without specifying a section, then they appear in the mapfile.? Also, they are all indicated as being .bss, so I suppose they are uninitialized.? But when I use __attribute__ to force it into .sram1, some variables no longer appear in the map file, BUT, the space being used is shown.? Below is an excerpt.? See how in main.o all the variables are listed, but in lwiplib.o, only the variable "hello" is displayed?? "hello" is a variable I declared to see if it appears in the map file. /***two declarations that should be appearing in lwiplib.o, but aren't ***/ static struct etharp_entry arp_table[ARP_TABLE_SIZE] __attribute__ ((section(".sram1")));? /*this variable's name not appearing in mapfile*/ unsigned char *hello? __attribute__ ((section(".sram1")));??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? /*this variable's name appears in mapfile*/ /*******************************************************/ .sram1????????? 0x20000000????? 0x16c load address 0x00028c70 ?*(.sram1_data) ??????????????? 0x20000000??????????????? sram1_bss = . ?*(.sram1_bss) ?.sram1???????? 0x20000000?????? 0x64 main.o ??????????????? 0x20000000??????????????? netbuf_start ??????????????? 0x20000004??????????????? netbuf_wr ??????????????? 0x20000008??????????????? netbuf_rd ??????????????? 0x2000000c??????????????? netbuf_end ??????????????? 0x20000010??????????????? outbuf1 ??????????????? 0x20000014??????????????? outbuf2 ??????????????? 0x20000018??????????????? netbuf ??????????????? 0x2000001c??????????????? aacFrameInfo ??????????????? 0x2000002c??????????????? mp3FrameInfo ??????????????? 0x2000003c??????????????? packetq ?.sram1???????? 0x20000064?????? 0x10 ./stream-core/dac.o ??????????????? 0x20000064??????????????? dac_fill ?.sram1???????? 0x20000074?????? 0xf8 ./general-core/lwiplib.o ??????????????? 0x20000168??????????????? hello ??????????????? 0x00028c70??????????????? sram1_loadaddr = LOADADDR (.sram1) ________________________________ From: 42Bastian To: arm-gnu at codesourcery.com Sent: Friday, April 6, 2012 11:26 AM Subject: Re: [arm-gnu] Placing variable at absolute address in RAM Hi > bi/4.5.2/../../../../arm-none-eabi/bin/ld.exe: section .data loaded at [00028bc0,00028bcf] overlaps section .sram1 loaded at [00028bc0,00028c7b] > collect2: ld returned 1 exit status > cs-make: *** [RTOSDemo.axf] Error 1 You should not mix? AT > with AT(...). -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + _______________________________________________ arm-gnu mailing list arm-gnu at codesourcery.com http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu -------------- next part -------------- An HTML attachment was scrubbed... URL: From list-bastian.schick at sciopta.com Sat Apr 7 07:59:01 2012 From: list-bastian.schick at sciopta.com (42Bastian) Date: Sat, 07 Apr 2012 09:59:01 +0200 Subject: [arm-gnu] Placing variable at absolute address in RAM In-Reply-To: <1333727794.58050.YahooMailNeo@web162702.mail.bf1.yahoo.com> References: <1333557236.8618.YahooMailNeo@web162701.mail.bf1.yahoo.com> <4F7D2C88.6030504@optusnet.com.au> <1333634567.11179.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7E4357.9060900@optusnet.com.au> <1333708825.29239.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7ECC22.5090009@sciopta.com> <1333713818.19879.YahooMailNeo@web162703.mail.bf1.yahoo.com> <4F7F0B37.6070201@sciopta.com> <1333727794.58050.YahooMailNeo@web162702.mail.bf1.yahoo.com> Message-ID: <4F7FF3C5.9030708@sciopta.com> Hi > static struct etharp_entry arp_table[ARP_TABLE_SIZE] __attribute__ ((section(".sram1"))); /*this variable's name not appearing in mapfile*/ This one is locally used. > unsigned char *hello __attribute__ ((section(".sram1"))); /*this variable's name appears in mapfile*/ This one is global. Try removing the "static". BTW: Instead of adding "__attribute__" to every static, you might do .sram1 : { *lwIP.o(.data) } > SRAM1 AT > FLASH But you must place this before the common *.o(.data) -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + From B17777 at freescale.com Sun Apr 8 08:09:16 2012 From: B17777 at freescale.com (Sun Ray-B17777) Date: Sun, 8 Apr 2012 08:09:16 +0000 Subject: [arm-gnu] Unknown mandatory EABI object attribute 44/42 Message-ID: <6E09A5400007744A84625160124FCDB50DDDDB@039-SN2MPN1-021.039d.mgd.msft.net> Hi, When I use the arm-none-linux-gnueabi(v4.4.4) to link some library generated by arm-none-eabi(v4.6.1) toolchain, I always met the error such as "Unknown mandatory EABI object attribute 44/42", I checked the EABI spec that the error indicates Tag_DIV_use and Tag_MPextension_use is not supported. Is this a bug for the toolchain? Can I disable the feature in library generating with compiling flags? Or I have to use the arm-none-linux-gnueabi to generate the lib? Thanks, Yanfei -------------- next part -------------- An HTML attachment was scrubbed... URL: From B17777 at freescale.com Sun Apr 8 09:33:33 2012 From: B17777 at freescale.com (Sun Ray-B17777) Date: Sun, 8 Apr 2012 09:33:33 +0000 Subject: [arm-gnu] Unknown mandatory EABI object attribute 44/42 Message-ID: <6E09A5400007744A84625160124FCDB50DDE06@039-SN2MPN1-021.039d.mgd.msft.net> By the way, I tried to set the eabi_attribute in source file, like ?.eabi_attribute 42,0? to disable Tag_MPextension_use, seems the link works. But the eabi_attribute change only be effective in the single file, I have to add the attribute setting to each file archived in the library. So I wonder if there is a method to set the eabi_attribute globally to the whole project, such as in command line or in link script. From: Sun Ray-B17777 Sent: 2012?4?8? 16:09 To: arm-gnu at codesourcery.com Subject: Unknown mandatory EABI object attribute 44/42 Hi, When I use the arm-none-linux-gnueabi(v4.4.4) to link some library generated by arm-none-eabi(v4.6.1) toolchain, I always met the error such as ?Unknown mandatory EABI object attribute 44/42?, I checked the EABI spec that the error indicates Tag_DIV_use and Tag_MPextension_use is not supported. Is this a bug for the toolchain? Can I disable the feature in library generating with compiling flags? Or I have to use the arm-none-linux-gnueabi to generate the lib? Thanks, Yanfei -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlos_odonell at mentor.com Sun Apr 8 19:03:18 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Sun, 8 Apr 2012 15:03:18 -0400 Subject: [arm-gnu] Unknown mandatory EABI object attribute 44/42 In-Reply-To: <6E09A5400007744A84625160124FCDB50DDE06@039-SN2MPN1-021.039d.mgd.msft.net> References: <6E09A5400007744A84625160124FCDB50DDE06@039-SN2MPN1-021.039d.mgd.msft.net> Message-ID: <4F81E0F6.7060405@mentor.com> On 4/8/2012 5:33 AM, Sun Ray-B17777 wrote: > By the way, I tried to set the eabi_attribute in source file, like > ?.eabi_attribute 42,0? to disable Tag_MPextension_use, seems the link > works. But the eabi_attribute change only be effective in the single > file, I have to add the attribute setting to each file archived in > the library. So I wonder if there is a method to set the > eabi_attribute globally to the whole project, such as in command line > or in link script. The tools are not "forward compatible", you can't use a newer compiler to compile object files and link with an older compiler. It is never guaranteed to work. You must link with the newer compiler. Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From biglizheng at gmail.com Mon Apr 9 17:24:41 2012 From: biglizheng at gmail.com (Li, Zheng) Date: Mon, 9 Apr 2012 10:24:41 -0700 Subject: [arm-gnu] elf2flt for the Code Sourcery Lite Message-ID: Hello everyone, I'm using the latest Sourcery CodeBench Lite for ARM_GNU_Linux. However, I cannot generate FLT binary for mmu-less arm as the linker does not have any elf2flt option. I was trying to compile elf2flt myself, but elf2flt requires libbfd.a and libiberty.a from the tool-chain which I cannot locate in my Code Sourcery installation. Can anyone point to me how to deal with this elf2flt problem? Thanks a million. Cheers, Zheng From carlos_odonell at mentor.com Mon Apr 9 18:15:15 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Mon, 9 Apr 2012 14:15:15 -0400 Subject: [arm-gnu] elf2flt for the Code Sourcery Lite In-Reply-To: References: Message-ID: <4F832733.8050707@mentor.com> On 4/9/2012 1:24 PM, Li, Zheng wrote: > Hello everyone, > > I'm using the latest Sourcery CodeBench Lite for ARM_GNU_Linux. > However, I cannot generate FLT binary for mmu-less arm as the linker > does not have any elf2flt option. I was trying to compile elf2flt > myself, but elf2flt requires libbfd.a and libiberty.a from the > tool-chain which I cannot locate in my Code Sourcery installation. > > Can anyone point to me how to deal with this elf2flt problem? Thanks a million. Sourcery CodeBench Lite for ARM GNU/Linux can't be used with an mmu-less device. You must use Sourcery CodeBench Lite for ARM uCLinux to create applications for an mmu-less device. http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/ * Under ARM Processors click "Download the uClinux release." Good luck with your project! Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From biglizheng at gmail.com Mon Apr 9 20:37:08 2012 From: biglizheng at gmail.com (Li, Zheng) Date: Mon, 9 Apr 2012 13:37:08 -0700 Subject: [arm-gnu] elf2flt for the Code Sourcery Lite In-Reply-To: <4F832733.8050707@mentor.com> References: <4F832733.8050707@mentor.com> Message-ID: Thanks a lot. I got it working. Cheers, Zheng On Mon, Apr 9, 2012 at 11:15 AM, Carlos O'Donell wrote: > On 4/9/2012 1:24 PM, Li, Zheng wrote: >> Hello everyone, >> >> I'm using the latest Sourcery CodeBench Lite for ARM_GNU_Linux. >> However, I cannot generate FLT binary for mmu-less arm as the linker >> does not have any elf2flt option. I was trying to compile elf2flt >> myself, but elf2flt requires libbfd.a and libiberty.a from the >> tool-chain which I cannot locate in my Code Sourcery installation. >> >> Can anyone point to me how to deal with this elf2flt problem? Thanks a million. > > Sourcery CodeBench Lite for ARM GNU/Linux can't be used with an mmu-less device. > > You must use Sourcery CodeBench Lite for ARM uCLinux to create applications for an mmu-less device. > > http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/ > * Under ARM Processors click "Download the uClinux release." > > Good luck with your project! > > Cheers, > Carlos. > -- > Carlos O'Donell > Mentor Graphics / CodeSourcery > carlos_odonell at mentor.com > carlos at codesourcery.com > +1 (613) 963 1026 -- Li, Zheng? ?? From carlos_odonell at mentor.com Wed Apr 11 16:50:21 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Wed, 11 Apr 2012 12:50:21 -0400 Subject: [arm-gnu] Some symbols computation does not work right in LD In-Reply-To: References: Message-ID: <4F85B64D.4070909@mentor.com> On 3/23/2012 5:21 AM, Bruno Richard wrote: > I found a problem in the ARM-EABI linker: > In .ld files, when some symbols are computed, their results when computed by LD look invalid. > > This problem was not showing on GCC versions up to 4.5.2, and is present with 4.6.1. > > To show the problem, use the following command line: > arm-none-eabi-ld.exe" -T test.ld main.o -o main.elf -Map main.map > > Here is an excerpt of the linker file that shows the problem: > _eidata1 = (_sidata + _edata) - _sdata ; /* 0x08000004 in map file */ > _eidata2 = _sidata + (_edata - _sdata); /* 0x08000004 in map file */ > same = (_eidata1 == _eidata2) ? 0x1 : 0x0; /* 0x00000000 in map file !!!*/ > > The "same" Symbol should be 1, not 0. > > I attach a zip file containing the files necessary to reproduce the problem. I believe your linker script is wrong. Please read: http://sourceware.org/binutils/docs/ld/Expression-Section.html#Expression-Section Symbols in a section are section relative by default. Use ABSOLUTE() when assigning to symbols that should have absolute VMA values, or use ABSOLUTE() when doing the computation to avoid the normal rules LD applies when mixing relative and non-relative addressing. For example: _sidata = 0xd4 (relative to .text 0x08000000 VMA FLASH) _edata = 0xc (relative to .data 0x20000000 VMA RAM) _sdata = 0x0 (relative to .data 0x20000000 VMA RAM) _eidata1 = (_sidata + _edata) - _sdata; Linker converts _sidata and _edata to absolute via rule: binary operator on two relative operands in different sections implicitly converts to absolute addressing. _edata1 = (0x080000d4 + 0x2000000c) - _sdata; = (0x280000e0) - _sdata Linker converts _sdata to absolute via previously stated rule. = 0x280000e0 - 0x20000000; = 0x080000e0; _eidata2 = _sidata + (_edata - _sdata); Linker doesn't convert _edata and _sdata because they are in the same section. = _sidata + (0xc - 0x0); Linker converts result of .data section relative 0xc to absolute. = _sidata + (0xc); = 0x080000d4 + 0x2000000c; = 0x280000e0; Therefore _eidata1 != _eidata2. In the past you might have gotten lucky with the numbers working out. With ABSOLUTE() I get: 0x080000e0 _eidata1 = ((_sidata + _edata) - _sdata) 0x080000e0 _eidata2 = (_sidata + (_edata - _sdata)) 0x00000001 same = (_eidata1 == _eidata2)?0x1:0x0 Note: - I have seen LD *print* the wrong VMA in the address column, but I haven't investigated this bug. Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From carlos_odonell at mentor.com Wed Apr 11 17:41:36 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Wed, 11 Apr 2012 13:41:36 -0400 Subject: [arm-gnu] .debug_type missing from elf output In-Reply-To: <3625CB86347ED04988A349ED2BF75B8901CDC9BD42@IE2RD2XVS871.red002.local> References: <3625CB86347ED04988A349ED2BF75B8901CDC9BD42@IE2RD2XVS871.red002.local> Message-ID: <4F85C250.4010404@mentor.com> On 3/23/2012 9:35 AM, Leo Havm?ller wrote: > With arm-2011.09-69-arm-none-eabi, the entire .debug_types section is missing from the elf output (compiling with ?gdwarf-4). > > OK with arm-2011.03-42-arm-none-eabi. I can't reproduce that with a simple application, and you haven't provided enough information for anyone else to verify. With 2011.09-69: struct s { int x; int y : 5; int z; }; struct s i; int main (void) { } arm-none-eabi-gcc -gdwarf-4 -T generic-hosted.ld -o test test.c arm-none-eabi-readelf -a test | grep types [13] .debug_types PROGBITS 00000000 008e8e 000051 00 0 0 1 arm-none-eabi-objdump --dwarf test ... Contents of the .debug_types section: Compilation Unit @ offset 0x0: Length: 0x4d (32-bit) Version: 4 Abbrev Offset: 0 Pointer Size: 4 Signature: a5e49293c4185192 Type Offset: 0x1d <0><17>: Abbrev Number: 1 (DW_TAG_type_unit) <18> DW_AT_language : 1 (ANSI C) <19> DW_AT_stmt_list : 0x0 <1><1d>: Abbrev Number: 2 (DW_TAG_structure_type) <1e> DW_AT_name : s <20> DW_AT_byte_size : 12 <21> DW_AT_decl_file : 1 <22> DW_AT_decl_line : 1 <23> DW_AT_sibling : <0x49> <2><27>: Abbrev Number: 3 (DW_TAG_member) <28> DW_AT_name : x <2a> DW_AT_decl_file : 1 <2b> DW_AT_decl_line : 3 <2c> DW_AT_type : <0x49> <30> DW_AT_data_member_location: 0 <2><31>: Abbrev Number: 4 (DW_TAG_member) <32> DW_AT_name : y <34> DW_AT_decl_file : 1 <35> DW_AT_decl_line : 4 <36> DW_AT_type : <0x49> <3a> DW_AT_byte_size : 4 <3b> DW_AT_bit_size : 5 <3c> DW_AT_bit_offset : 27 <3d> DW_AT_data_member_location: 4 <2><3e>: Abbrev Number: 3 (DW_TAG_member) <3f> DW_AT_name : z <41> DW_AT_decl_file : 1 <42> DW_AT_decl_line : 5 <43> DW_AT_type : <0x49> <47> DW_AT_data_member_location: 8 <1><49>: Abbrev Number: 5 (DW_TAG_base_type) <4a> DW_AT_byte_size : 4 <4b> DW_AT_encoding : 5 (signed) <4c> DW_AT_name : int ... Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From carlos_odonell at mentor.com Wed Apr 11 17:58:36 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Wed, 11 Apr 2012 13:58:36 -0400 Subject: [arm-gnu] OSBDM support In-Reply-To: <4F7DA11D.17701.18D4744@g.modugno.elettronika.it> References: <4F7DA11D.17701.18D4744@g.modugno.elettronika.it> Message-ID: <4F85C64C.8050507@mentor.com> On 4/5/2012 9:41 AM, Giuseppe Modugno wrote: > I'm new to ARM processors and Freescale Kinetis... I'm sorry for the dumb questions below. > > I'm using a Freescale Kinetis (ARM Cortex-M4) demo board with OSBDM interface > integrated. I already installed OSDBM driver (downloader from www.pemicro.com website) > so I can see correctly two peripherals (OSBDM Debug port and Virtual USB Serial Port). > > Now I'd like to use CodeSourcery suite for ARM to program (just now I want only program) > the internal flash memory of the microcontroller, starting from a SREC file. > > I know I can use Debug Sprite tool to do that, but I couldn't find the definitive way. I already > copied the two driver DLLs (libusb0.dll and osbdm-jm60.dll) in bin subdirectory where > arm-none-eabi-sprite.exe and arm-none-eabi-gdb.exe are present. > > And now? How can I run -sprite and -gdb tools to program the flash? Sourcery CodeBench Lite for ARM EABI does not have support for the OSBDM debug interface. Sourcery CodeBench for ARM EABI (commercial version) has OSBDM support: http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/platforms/arm-eabi Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From carlos_odonell at mentor.com Thu Apr 12 05:31:34 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Thu, 12 Apr 2012 01:31:34 -0400 Subject: [arm-gnu] .debug_type missing from elf output In-Reply-To: References: <3625CB86347ED04988A349ED2BF75B8901CDC9BD42@IE2RD2XVS871.red002.local> <4F85C250.4010404@mentor.com> Message-ID: <4F8668B6.3040304@mentor.com> On 4/12/2012 12:29 AM, Leo Havm?ller wrote: > Thank you for your response. > > I have tested with the compiler/linker options used in the real project, and found that --gc-sections is the curprit. > > If you use: > arm-none-eabi-gcc -gdwarf-4 -Wl,--gc-sections -T generic-hosted.ld -o test test.c arm-none-eabi-readelf -a test | grep types > Then the .debug_types section is missing from the elf output. Add this to keep it from being discarded. /* DWARF 4 */ .debug_types 0 : { KEEP (*(.debug_types)) } I don't know why the linker would cull this. I've filed an internal issue for this. Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos_odonell at mentor.com carlos at codesourcery.com +1 (613) 963 1026 From fatih.okutan at svstelekom.com.tr Thu Apr 12 05:31:52 2012 From: fatih.okutan at svstelekom.com.tr (Fatih Okutan) Date: Thu, 12 Apr 2012 05:31:52 +0000 Subject: [arm-gnu] unsubscribe Message-ID: <85BB6F51899A3F41B9653242FF969DCC0671BF7E@SVSEXC.center.svstelekom.com.tr> Could you please remove my e-mail from mailing list ? Best Regards. M.Fatih OKUTAN SVS TELEKOM -------------- next part -------------- An HTML attachment was scrubbed... URL: From vaclavpe at seznam.cz Thu Apr 12 11:55:02 2012 From: vaclavpe at seznam.cz (=?us-ascii?Q?Vaclav=20Peroutka?=) Date: Thu, 12 Apr 2012 13:55:02 +0200 (CEST) Subject: [arm-gnu] LD - how to check memory size Message-ID: <308458.9209.16473-4989-842457843-1334231702@seznam.cz> Hello, I have simple linker script like below. If I have two sections, they are collected correctly but size is not counted? Does anybody know, why ? It was disappointing when we found this feature. BTW. Is it feature, or bug in the script or in the linker ? How to correctly rewrite the script to have more sections and size checking ? If I have everything in one section, checking of course works. Thank you for answer MEMORY { MEM1 : ORIGIN = 0, LENGTH = 2K } SECTIONS { .sec1 : { . = ALIGN(Align_Length); __sec1_stack__ = . ; *(.sec1) __end_sec1__ = . ; . = ALIGN(Align_Length); } >MEM1 .sec2 : { . = ALIGN(Align_Length); __sec2_stack__ = . ; *(.sec2) __end_sec2__ = . ; . = ALIGN(Align_Length); } >MEM1 } From list-bastian.schick at sciopta.com Thu Apr 12 12:14:57 2012 From: list-bastian.schick at sciopta.com (42Bastian) Date: Thu, 12 Apr 2012 14:14:57 +0200 Subject: [arm-gnu] LD - how to check memory size In-Reply-To: <308458.9209.16473-4989-842457843-1334231702@seznam.cz> References: <308458.9209.16473-4989-842457843-1334231702@seznam.cz> Message-ID: <4F86C741.7080504@sciopta.com> Am 12.04.2012 13:55, schrieb Vaclav Peroutka: > Hello, > > I have simple linker script like below. If I have two sections, they > are > collected correctly but size is not counted? Does anybody know, why ? It > was disappointing when we found this feature. BTW. Is it feature, or bug > in the script or in the linker ? How to correctly rewrite the script to > have more sections and size checking ? If I have everything in one > section, checking of course works. Your question is a bit confusing. Which size is not counted? Maybe you stripped to much from the script? Did you try ASSERT() and SIZEOF() ? -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + From LEH at rtx.dk Thu Apr 12 04:29:53 2012 From: LEH at rtx.dk (=?iso-8859-1?Q?Leo_Havm=F8ller?=) Date: Thu, 12 Apr 2012 04:29:53 +0000 Subject: [arm-gnu] .debug_type missing from elf output In-Reply-To: <4F85C250.4010404@mentor.com> References: <3625CB86347ED04988A349ED2BF75B8901CDC9BD42@IE2RD2XVS871.red002.local> <4F85C250.4010404@mentor.com> Message-ID: Hello Mr. O'Donell, Thank you for your response. I have tested with the compiler/linker options used in the real project, and found that --gc-sections is the curprit. If you use: arm-none-eabi-gcc -gdwarf-4 -Wl,--gc-sections -T generic-hosted.ld -o test test.c arm-none-eabi-readelf -a test | grep types Then the .debug_types section is missing from the elf output. Section headers without --gc-sections (OK): [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 00000000 008000 000698 00 AX 0 0 4 [ 2] .eh_frame PROGBITS 00000698 008698 000004 00 A 0 0 4 [ 3] .rodata PROGBITS 0000069c 00869c 00005c 00 WAX 0 0 4 [ 4] .data PROGBITS 000006f8 0086f8 000440 00 WA 0 0 8 [ 5] .bss NOBITS 00000b38 008b38 000028 00 WA 0 0 8 [ 6] .debug_aranges PROGBITS 00000000 008b38 000020 00 0 0 1 [ 7] .debug_info PROGBITS 00000000 008b58 000055 00 0 0 1 [ 8] .debug_abbrev PROGBITS 00000000 008bad 000083 00 0 0 1 [ 9] .debug_line PROGBITS 00000000 008c30 000037 00 0 0 1 [10] .debug_frame PROGBITS 00000000 008c68 0001bc 00 0 0 4 [11] .debug_str PROGBITS 00000000 008e24 000022 01 MS 0 0 1 [12] .ARM.attributes ARM_ATTRIBUTES 00000000 008e46 00002e 00 0 0 1 [13] .debug_types PROGBITS 00000000 008e74 000051 00 0 0 1 [14] .comment PROGBITS 00000000 008ec5 000030 01 MS 0 0 1 [15] .shstrtab STRTAB 00000000 008ef5 0000b1 00 0 0 1 [16] .symtab SYMTAB 00000000 009278 000a30 10 17 102 4 [17] .strtab STRTAB 00000000 009ca8 0004f8 00 0 0 1 Section headers with --gc-sections (.debug_types removed): [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 00000000 008000 000698 00 AX 0 0 4 [ 2] .eh_frame PROGBITS 00000698 008698 000004 00 A 0 0 4 [ 3] .rodata PROGBITS 0000069c 00869c 00005c 00 WAX 0 0 4 [ 4] .data PROGBITS 000006f8 0086f8 000440 00 WA 0 0 8 [ 5] .bss NOBITS 00000b38 008b38 000020 00 WA 0 0 8 [ 6] .debug_aranges PROGBITS 00000000 008b38 000020 00 0 0 1 [ 7] .debug_info PROGBITS 00000000 008b58 000055 00 0 0 1 [ 8] .debug_abbrev PROGBITS 00000000 008bad 000083 00 0 0 1 [ 9] .debug_line PROGBITS 00000000 008c30 000037 00 0 0 1 [10] .debug_frame PROGBITS 00000000 008c68 0001bc 00 0 0 4 [11] .debug_str PROGBITS 00000000 008e24 000022 01 MS 0 0 1 [12] .comment PROGBITS 00000000 008e46 000030 01 MS 0 0 1 [13] .ARM.attributes ARM_ATTRIBUTES 00000000 008e76 00002e 00 0 0 1 [14] .shstrtab STRTAB 00000000 008ea4 0000a4 00 0 0 1 [15] .symtab SYMTAB 00000000 0091f0 0009f0 10 16 100 4 [16] .strtab STRTAB 00000000 009be0 0004e9 00 0 0 1 This problem is seen with arm-2011.09-69-arm-none-eabi. Was OK with arm-2011.03-42-arm-none-eabi. Best regards RTX Telecom A/S Leo Havm?ller. > -----Original Message----- > From: Carlos O'Donell [mailto:carlos_odonell at mentor.com] > Sent: 11. april 2012 19:42 > To: Leo Havm?ller > Cc: arm-gnu at codesourcery.com > Subject: Re: [arm-gnu] .debug_type missing from elf output > > On 3/23/2012 9:35 AM, Leo Havm?ller wrote: > > With arm-2011.09-69-arm-none-eabi, the entire .debug_types section is > missing from the elf output (compiling with -gdwarf-4). > > > > OK with arm-2011.03-42-arm-none-eabi. > > I can't reproduce that with a simple application, and you haven't > provided enough information for anyone else to verify. > > With 2011.09-69: > > struct s > { > int x; > int y : 5; > int z; > }; > struct s i; > > int main (void) > { > } > > arm-none-eabi-gcc -gdwarf-4 -T generic-hosted.ld -o test test.c arm- > none-eabi-readelf -a test | grep types > [13] .debug_types PROGBITS 00000000 008e8e 000051 00 > 0 0 1 > > arm-none-eabi-objdump --dwarf test > ... > Contents of the .debug_types section: > > Compilation Unit @ offset 0x0: > Length: 0x4d (32-bit) > Version: 4 > Abbrev Offset: 0 > Pointer Size: 4 > Signature: a5e49293c4185192 > Type Offset: 0x1d > <0><17>: Abbrev Number: 1 (DW_TAG_type_unit) > <18> DW_AT_language : 1 (ANSI C) > <19> DW_AT_stmt_list : 0x0 > <1><1d>: Abbrev Number: 2 (DW_TAG_structure_type) > <1e> DW_AT_name : s > <20> DW_AT_byte_size : 12 > <21> DW_AT_decl_file : 1 > <22> DW_AT_decl_line : 1 > <23> DW_AT_sibling : <0x49> > <2><27>: Abbrev Number: 3 (DW_TAG_member) > <28> DW_AT_name : x > <2a> DW_AT_decl_file : 1 > <2b> DW_AT_decl_line : 3 > <2c> DW_AT_type : <0x49> > <30> DW_AT_data_member_location: 0 > <2><31>: Abbrev Number: 4 (DW_TAG_member) > <32> DW_AT_name : y > <34> DW_AT_decl_file : 1 > <35> DW_AT_decl_line : 4 > <36> DW_AT_type : <0x49> > <3a> DW_AT_byte_size : 4 > <3b> DW_AT_bit_size : 5 > <3c> DW_AT_bit_offset : 27 > <3d> DW_AT_data_member_location: 4 > <2><3e>: Abbrev Number: 3 (DW_TAG_member) > <3f> DW_AT_name : z > <41> DW_AT_decl_file : 1 > <42> DW_AT_decl_line : 5 > <43> DW_AT_type : <0x49> > <47> DW_AT_data_member_location: 8 > <1><49>: Abbrev Number: 5 (DW_TAG_base_type) > <4a> DW_AT_byte_size : 4 > <4b> DW_AT_encoding : 5 (signed) > <4c> DW_AT_name : int > ... > > Cheers, > Carlos. > -- > Carlos O'Donell > Mentor Graphics / CodeSourcery > carlos_odonell at mentor.com > carlos at codesourcery.com > +1 (613) 963 1026 From list-bastian.schick at sciopta.com Thu Apr 12 16:44:09 2012 From: list-bastian.schick at sciopta.com (42Bastian) Date: Thu, 12 Apr 2012 18:44:09 +0200 Subject: [arm-gnu] LD - how to check memory size In-Reply-To: <308464.9193.16465-8980-1350268598-1334235880@seznam.cz> References: <308464.9193.16465-8980-1350268598-1334235880@seznam.cz> Message-ID: <4F870659.6060200@sciopta.com> Hi Vaclav >> Am 12.04.2012 13:55, schrieb Vaclav Peroutka: >>> Hello, >>> >>> I have simple linker script like below. If I have two sections, they >>> are >>> collected correctly but size is not counted? Does anybody know, why ? It >>> was disappointing when we found this feature. BTW. Is it feature, or bug >>> in the script or in the linker ? How to correctly rewrite the script to >>> have more sections and size checking ? If I have everything in one >>> section, checking of course works. >> >> Your question is a bit confusing. Which size is not counted? Maybe you >> stripped to much from the script? >> >> Did you try ASSERT() and SIZEOF() ? >> > > If sec1 and sec2 sizes are bigger than MEM1 size, I got no warning, no error. If I put everything into one sections, I get linker error, which is correct. Hopefully now it is cleaner. Now this sounds weired. (Esp. as I rely on this feature in my scripts) > I did not try neither ASSERT nor SIZEOF. Can you give me some example ? Well, this should work: ASSERT(SIZEOF(.sec1)+SIZEOF(.sec2)<= LENGTH(MEM1)) (I am always unsure how the test in assert should look like.) -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + From shawn.nguyen at alicosystems.com Thu Apr 12 17:49:49 2012 From: shawn.nguyen at alicosystems.com (Shawn Nguyen) Date: Thu, 12 Apr 2012 10:49:49 -0700 Subject: [arm-gnu] LD - how to check memory size In-Reply-To: <4F870659.6060200@sciopta.com> References: <308464.9193.16465-8980-1350268598-1334235880@seznam.cz> <4F870659.6060200@sciopta.com> Message-ID: <009f01cd18d4$a944bc80$fbce3580$@nguyen@alicosystems.com> Admin, Please remove me from this distribution. Thanks in advance. Shawn -----Original Message----- From: arm-gnu-bounces at codesourcery.com [mailto:arm-gnu-bounces at codesourcery.com] On Behalf Of 42Bastian Sent: Thursday, April 12, 2012 9:44 AM To: Vaclav Peroutka Cc: arm-gnu at codesourcery.com Subject: Re: [arm-gnu] LD - how to check memory size Hi Vaclav >> Am 12.04.2012 13:55, schrieb Vaclav Peroutka: >>> Hello, >>> >>> I have simple linker script like below. If I have two sections, they >>> are collected correctly but size is not counted? Does anybody know, >>> why ? It was disappointing when we found this feature. BTW. Is it >>> feature, or bug in the script or in the linker ? How to correctly >>> rewrite the script to have more sections and size checking ? If I >>> have everything in one section, checking of course works. >> >> Your question is a bit confusing. Which size is not counted? Maybe >> you stripped to much from the script? >> >> Did you try ASSERT() and SIZEOF() ? >> > > If sec1 and sec2 sizes are bigger than MEM1 size, I got no warning, no error. If I put everything into one sections, I get linker error, which is correct. Hopefully now it is cleaner. Now this sounds weired. (Esp. as I rely on this feature in my scripts) > I did not try neither ASSERT nor SIZEOF. Can you give me some example ? Well, this should work: ASSERT(SIZEOF(.sec1)+SIZEOF(.sec2)<= LENGTH(MEM1)) (I am always unsure how the test in assert should look like.) -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + _______________________________________________ arm-gnu mailing list arm-gnu at codesourcery.com http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu From ricardo_anguiano at mentor.com Thu Apr 12 18:14:29 2012 From: ricardo_anguiano at mentor.com (Ricardo Anguiano) Date: Thu, 12 Apr 2012 11:14:29 -0700 Subject: [arm-gnu] unsubscribing (was Re: LD - how to check memory size) In-Reply-To: <009f01cd18d4$a944bc80$fbce3580$@nguyen@alicosystems.com> (Shawn Nguyen's message of "Thu, 12 Apr 2012 10:49:49 -0700") References: <308464.9193.16465-8980-1350268598-1334235880@seznam.cz> <4F870659.6060200@sciopta.com> <009f01cd18d4$a944bc80$fbce3580$@nguyen@alicosystems.com> Message-ID: Hello Shawn, Shawn Nguyen writes: > Please remove me from this distribution. GNU Mailman based mailing lists allow users to unsubscribe themselves at anytime. Check the full headers of any message received from the mailing list for instructions for unsubscribing via email or the web. This list's headers contain the following header: List-Unsubscribe: , If using the web method, you will want to select the "Unsubscribe or edit options" button at the bottom of the web page. Thanks, -- Ricardo Anguiano Mentor Graphics +1-510-354-6774