From matt at pod7.org Wed Feb 20 17:50:40 2008 From: matt at pod7.org (Matt Stephens) Date: Wed, 20 Feb 2008 17:50:40 -0000 Subject: m68k-elf-sprite options Message-ID: <001001c873e9$1cf08c80$56d1a580$@org> Can anyone tell me what the various options are for the m68k-elf-sprite program? Our board is based on the mcf5485 but when i try to configure debugging specifying m5485evb it fails. If i pass the name of the initialisation file for the insight debugger it complains that it can't parse it. I am assuming that the file must be xml but i can't find the format or schema for the file. I'm pretty sure if i can translate our plain text file into the required xml then i will be able to debug from eclipse. Thanks a lot Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlos at codesourcery.com Wed Feb 20 21:25:04 2008 From: carlos at codesourcery.com (Carlos O'Donell) Date: Wed, 20 Feb 2008 16:25:04 -0500 Subject: [coldfire-gnu-discuss] m68k-elf-sprite options In-Reply-To: <001001c873e9$1cf08c80$56d1a580$@org> References: <001001c873e9$1cf08c80$56d1a580$@org> Message-ID: <47BC9AB0.3030906@codesourcery.com> Matt Stephens wrote: > Can anyone tell me what the various options are for the m68k-elf-sprite > program? Our board is based on the mcf5485 but when i try to configure > debugging specifying m5485evb it fails. If i pass the name of the > initialisation file for the insight debugger it complains that it can?t > parse it. I am assuming that the file must be xml but i can?t find the > format or schema for the file. I?m pretty sure if i can translate our > plain text file into the required xml then i will be able to debug from > eclipse. Run the sprite with `--help' and it will print out the options. The board file format is XML, and the format is documented in the "Getting Started Guide" (getting-started.pdf) that comes with your installation of Sourcery G++. Tell me if that helps! Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From Viktor.Baumung at slc-liftco.com Thu Feb 21 11:04:52 2008 From: Viktor.Baumung at slc-liftco.com (Baumung Viktor) Date: Thu, 21 Feb 2008 12:04:52 +0100 Subject: file located in the SRAM Message-ID: Hello, I am using Cobra5485-board from senTec with ColdFire 5485?CPU. The attached source Tree (test.tar.gz) was compiled with CodeSourcery G++, compiler version 4.2.1 (Sourcery G++ 4.2-59). It is simply a "hello world" Application. The Linker Script (cobra5485_sram.ld) was modified to put the "sram_data.c" .data section into an external SRAM. (section "battram1"). The "Debug" folder contains the Makefiles for building the binary. When the program is downloaded and started, the code jumps to address 00000000, which causes the DBug Exception Handler (invalid instruction at PC 00000000). The working Version may be compiled with the other Linker script (cobra5485.ld) Here come interesting parts of "diff -ub cobra5485.ld cobra5485_sram.ld": MEMORY { @@ -27,9 +30,12 @@ rambar0 (rwx) : ORIGIN = 0x20000000, LENGTH = 4K rambar1 (rwx) : ORIGIN = 0x20002000, LENGTH = 4K mbar (rw) : ORIGIN = 0x10000000, LENGTH = 0x40000 + battram1 (rw) : ORIGIN = 0xFB800000, LENGTH = 0xA000 } -/* These force the linker to search for particular symbols from + +/* + * These force the linker to search for particular symbols from * the start of the link process and thus ensure the user's * overrides are picked up */ @@ -43,6 +49,7 @@ PROVIDE(__cs3_heap_start = _end); PROVIDE(__cs3_heap_end = __cs3_region_start_ram + __cs3_region_size_ram); + SECTIONS { .text : @@ -142,6 +149,12 @@ _etext = .; } >ram + .battram1 : + { + *sram_data.o (.data* .bss* COMMON) + _ebattram1 = .; + } >battram1 + .cs3.rom : { __cs3_region_start_rom = .; @@ -187,11 +200,13 @@ *(.rambar1) . = ALIGN (8); } >rambar1 + .cs3.rambar1.bss : { *(.rambar1.b) . = ALIGN (8); } >rambar1 + /* __cs3_region_end_rambar1 is deprecated */ __cs3_region_end_rambar1 = __cs3_region_start_rambar1 + LENGTH(rambar1); __cs3_region_size_rambar1 = LENGTH(rambar1); @@ -204,12 +219,14 @@ __cs3_region_start_mbar = .; __cs3_region_init_mbar = .; } >mbar + /* __cs3_region_end_mbar is deprecated */ __cs3_region_end_mbar = __cs3_region_start_mbar + LENGTH(mbar); __cs3_region_size_mbar = LENGTH(mbar); .data : { + *(EXCLUDE_FILE(*sram_data.o) .data*) *(.got.plt) *(.got) *(.shdata) *(.data .data.*) @@ -218,8 +235,10 @@ . = ALIGN (8); _edata = .; } >ram + .bss : { + *(EXCLUDE_FILE(*sram_data.o) .bss*) *(.shbss) *(.bss .bss.*) *(.gnu.linkonce.b.*) --------------------------------------------------------------------- Can you give a reason for this error? Attached you can find two files containing the original and modified linker script. Thank you very much for your support. With kind regards Viktor Baumung -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.tar.gz Type: application/x-gzip Size: 103907 bytes Desc: test.tar.gz URL: From daniel.mclean at optusnet.com.au Mon Feb 25 23:32:25 2008 From: daniel.mclean at optusnet.com.au (Daniel McLean) Date: Tue, 26 Feb 2008 09:32:25 +1000 Subject: Using ASSERT() in Linker Control Files Message-ID: Hi, I'm having some problems getting ASSERT() to work properly in the linker control file using Code Sourcery Lite. I'm using version "freescale-coldfire-4.2-47-m68k-elf" of the Code Sourcery tools. I've got this ASSERT() function in my linker control file: (snippet of Linker control file) .bss : { . = ALIGN (4); __BSS_START = .; *(.shbss) *(.bss .bss.*) *(.gnu.linkonce.b.*) *(COMMON) . = ALIGN (8); __BSS_END = .; __HEAP_START = .; __HEAP_END = . + HEAPSIZE; __SP_END = __HEAP_END; __SP_INIT = __SP_END + STACKSIZE; ASSERT(((ORIGIN(ram) + LENGTH(ram)) > (__SP_INIT)), "Ram has overflown. Not enough room for heap/stack"); } >ram AT>rom Which generates this in the MAP file: 0x200038b8 . = ALIGN (0x8) *fill* 0x200038b4 0x4 00 0x200038b8 __BSS_END = . 0x200038b8 __HEAP_START = . 0x200078b8 __HEAP_END = (. + HEAPSIZE) 0x200078b8 __SP_END = __HEAP_END 0x200079b8 __SP_INIT = (__SP_END + STACKSIZE) 0x20001709 ASSERT ((0x20008000 > __SP_INIT), Ram has overflown. Not enough room for heap/stack) This seems as expected. Now if I increase the start of the heap just to test whether the ASSERT will work like so: .bss : { . = ALIGN (4); __BSS_START = .; *(.shbss) *(.bss .bss.*) *(.gnu.linkonce.b.*) *(COMMON) . = ALIGN (8); __BSS_END = .; . += 0x1000; __HEAP_START = .; __HEAP_END = . + HEAPSIZE; __SP_END = __HEAP_END; __SP_INIT = __SP_END + STACKSIZE; ASSERT(((ORIGIN(ram) + LENGTH(ram)) > (__SP_INIT)), "Ram has overflown. Not enough room for heap/stack"); } >ram AT>rom I now get this in the map file: 0x200038b8 . = ALIGN (0x8) *fill* 0x200038b4 0x4 00 0x200038b8 __BSS_END = . 0x200048b8 . = (. + 0x1000) *fill* 0x200038b8 0x1000 00 0x200048b8 __HEAP_START = . 0x200088b8 __HEAP_END = (. + HEAPSIZE) 0x200088b8 __SP_END = __HEAP_END 0x200089b8 __SP_INIT = (__SP_END + STACKSIZE) 0x20001709 ASSERT ((0x20008000 > __SP_INIT), Ram has overflown. Not enough room for heap/stack) Now shouldn't the assertion fail since __SP_INIT is larger than 0x20008000?? The linker does not generate any errors.. Am I overlooking something??? Thanks Daniel _____________________________________ Daniel McLean Email: daniel.mclean at optusnet.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.mclean at optusnet.com.au Mon Feb 25 05:58:08 2008 From: daniel.mclean at optusnet.com.au (Daniel McLean) Date: Mon, 25 Feb 2008 15:58:08 +1000 Subject: Using ASSERT() in Linker Control Files Message-ID: Hi, I'm having some problems getting ASSERT() to work properly in the linker control file using Code Sourcery Lite. I'm using version "freescale-coldfire-4.2-47-m68k-elf" of the Code Sourcery tools. I've got this ASSERT() function in my linker control file: (snippet of Linker control file) .bss : { . = ALIGN (4); __BSS_START = .; *(.shbss) *(.bss .bss.*) *(.gnu.linkonce.b.*) *(COMMON) . = ALIGN (8); __BSS_END = .; __HEAP_START = .; __HEAP_END = . + HEAPSIZE; __SP_END = __HEAP_END; __SP_INIT = __SP_END + STACKSIZE; ASSERT(((ORIGIN(ram) + LENGTH(ram)) > (__SP_INIT)), "Ram has overflown. Not enough room for heap/stack"); } >ram AT>rom Which generates this in the MAP file: 0x200038b8 . = ALIGN (0x8) *fill* 0x200038b4 0x4 00 0x200038b8 __BSS_END = . 0x200038b8 __HEAP_START = . 0x200078b8 __HEAP_END = (. + HEAPSIZE) 0x200078b8 __SP_END = __HEAP_END 0x200079b8 __SP_INIT = (__SP_END + STACKSIZE) 0x20001709 ASSERT ((0x20008000 > __SP_INIT), Ram has overflown. Not enough room for heap/stack) This seems as expected. Now if I increase the start of the heap just to test whether the ASSERT will work like so: .bss : { . = ALIGN (4); __BSS_START = .; *(.shbss) *(.bss .bss.*) *(.gnu.linkonce.b.*) *(COMMON) . = ALIGN (8); __BSS_END = .; . += 0x1000; __HEAP_START = .; __HEAP_END = . + HEAPSIZE; __SP_END = __HEAP_END; __SP_INIT = __SP_END + STACKSIZE; ASSERT(((ORIGIN(ram) + LENGTH(ram)) > (__SP_INIT)), "Ram has overflown. Not enough room for heap/stack"); } >ram AT>rom I now get this in the map file: 0x200038b8 . = ALIGN (0x8) *fill* 0x200038b4 0x4 00 0x200038b8 __BSS_END = . 0x200048b8 . = (. + 0x1000) *fill* 0x200038b8 0x1000 00 0x200048b8 __HEAP_START = . 0x200088b8 __HEAP_END = (. + HEAPSIZE) 0x200088b8 __SP_END = __HEAP_END 0x200089b8 __SP_INIT = (__SP_END + STACKSIZE) 0x20001709 ASSERT ((0x20008000 > __SP_INIT), Ram has overflown. Not enough room for heap/stack) Now shouldn't the assertion fail since __SP_INIT is larger than 0x20008000?? The linker does not generate any errors.. Am I overlooking something??? Thanks Daniel _____________________________________ Daniel McLean Email: daniel.mclean at optusnet.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: