From john at dms-tech.com Thu Jan 4 10:26:53 2007 From: john at dms-tech.com (DMS Tech, John) Date: Thu, 4 Jan 2007 12:26:53 +0200 Subject: The option -fkeep-static-consts Message-ID: I am using the G++ 4.1-32 version. I have some static constants in my code and whenever I use a optimization option (-O1, ..) these static constants disappear from my compiled output file. The flag '-fkeep-static-consts' does not seem to have any effect in any of the optimization modes. Before I was using an older version and in that version this flag worked correctly. Is this a bug or am I overlooking something? John. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at codesourcery.com Thu Jan 4 20:19:50 2007 From: mark at codesourcery.com (Mark Mitchell) Date: Thu, 04 Jan 2007 12:19:50 -0800 Subject: [coldfire-gnu-discuss] The option -fkeep-static-consts In-Reply-To: References: Message-ID: <459D6166.2000703@codesourcery.com> DMS Tech, John wrote: > I am using the G++ 4.1-32 version. I have some static constants in my > code and whenever I use a optimization option (-O1, ..) these static > constants disappear from my compiled output file. The compiler is behaving as expected: `-fkeep-static-consts' Emit variables declared `static const' when optimization isn't turned on, even if the variables aren't referenced. When optimization is on, the compiler always removes unreferenced static constants. Older versions of the compiler may not have been smart enough to do so. The option is actually intended to be used in the negative: m68k-elf-gcc -g -fno-keep-static-consts a.c compiles a.c without optimization, but throws away unreferenced static constants. Without the option, they would be kept. To keep the static ocnstants at all optimization levels, use the "used' attribute: static const int i __attribute__((used)) = 7; -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From john at dms-tech.com Fri Jan 5 06:59:22 2007 From: john at dms-tech.com (DMS Tech, John) Date: Fri, 5 Jan 2007 08:59:22 +0200 Subject: Warning messages Message-ID: I am getting the following warning messages in my code: "warning: pointer targets in passing argument 1 of 'OSGetINI' differ in signedness" These warnings occur when I have declared the function with 'unsigned char *someparametername' and I want to pass a constant string in the function call. Example: void somefunction(unsigned char *someparametername); .. .. .. Somefunction("This constant string"); .. .. .. When I switch these warnings off with the compiler option '-Wno-pointer-sign' these warnings are suppressed, but my question is now when a real problem occurs like this example: void somefunction(unsigned char *someparametername); signed char *somesignedvariable; ... ... Somefunction(somesignedvariable); ... ... Is this going to get the warning still or is this warning also suppressed? If so is there another way to stop the warnings from the first example and still detect the warnings from the second? John. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at dms-tech.com Fri Jan 5 10:43:58 2007 From: john at dms-tech.com (DMS Tech, John) Date: Fri, 5 Jan 2007 12:43:58 +0200 Subject: Optimizing problem Message-ID: When I use the optimize option -O1 I have a problem that a small delay loop, used in a boot-loader program, gets optimized out of the code. Only the function call stays but the actual while loop is removed. Is there any compiler option to make sure this loop stays intact or a '__attribute__', which will make sure this function is not optimized? John. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at westcontrol.com Fri Jan 5 10:43:17 2007 From: david at westcontrol.com (David Brown) Date: Fri, 05 Jan 2007 11:43:17 +0100 Subject: [coldfire-gnu-discuss] Warning messages In-Reply-To: References: Message-ID: <459E2BC5.2090707@westcontrol.com> Hi John, (Please turn off the request for read receipts in your email program - they do not work, and just annoy people, especially on mailing lists.) What you are getting wrong here is that there are three types of char - "unsigned char", "signed char", and "char" (also known as plain char). A string literal is always a pointer to plain char, so if you pass it to a function expecting a pointer to unsigned chars, the signedness differes. This is the case regardless of whether the compiler is using signed or unsigned values for plain chars (it's a compiler switch - I don't know what the default is for m68k gcc). The way to deal with this is to be more specific about your data. If you are dealing with strings and characters, then use plain char, including in the function declaration. If what you want is eight bit numbers, then use "signed char" or "unsigned char" as appropriate (or, much better, use typedef'ed types - either standard ones like uint8, or your own ones). mvh., David DMS Tech, John wrote: > I am getting the following warning messages in my code: > > > > ?warning: pointer targets in passing argument 1 of 'OSGetINI' differ in > signedness? > > > > These warnings occur when I have declared the function with ?unsigned > char *someparametername? and I want to pass a constant string in the > function call. Example: > > > > void somefunction(unsigned char *someparametername); > > > > .. > > .. > > .. > > Somefunction(?This constant string?); > > .. > > .. > > .. > > > > When I switch these warnings off with the compiler option > ?-Wno-pointer-sign? these warnings are suppressed, but my question is > now when a real problem occurs like this example: > > > > void somefunction(unsigned char *someparametername); > > > > signed char *somesignedvariable; > > > > ? > > ? > > Somefunction(somesignedvariable); > > ? > > ? > > Is this going to get the warning still or is this warning also suppressed? > > > > If so is there another way to stop the warnings from the first example > and still detect the warnings from the second? > > > > John. > > > > > From david at westcontrol.com Fri Jan 5 11:22:54 2007 From: david at westcontrol.com (David Brown) Date: Fri, 05 Jan 2007 12:22:54 +0100 Subject: [coldfire-gnu-discuss] Optimizing problem In-Reply-To: References: Message-ID: <459E350E.3080504@westcontrol.com> DMS Tech, John wrote: > When I use the optimize option ?O1 I have a problem that a small delay > loop, used in a boot-loader program, gets optimized out of the code. > Only the function call stays but the actual while loop is removed. Is > there any compiler option to make sure this loop stays intact or a > ?__attribute__?, which will make sure this function is not optimized? > > You have to remember that the compiler generates code to give you the effects you ask for - it does not do a blind translation of C code to assembly (unless you use no optimization). So if you write something like: void delay(void) { int i; for (i = 0; i < 1000; i++); } The compiler is smart enough to see that this does nothing, and generates no code. If you want to force a delay, and don't want to do it properly with a timer or something (such as when you are starting up and have not got timers running, or for very short delays), then the easiest method is to declare the loop variable to be "volatile". Regarding optimisation - the most sensible choice for most work is -O2 optimisation, which gives good code while still being clear enough for debugging. Sometimes you might want -O1 if you want to examine generated assembly, but I have never found a use for turning off optimisation. If your code works with optimisation off, but fails with it enabled, then your code (or your compiler :-) is broken. mvh., David > > John. > > > From paul.mcconkey at cambridgeimaging.co.uk Fri Jan 5 11:09:45 2007 From: paul.mcconkey at cambridgeimaging.co.uk (Paul McConkey) Date: Fri, 5 Jan 2007 11:09:45 -0000 Subject: [coldfire-gnu-discuss] Warning messages In-Reply-To: Message-ID: <59789F6B85725F4CAD78243CDDBA4C662BB652@SERVA.grange.local> Hi John, Just to add to David's well made reply... The warnings are appearing to let you know that the type for the variable and the type in the function declaration don't match _exactly_. You will get this warning or similar ones if the types differ in other ways, ie volatile, const, etc., qualifiers don't match. As David says, you probably need to be more precise about your typing. (Btw, I thought that signed char and char were the same). If you know that you won't have any bad side effects, you can also cast the variable to match the the function declaration. Beware that you are in effect telling the compiler that you know better than it how to deal with your variable! It is unsafe coding and not good practice to cast variables all over the place, but it is often convenient and can make code easier to follow so just do it with care. Cheers, Paul. (Emails with read receipt requests normally get killed by my junk mail filter - this only gets through as I have white listed codesourcery.com, but I agree with David's comments) From nathan at codesourcery.com Sat Jan 6 14:33:40 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Sat, 06 Jan 2007 14:33:40 +0000 Subject: [coldfire-gnu-discuss] Warning messages In-Reply-To: References: Message-ID: <459FB344.2000707@codesourcery.com> DMS Tech, John wrote: > When I switch these warnings off with the compiler option > ?-Wno-pointer-sign? these warnings are suppressed, but my question is > now when a real problem occurs like this example: > > > > void somefunction(unsigned char *someparametername); > signed char *somesignedvariable; > Somefunction(somesignedvariable); > Is this going to get the warning still or is this warning also suppressed? The warning will be suppressed. Plain char is signed on coldfire. > If so is there another way to stop the warnings from the first example > and still detect the warnings from the second? No, because they are the same case, as far as the compiler is concerned. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From nathan at codesourcery.com Sat Jan 6 14:35:28 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Sat, 06 Jan 2007 14:35:28 +0000 Subject: [coldfire-gnu-discuss] Optimizing problem In-Reply-To: References: Message-ID: <459FB3B0.2000806@codesourcery.com> DMS Tech, John wrote: > When I use the optimize option ?O1 I have a problem that a small delay > loop, used in a boot-loader program, gets optimized out of the code. > Only the function call stays but the actual while loop is removed. Is > there any compiler option to make sure this loop stays intact or a > ?__attribute__?, which will make sure this function is not optimized? for (i = 0; i != limit; i++) __asm__ volatile (""); The compiler will not optimize this loop away, and the body of the loop will be an empty asm. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From paam at cegetel.net Tue Jan 9 19:24:27 2007 From: paam at cegetel.net (Philippe ROUVEYROL) Date: Tue, 09 Jan 2007 20:24:27 +0100 Subject: library libc.a Message-ID: <002c01c73423$c7bbc5a0$6cb74c56@phil5a43b14938> Hello, I am using the lite sourcery toolchain 4.1-32 for elf coldfire 5208 on Window 2000 I would like use "sprint" function also i have included library libc.a in my linker command line : m68k-elf-ld -o release.elf $(OBJS_C) $(OBJS_S) -lc -Trelease.ld #($(OBJS_C) $(OBJS_S) = list of .o generated by m68k-elf-gcc and m68k-elf-as) when I run command line above i got errors below c:\program files\codesourcery\sourcery g++\bin\../m68k-elf/lib\libc.a(vfprintf.o): In function `_vfprintf_r': vfprintf.c:(.text+0x111a): undefined reference to `__umoddi3' vfprintf.c:(.text+0x692): undefined reference to `__eqdf2' ..... c:\program files\codesourcery\sourcery g++\bin\../m68k-elf/lib\libc.a(dtoa.o): In function `_dtoa_r': dtoa.c:(.text+0x204): undefined reference to `__nedf2' dtoa.c:(.text+0x298): undefined reference to `__floatunsidf' .... ... c:\program files\codesourcery\sourcery g++\bin\../m68k-elf/lib\libc.a(makebuf.o): In function `__smakebuf': makebuf.c:(.text+0xba): undefined reference to `isatty' c:\program files\codesourcery\sourcery g++\bin\../m68k-elf/lib\libc.a(mprec.o): In function `_ratio': mprec.c:(.text+0x2ec): undefined reference to `__divdf3' c:\program files\codesourcery\sourcery g++\bin\../m68k-elf/lib\libc.a(mprec.o): In function `_mprec_log10': mprec.c:(.text+0x33e): undefined reference to `__muldf3' c:\program files\codesourcery\sourcery g++\bin\../m68k-elf/lib\libc.a(mprec.o): In function `_s2b': mprec.c:(.text+0xa08): undefined reference to `__divsi3' c:\program files\codesourcery\sourcery g++\bin\../m68k-elf/lib\libc.a(sbrkr.o): In function `_sbrk_r': sbrkr.c:(.text+0x10): undefined reference to `sbrk' c:\program files\codesourcery\sourcery g++\bin\../m68k-elf/lib\libc.a(writer.o): In function `_write_r': writer.c:(.text+0x18): undefined reference to `write' c:\program files\codesourcery\sourcery g++\bin\../m68k-elf/lib\libc.a(closer.o): In function `_close_r': closer.c:(.text+0x10): undefined reference to `close' c:\program files\codesourcery\sourcery g++\bin\../m68k-elf/lib\libc.a(fstatr.o): In function `_fstat_r': fstatr.c:(.text+0x14): undefined reference to `fstat' c:\program files\codesourcery\sourcery g++\bin\../m68k-elf/lib\libc.a(lseekr.o): In function `_lseek_r': lseekr.c:(.text+0x18): undefined reference to `lseek' c:\program files\codesourcery\sourcery g++\bin\../m68k-elf/lib\libc.a(readr.o): In function `_read_r': readr.c:(.text+0x18): undefined reference to `read' cs-make: *** [board.elf] Error 1 rgds, paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at codesourcery.com Tue Jan 9 20:46:31 2007 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Tue, 9 Jan 2007 15:46:31 -0500 Subject: [coldfire-gnu-discuss] library libc.a In-Reply-To: <002c01c73423$c7bbc5a0$6cb74c56@phil5a43b14938> References: <002c01c73423$c7bbc5a0$6cb74c56@phil5a43b14938> Message-ID: <20070109204630.GL6004@caradoc.them.org> On Tue, Jan 09, 2007 at 08:24:27PM +0100, Philippe ROUVEYROL wrote: > m68k-elf-ld -o release.elf $(OBJS_C) $(OBJS_S) -lc -Trelease.ld You should use m68k-elf-gcc to link, in most cases, not m68k-elf-ld. If you use gcc, it will add libc automatically - and also libgcc, which contains the functions you are missing. -- Daniel Jacobowitz CodeSourcery From matsblide at hotmail.com Wed Jan 17 09:38:43 2007 From: matsblide at hotmail.com (Mats Blide) Date: Wed, 17 Jan 2007 09:38:43 +0000 Subject: GNU Linker Message-ID: Hi, I don't know if this is the right forum, but I have notised that it is fairly active and gives quick response. So I give it a try. I'am still a GNU newbie. I'am in the process off sliming a FreeRTOS/lwIP configuration to fitt into my limited 32K RAM. I'am used to linkers that can produce a map file where I can se the size of every individual object, but I'am not able to figure out how to do this with GCC. As it is now it only shows the RAM size used by each objectfile as a whole. Any help appresiated highly apreceated! Rgds /Mats _________________________________________________________________ Tr?ffa singlar d?r du bor http://match.se.msn.com/channel/index.aspx?trackingid=1002962 From pixievn at gmail.com Wed Jan 17 10:43:05 2007 From: pixievn at gmail.com (Tien Truong) Date: Wed, 17 Jan 2007 17:43:05 +0700 Subject: Problems with 5282evb Message-ID: <000e01c73a24$545bbb40$0654a8c0@pyramidsoftwares.com> Hi All, I'm using the Sourcery G++ 4.1-32 for ColdFire Released to implement the eembc benchmark running on 5282evb board. But I got an issue below when linking. Do I need to re-build the libraries? and the linker command file that I used is not correct? Could you please give me some instructions? m68k-elf-gcc -c -mcpu=5282 -I. -I../th/gnucoldfire/al -I../th/src -o gnucol dfire/obj/thal.o ../th/gnucoldfire/al/thal.c m68k-elf-gcc -c -mcpu=5282 -I. -I../th/gnucoldfire/al -I../th/src -o gnucol dfire/obj/anytoi.o ../th/src/anytoi.c m68k-elf-gcc -c -mcpu=5282 -I. -I../th/gnucoldfire/al -I../th/src -o gnucol dfire/obj/crc.o ../th/src/crc.c m68k-elf-gcc -c -mcpu=5282 -I. -I../th/gnucoldfire/al -I../th/src -o gnucol dfire/obj/heap.o ../th/src/heap.c m68k-elf-gcc -c -mcpu=5282 -I. -I../th/gnucoldfire/al -I../th/src -o gnucol dfire/obj/memmgr.o ../th/src/memmgr.c m68k-elf-gcc -c -mcpu=5282 -I. -I../th/gnucoldfire/al -I../th/src -o gnucol dfire/obj/printfe.o ../th/src/printfe.c m68k-elf-gcc -c -mcpu=5282 -I. -I../th/gnucoldfire/al -I../th/src -o gnucol dfire/obj/ssubs.o ../th/src/ssubs.c m68k-elf-gcc -c -mcpu=5282 -I. -I../th/gnucoldfire/al -I../th/src -o gnucol dfire/obj/therror.o ../th/src/therror.c m68k-elf-gcc -c -mcpu=5282 -I. -I../th/gnucoldfire/al -I../th/src -o gnucol dfire/obj/thfl.o ../th/src/thfl.c m68k-elf-gcc -c -mcpu=5282 -I. -I../th/gnucoldfire/al -I../th/src -o gnucol dfire/obj/thlib.o ../th/src/thlib.c m68k-elf-gcc -c -mcpu=5282 -I. -I../th/gnucoldfire/al -I../th/src -o gnucol dfire/obj/uuencode.o ../th/src/uuencode.c m68k-elf-ar scr gnucoldfire/obj/thobjs.a gnucoldfire/obj/thal.o gnucoldfire/obj /anytoi.o gnucoldfire/obj/crc.o gnucoldfire/obj/heap.o gnucoldfire/obj/memmgr.o gnucoldfire/obj/printfe.o gnucoldfire/obj/ssubs.o gnucoldfire/obj/therror.o gnuc oldfire/obj/thfl.o gnucoldfire/obj/thlib.o gnucoldfire/obj/uuencode.o m68k-elf-gcc -c -mcpu=5282 -I. -I../th/gnucoldfire/al -I../th/src -Ittsprk0 1 -DITERATIONS=1 -I. -I../th/gnucoldfire/al -I../th/src -o gnucoldfire/obj/ttsp rk01/algotst.o ttsprk01/algotst.c m68k-elf-gcc -c -mcpu=5282 -I. -I../th/gnucoldfire/al -I../th/src -Ittsprk0 1 -DITERATIONS=1 -I. -I../th/gnucoldfire/al -I../th/src -o gnucoldfire/obj/ttsp rk01/bmark.o ttsprk01/bmark.c m68k-elf-gcc -mcpu=5282 -T"C:\cvs_test\validation_suites\Benchmarks\eembc_1_1\to plevel\th\gnucoldfire\al\m5282evb-ram-hosted.ld" -g -o gnucoldfire/bin/ttsprk0 1.elf gnucoldfire/obj/ttsprk01/algotst.o gnucoldfire/obj/ttsprk01/bmark.o gnuco ldfire/obj/thobjs.a c:/program files/codesourcery/sourcery g++/bin/../lib/gcc/m68k-elf/4.1.1/../../. ./../m68k-elf/lib/m5208\libcf.a(cf-crt1.o): In function `__start1': cf-crt1.c:(.text+0xaa): undefined reference to `main' collect2: ld returned 1 exit status make: *** [gnucoldfire/bin/ttsprk01.elf] Error 1 Thanks, Tien Truong -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: m5282evb-ram-hosted.ld Type: application/octet-stream Size: 2732 bytes Desc: not available URL: From david at westcontrol.com Wed Jan 17 10:38:06 2007 From: david at westcontrol.com (David Brown) Date: Wed, 17 Jan 2007 11:38:06 +0100 Subject: [coldfire-gnu-discuss] GNU Linker In-Reply-To: References: Message-ID: <45ADFC8E.2010406@westcontrol.com> Mats Blide wrote: > > Hi, > > I don't know if this is the right forum, but I have notised that it is > fairly active and gives quick response. So I give it a try. I'am still a > GNU newbie. > > I'am in the process off sliming a FreeRTOS/lwIP configuration to fitt > into my limited 32K RAM. I'am used to linkers that can produce a map > file where I can se the size of every individual object, but I'am not > able to figure out how to do this with GCC. As it is now it only shows > the RAM size used by each objectfile as a whole. > > Any help appresiated highly apreceated! > > Rgds /Mats > You want something like: -Wl,-Map=program.map and possibly -Wl,--cref in the command line for gcc when doing the linking. Running m68k-elf-size on the elf file will also give you the sizes of the sections, and objdump can give more details. From matsblide at hotmail.com Wed Jan 17 13:23:10 2007 From: matsblide at hotmail.com (Mats Blide) Date: Wed, 17 Jan 2007 13:23:10 +0000 Subject: [coldfire-gnu-discuss] GNU Linker In-Reply-To: <45ADFC8E.2010406@westcontrol.com> Message-ID: Thank's for your answer. I tried your suggestions, but they seam reluctant to give me the sizes of individual variables. What I'am looking for is something like this: .data 0x20000000 0x100 project/MyObjectFile.o 0x20000000 0x050 MyBuffer 0x20000050 0x002 MyVar 0x20000052 0x048 MySomeOtherBuffer Now only have things like this: .bss 0x20003264 0x907 lwip/src/core/pbuf.o Telling me that pbuf.o consumes 0x907 bytes RAM in segment bss. And that's fair enough. But I would like to se what is using that RAM. /Mats >From: David Brown >To: Mats Blide , >coldfire-gnu-discuss at codesourcery.com >Subject: Re: [coldfire-gnu-discuss] GNU Linker >Date: Wed, 17 Jan 2007 11:38:06 +0100 > >Mats Blide wrote: >> >>Hi, >> >>I don't know if this is the right forum, but I have notised that it is >>fairly active and gives quick response. So I give it a try. I'am still a >>GNU newbie. >> >>I'am in the process off sliming a FreeRTOS/lwIP configuration to fitt into >>my limited 32K RAM. I'am used to linkers that can produce a map file where >>I can se the size of every individual object, but I'am not able to figure >>out how to do this with GCC. As it is now it only shows the RAM size used >>by each objectfile as a whole. >> >>Any help appresiated highly apreceated! >> >>Rgds /Mats >> > >You want something like: > -Wl,-Map=program.map > >and possibly > -Wl,--cref > > >in the command line for gcc when doing the linking. > >Running m68k-elf-size on the elf file will also give you the sizes of the >sections, and objdump can give more details. > > _________________________________________________________________ V?rlden bevakas p? MSN http://nyheter.msn.se/ From pradeepkumarb at hcl.in Wed Jan 17 13:22:06 2007 From: pradeepkumarb at hcl.in (Pradeep Kumar Bola, TLS,Chennai) Date: Wed, 17 Jan 2007 18:52:06 +0530 Subject: m5213 Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- From david at westcontrol.com Wed Jan 17 14:17:31 2007 From: david at westcontrol.com (David Brown) Date: Wed, 17 Jan 2007 15:17:31 +0100 Subject: [coldfire-gnu-discuss] GNU Linker In-Reply-To: References: Message-ID: <45AE2FFB.1070307@westcontrol.com> The map file will give you a break-down by section and object file, so you can at least see which object file is using the space. If you need more detail, you can always try the "-fdata-sections" option on the compiler, which will put each data item in its own section. I haven't used it myself, but give it a shot. http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fdata_002dsections-577 mvh., David Mats Blide wrote: > Thank's for your answer. I tried your suggestions, but they seam > reluctant to give me the sizes of individual variables. What I'am > looking for is something like this: > > .data 0x20000000 0x100 project/MyObjectFile.o > 0x20000000 0x050 MyBuffer > 0x20000050 0x002 MyVar > 0x20000052 0x048 MySomeOtherBuffer > > Now only have things like this: > > .bss 0x20003264 0x907 lwip/src/core/pbuf.o > > > > Telling me that pbuf.o consumes 0x907 bytes RAM in segment bss. And > that's fair enough. But I would like to se what is using that RAM. > > /Mats > > > > >> From: David Brown >> To: Mats Blide , >> coldfire-gnu-discuss at codesourcery.com >> Subject: Re: [coldfire-gnu-discuss] GNU Linker >> Date: Wed, 17 Jan 2007 11:38:06 +0100 >> >> Mats Blide wrote: >>> >>> Hi, >>> >>> I don't know if this is the right forum, but I have notised that it >>> is fairly active and gives quick response. So I give it a try. I'am >>> still a GNU newbie. >>> >>> I'am in the process off sliming a FreeRTOS/lwIP configuration to fitt >>> into my limited 32K RAM. I'am used to linkers that can produce a map >>> file where I can se the size of every individual object, but I'am not >>> able to figure out how to do this with GCC. As it is now it only >>> shows the RAM size used by each objectfile as a whole. >>> >>> Any help appresiated highly apreceated! >>> >>> Rgds /Mats >>> >> >> You want something like: >> -Wl,-Map=program.map >> >> and possibly >> -Wl,--cref >> >> >> in the command line for gcc when doing the linking. >> >> Running m68k-elf-size on the elf file will also give you the sizes of >> the sections, and objdump can give more details. >> >> > > _________________________________________________________________ > V?rlden bevakas p? MSN http://nyheter.msn.se/ > > From nathan at codesourcery.com Wed Jan 17 16:23:01 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 17 Jan 2007 16:23:01 +0000 Subject: [coldfire-gnu-discuss] GNU Linker In-Reply-To: References: Message-ID: <45AE4D65.9040108@codesourcery.com> Mats Blide wrote: > Thank's for your answer. I tried your suggestions, but they seam > reluctant to give me the sizes of individual variables. What I'am > looking for is something like this: > > .data 0x20000000 0x100 project/MyObjectFile.o > 0x20000000 0x050 MyBuffer > 0x20000050 0x002 MyVar > 0x20000052 0x048 MySomeOtherBuffer you can use m68k-elf-nm -S to do this nm -S xgcc 08064068 00000008 r __FUNCTION__.12567 that's at address 08064068 size 8 weak readonly object nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From matsblide at hotmail.com Wed Jan 17 16:23:29 2007 From: matsblide at hotmail.com (Mats Blide) Date: Wed, 17 Jan 2007 16:23:29 +0000 Subject: [coldfire-gnu-discuss] GNU Linker In-Reply-To: <45AE2FFB.1070307@westcontrol.com> Message-ID: Thank you for your help. I tried the compilerswitch and although it gave me som segment overlap error in the linking it atleast created a map file that gave me a better overview of the RAM usage. /Mats >From: David Brown >To: Mats Blide >CC: coldfire-gnu-discuss at codesourcery.com >Subject: Re: [coldfire-gnu-discuss] GNU Linker >Date: Wed, 17 Jan 2007 15:17:31 +0100 > >The map file will give you a break-down by section and object file, so you >can at least see which object file is using the space. If you need more >detail, you can always try the "-fdata-sections" option on the compiler, >which will put each data item in its own section. I haven't used it >myself, but give it a shot. > >http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fdata_002dsections-577 > >mvh., > >David > > >Mats Blide wrote: >>Thank's for your answer. I tried your suggestions, but they seam reluctant >>to give me the sizes of individual variables. What I'am looking for is >>something like this: >> >>.data 0x20000000 0x100 project/MyObjectFile.o >> 0x20000000 0x050 MyBuffer >> 0x20000050 0x002 MyVar >> 0x20000052 0x048 MySomeOtherBuffer >> >>Now only have things like this: >> >>.bss 0x20003264 0x907 lwip/src/core/pbuf.o >> >> >> >>Telling me that pbuf.o consumes 0x907 bytes RAM in segment bss. And that's >>fair enough. But I would like to se what is using that RAM. >> >>/Mats >> >> >> >> >>>From: David Brown >>>To: Mats Blide , >>>coldfire-gnu-discuss at codesourcery.com >>>Subject: Re: [coldfire-gnu-discuss] GNU Linker >>>Date: Wed, 17 Jan 2007 11:38:06 +0100 >>> >>>Mats Blide wrote: >>>> >>>>Hi, >>>> >>>>I don't know if this is the right forum, but I have notised that it is >>>>fairly active and gives quick response. So I give it a try. I'am still a >>>>GNU newbie. >>>> >>>>I'am in the process off sliming a FreeRTOS/lwIP configuration to fitt >>>>into my limited 32K RAM. I'am used to linkers that can produce a map >>>>file where I can se the size of every individual object, but I'am not >>>>able to figure out how to do this with GCC. As it is now it only shows >>>>the RAM size used by each objectfile as a whole. >>>> >>>>Any help appresiated highly apreceated! >>>> >>>>Rgds /Mats >>>> >>> >>>You want something like: >>> -Wl,-Map=program.map >>> >>>and possibly >>> -Wl,--cref >>> >>> >>>in the command line for gcc when doing the linking. >>> >>>Running m68k-elf-size on the elf file will also give you the sizes of the >>>sections, and objdump can give more details. >>> >>> >> >>_________________________________________________________________ >>V?rlden bevakas p? MSN http://nyheter.msn.se/ >> >> > > _________________________________________________________________ MSN bjuder p? musikstreaming i en m?nad http://www.msn.se/music/ From nathan at codesourcery.com Wed Jan 17 16:26:10 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 17 Jan 2007 16:26:10 +0000 Subject: [coldfire-gnu-discuss] m5213 In-Reply-To: References: Message-ID: <45AE4E22.8000307@codesourcery.com> Pradeep Kumar Bola, TLS,Chennai wrote: > Hi, > > I am planning to use "CodeSourcery" as development tool for my freescale > evaluation board evb5213. > How can I use the same tool? where can I get some examples for startup? you can download the public 'lite' edition from http://www.codesourcery.com/gnu_toolchains/coldfire/download.html, or if you are interested in Sourcery G++ (includes eclipse and support), see http://www.codesourcery.com/gnu_toolchains/sgpp or send email to sales at codesourcery.com The startup source code is provided as part of the download, so you can adapt it for your application. The evb5213 board is supported. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From nathan at codesourcery.com Wed Jan 17 18:06:25 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 17 Jan 2007 18:06:25 +0000 Subject: [coldfire-gnu-discuss] Problems with 5282evb In-Reply-To: <000e01c73a24$545bbb40$0654a8c0@pyramidsoftwares.com> References: <000e01c73a24$545bbb40$0654a8c0@pyramidsoftwares.com> Message-ID: <45AE65A1.8090601@codesourcery.com> Tien Truong wrote: > m68k-elf-gcc -mcpu=5282 > -T"C:\cvs_test\validation_suites\Benchmarks\eembc_1_1\to > plevel\th\gnucoldfire\al\m5282evb-ram-hosted.ld" -g -o > gnucoldfire/bin/ttsprk0 > 1.elf gnucoldfire/obj/ttsprk01/algotst.o > gnucoldfire/obj/ttsprk01/bmark.o gnuco > ldfire/obj/thobjs.a > c:/program files/codesourcery/sourcery > g++/bin/../lib/gcc/m68k-elf/4.1.1/../../. > ./../m68k-elf/lib/m5208\libcf.a(cf-crt1.o): In function `__start1': > cf-crt1.c:(.text+0xaa): undefined reference to `main' > collect2: ld returned 1 exit status > make: *** [gnucoldfire/bin/ttsprk01.elf] Error 1 This is expected behaviour of the coldfire toolchains (I won't go into the details here). You can add '-u main' to your link line to resolve it. Here is an example that shows the failure without -u and success with -u. nathan at cugel:16>m68k-elf-gcc -c hello.c nathan at cugel:19>m68k-elf-ar cr libhello.a hello.o nathan at cugel:22>m68k-elf-gcc -T m5208evb-ram-hosted.ld -l hello /scratch/nathan/cf-elf/install/bin/../lib/gcc/m68k-elf/4.1.1/../../../../m68k-elf/lib/libcf.a(cf-crt1.o): In function `__start1': /home/nathan/cf/src/newlib-20060320/libgloss/m68k/cf-crt1.c:57: undefined reference to `main' collect2: ld returned 1 exit status nathan at cugel:23>m68k-elf-gcc -u main -T m5208evb-ram-hosted.ld -l hello nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From matsblide at hotmail.com Thu Jan 18 11:06:11 2007 From: matsblide at hotmail.com (Mats Blide) Date: Thu, 18 Jan 2007 11:06:11 +0000 Subject: MCF52233 access error exception. Message-ID: Hi again, Thank's for your previous help. Now I have my system up and running and it's talking TCP/IP to me and I am verry happy :-). But.....: I get access error exceptions. I have boiled down the problem being, calling functions in the address range F000-100000, as far as I can tell. I don't know if it is a hardware configuration problem or a GDB problem. Take a look at this: (gdb) disas Dump of assembler code for function start: 0x00000408 : movew %d4,%sr 0x0000040a : movel %d0,%a3 at - 0x0000040c : movel #536870912,%d0 0x00000412 : oril #513,%d0 0x00000418 : movec %d0,%rambar 0x0000041c : movel #289,%d0 0x00000422 : movec %d0,%flashbar 0x00000426 : moveal #536903679,%sp 0x0000042c : linkw %fp,#-8 0x00000430 : jsr 0xf2fe <----------------------- This was put here to provoke the problem. At 0xf2f2 there is a rst instruction. 0x00000436 : jsr 0x15d4 When single steping this: (gdb) nexti 57 move.l #__SRAM, d0 (gdb) 58 ori.l #( MCF5XXX_RAMBAR_SPV | MCF5XXX_RAMBAR_V ), d0 (gdb) 59 movec d0, rambar (gdb) 62 move.l #0x00000121,d0 (gdb) 63 movec d0,FLASHBAR (gdb) 66 move.l #__stack, sp (gdb) Cannot access memory at address 0x20007fff (gdb) start () at system/crt0.S:69 69 jsr 0xf2fe (gdb) Cannot access memory at address 0x20007fff (gdb) 0x04000000 in ?? () Now PC is 0x04000000!! And the stack looks like this: (gdb) i s #0 0x04000000 in ?? () #1 0x74082700 in ?? () #2 0x0000f2fe in udp_init () at lwip/src/core/udp.c:71 Cannot access memory at address 0x20007fff (gdb) When running the program, without the ?dummy? jsr 0xf2fe in the startup code it runs fine as long as there is no call to functions close to this address which results in a access error exception. Calling function at 0xa964 or 0x10100 for example is no problem. Help! :-) /Mats _________________________________________________________________ MSN bjuder p? musikstreaming i en m?nad http://www.msn.se/music/ From elbenard at gmail.com Thu Jan 18 15:56:17 2007 From: elbenard at gmail.com (Eric BENARD) Date: Thu, 18 Jan 2007 16:56:17 +0100 Subject: gcc-4.1-30 & SRAM Message-ID: <45AF98A1.8040903@gmail.com> Hi, I'm using a MCF5208 Coldfire which has 16kB of SRAM. I'm using the uclinux tools from Codesourcery on x86 : $ m68k-uclinux-gcc -v gcc version 4.1.1 (CodeSourcery Sourcery G++ 4.1-30) I'm trying to move parts of the code into SRAM without success until now. I've prefixed the test function I want to put in SRAM as follows : int __attribute__((__section__(".sramcode"))) func() In elf2flt.ld, I've added : MEMORY { flatmem : ORIGIN = 0x0, LENGTH = 0x1000000 sram : ORIGIN = 0x80000000, LENGTH = 12k } and .sramsection : { *(.sramdata) *(.sramcode) *(.text.sramcode.*) } > sram Then when I compile : $ m68k-uclinux-gcc -O3 -Wa,--register-prefix-optional -Wa,-memac -Wa,-mcpu=5208 -mcpu=5208 -o hw hw.c read error section .text collect2: ld returned 2 exit status I get a hw.gdb with the rights sections : $ m68k-uclinux-objdump -h hw.gdb hw.gdb: file format elf32-m68k Sections: Idx Name Size VMA LMA File off Algn 0 .text 00001360 00000000 00000000 00002000 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .data 00000200 00001360 00001360 00003360 2**2 CONTENTS, ALLOC, LOAD, RELOC, DATA 2 .bss 00002050 00001560 00001560 00003560 2**2 ALLOC 3 .sramsection 00000016 80000000 80000000 00004000 2**1 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 4 .comment 0000002f 00000000 00000000 00004016 2**0 CONTENTS, READONLY But elf2flt seems to fail : $ m68k-uclinux-elf2flt -v -o hw hw.gdb TEXT -> vma=0x0 len=0x80000016 read error section .text Do you have any idea of what is wrong and prevents generation of the flt binary ? Next stage will be to provide a code to copy the sramsection into SRAM as I don't think this will be done automagically but it's first necessary to manage to generate a flt binary ;) Many thanks Eric From nathan at codesourcery.com Thu Jan 18 16:26:27 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Thu, 18 Jan 2007 16:26:27 +0000 Subject: [coldfire-gnu-discuss] MCF52233 access error exception. In-Reply-To: References: Message-ID: <45AF9FB3.1080904@codesourcery.com> Mats Blide wrote: > 0x00000426 : moveal #536903679,%sp > 66 move.l #__stack, sp > (gdb) > Cannot access memory at address 0x20007fff There's at least one thing wrong here. You're initializing the stack pointer to 0x20007fff. The stack should be four byte aligned. It looks like the board's memory system is not initialized correctly. This message is happening because gdb is attempting to unwind the stack. You can check this yourself by trying things like (gdb) p/x *(int *)0x20007ffc = 0x12345678 (gdb) p/x *(int *)0x20007ffc You might also want to write a small piece of assembly code and insert it in __start to check that that memory region is functional. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From nathan at codesourcery.com Thu Jan 18 17:52:24 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Thu, 18 Jan 2007 17:52:24 +0000 Subject: [coldfire-gnu-discuss] gcc-4.1-30 & SRAM In-Reply-To: <45AF98A1.8040903@gmail.com> References: <45AF98A1.8040903@gmail.com> Message-ID: <45AFB3D8.3050204@codesourcery.com> Eric BENARD wrote: > Hi, > > I'm using a MCF5208 Coldfire which has 16kB of SRAM. > I'm using the uclinux tools from Codesourcery on x86 : > $ m68k-uclinux-gcc -v > gcc version 4.1.1 (CodeSourcery Sourcery G++ 4.1-30) > > I'm trying to move parts of the code into SRAM without success until now. > > I've prefixed the test function I want to put in SRAM as follows : > int __attribute__((__section__(".sramcode"))) func() > > In elf2flt.ld, I've added : > MEMORY { > flatmem : ORIGIN = 0x0, LENGTH = 0x1000000 > sram : ORIGIN = 0x80000000, LENGTH = 12k > } Thanks for using our downloads. What you're trying to do is not supported in this way. The FLT binary has to consist of text and data segments, along with a relocation table. You cannot add additional segments. All the relocations must be to symbols within the text or data (or bss) segments. This is a fundamental design of the FLT format. If you want to place code into sram, you will need to copy it there explicitly from within your application. The management of the SRAM is straying into OS issues that I am unfamiliar with -- perhaps uclinux has a mechanism to avoid multiple applications using that memory. Accessing objects in the sram region you define is going to be tricky. The most straight forward mechanism will be via a pointer to that memory. You may be able to produce a linker script that loads the sram image into the data segment, but keeps it's VMA as you desire. You'll have to adjust the FLT file creation to remove relocations against that segment (normally relocations are kept). I've not thought hard about this though. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From elbenard at gmail.com Thu Jan 18 18:07:43 2007 From: elbenard at gmail.com (Eric BENARD) Date: Thu, 18 Jan 2007 19:07:43 +0100 Subject: [coldfire-gnu-discuss] gcc-4.1-30 & SRAM In-Reply-To: <45AFB3D8.3050204@codesourcery.com> References: <45AF98A1.8040903@gmail.com> <45AFB3D8.3050204@codesourcery.com> Message-ID: <45AFB76F.6010008@gmail.com> Nathan Sidwell wrote : > Thanks for using our downloads. Thanks for your work on these tools ;-) > What you're trying to do is not > supported in this way. The FLT binary has to consist of text and data > segments, along with a relocation table. You cannot add additional > segments. All the relocations must be to symbols within the text or > data (or bss) segments. This is a fundamental design of the FLT format. > That's what I was afraid of ... > If you want to place code into sram, you will need to copy it there > explicitly from within your application. The management of the SRAM is > straying into OS issues that I am unfamiliar with -- perhaps uclinux has > a mechanism to avoid multiple applications using that memory. > uClinux doesn't use the internal SRAM. In my case I already manage to use 4kB for data with malloc/free functions reworked by Gerg Ungerer in it's mp3player. For code, there will be only one application using it so the management of thje SRAM should be pretty simple ... once I manage to link code into it ! > Accessing objects in the sram region you define is going to be tricky. > The most straight forward mechanism will be via a pointer to that > memory. You may be able to produce a linker script that loads the sram > image into the data segment, but keeps it's VMA as you desire. You'll > have to adjust the FLT file creation to remove relocations against that > segment (normally relocations are kept). I've not thought hard about > this though. > OK, I'll let you know if I find a way to do this. Many thanks and best regards Eric From david at westcontrol.com Fri Jan 19 09:22:23 2007 From: david at westcontrol.com (David Brown) Date: Fri, 19 Jan 2007 10:22:23 +0100 Subject: [coldfire-gnu-discuss] gcc-4.1-30 & SRAM In-Reply-To: <45AFB3D8.3050204@codesourcery.com> References: <45AF98A1.8040903@gmail.com> <45AFB3D8.3050204@codesourcery.com> Message-ID: <45B08DCF.7040308@westcontrol.com> Here's a possible way to cheat - int __attribute__((__section(".data"))) func(void) { ... } I haven't tried it with the ColdFire tools or the flt format (I've only used elf files, and then it's easy to add extra sections), but I've used it with gcc on the msp430 to get the same effect without having to modify linker files or startup code. Basically, the function implementation gets copied into ram along with initialised data. You will probably get assembler or linker warnings about changes to the sections attributes (suddenly the ".data" section is executable as well as read/write). You probably already know this, but when putting functions into ram like this (such as for flash programming routines), be very careful that any other functions (including library functions) that might be called are also in ram, and that interrupts are disabled before calling it - otherwise the processor will jump back to the flash. mvh., David Nathan Sidwell wrote: > Eric BENARD wrote: > > Hi, > > > > I'm using a MCF5208 Coldfire which has 16kB of SRAM. > > I'm using the uclinux tools from Codesourcery on x86 : > > $ m68k-uclinux-gcc -v > > gcc version 4.1.1 (CodeSourcery Sourcery G++ 4.1-30) > > > > I'm trying to move parts of the code into SRAM without success until > now. > > > > I've prefixed the test function I want to put in SRAM as follows : > > int __attribute__((__section__(".sramcode"))) func() > > > > In elf2flt.ld, I've added : > > MEMORY { > > flatmem : ORIGIN = 0x0, LENGTH = 0x1000000 > > sram : ORIGIN = 0x80000000, LENGTH = 12k > > } > > > Thanks for using our downloads. What you're trying to do is not > supported in this way. The FLT binary has to consist of text and data > segments, along with a relocation table. You cannot add additional > segments. All the relocations must be to symbols within the text or > data (or bss) segments. This is a fundamental design of the FLT format. > > If you want to place code into sram, you will need to copy it there > explicitly from within your application. The management of the SRAM is > straying into OS issues that I am unfamiliar with -- perhaps uclinux has > a mechanism to avoid multiple applications using that memory. > > Accessing objects in the sram region you define is going to be tricky. > The most straight forward mechanism will be via a pointer to that > memory. You may be able to produce a linker script that loads the sram > image into the data segment, but keeps it's VMA as you desire. You'll > have to adjust the FLT file creation to remove relocations against that > segment (normally relocations are kept). I've not thought hard about > this though. > > nathan > From matsblide at hotmail.com Fri Jan 19 11:07:59 2007 From: matsblide at hotmail.com (Mats Blide) Date: Fri, 19 Jan 2007 11:07:59 +0000 Subject: [coldfire-gnu-discuss] MCF52233 access error exception. In-Reply-To: <45AF9FB3.1080904@codesourcery.com> Message-ID: Yes, I had noticed that the stack pointer was wrong, stupid mistake :-). But it realy did no difference. Obviously there is something that I have not understood here newbie to GNU tools as well as coldfire. It seams to be no problem accessing the memory in the way you described. But there is something basically wrong in what I? am doing. If I make changes in assembler code in the startup most of the time I can't run it at all. I do: hb start jump start and when I do the first: nexti sometimes it runs the next instruction and sometimes just crashes. And the most of the time the pc is suddenly 0x40000000. I have a feeling that it has something to do with alignment because adding or removing 'dummy' instructions gives different result. I must admit that I have only browsed the manuals for coldfire and GNU tools on this matter. But I have tried to copy the start up code from a software built in CodeWarrior, and that runs fine ion the board I have. But it crashes as soon as I try to run it the GNU environment. I'am basicly lost here, so any hints about what?s wrong would be highly appreciated. I? am running a M52233DEMO board with a MCF52233 chip on it. /Mats _________________________________________________________________ B?rja ett nyttigt liv med v?ra h?lsotips http://e-health.msn.se/ From vika238 at yahoo.com Mon Jan 22 16:27:07 2007 From: vika238 at yahoo.com (vika vika) Date: Mon, 22 Jan 2007 08:27:07 -0800 (PST) Subject: GNU link error with code sourcery Message-ID: <43626.2834.qm@web58811.mail.re1.yahoo.com> Hi , I have done fo;owing steps to install codesourcery elf version 1) Installed in D:\CS 2) Path for D:\CS\bin got set automaticaly 3) My target processor is coldfire 5275 Tried to compile some source code with following options but got these linking errors CF2_CC := m68k-coff-gcc -m5200 -gstabs -I$(All my source code include path) $(All OBJS): %.o: ./path/%.c $(CF2_CC) -c $(my header inclede paths) -Wa,-adhls=$*.ls -o $@ $< gnutest.obj: $(MORE) linkfile.ld $(CF2_CC) -m5200 -Tlinkfile.ld -nostartfiles -o $@ $(All OBJS) makebuf.c:(.text+0xba): undefined reference to `isatty' d:/cs/bin/../lib/gcc/m68k-elf/4.1.1/../../../../m68k-elf/lib\libc.a(sbrkr.o): In function `_sbrk_r': sbrkr.c:(.text+0x10): undefined reference to `sbrk' d:/cs/bin/../lib/gcc/m68k-elf/4.1.1/../../../../m68k-elf/lib\libc.a(writer.o): In function `_write_r ': writer.c:(.text+0x18): undefined reference to `write' d:/cs/bin/../lib/gcc/m68k-elf/4.1.1/../../../../m68k-elf/lib\libc.a(fstatr.o): In function `_fstat_r ': fstatr.c:(.text+0x14): undefined reference to `fstat' d:/cs/bin/../lib/gcc/m68k-elf/4.1.1/../../../../m68k-elf/lib\libc.a(lseekr.o): In function `_lseek_r ': lseekr.c:(.text+0x18): undefined reference to `lseek' d:/cs/bin/../lib/gcc/m68k-elf/4.1.1/../../../../m68k-elf/lib\libc.a(readr.o): In function `_read_r': readr.c:(.text+0x18): undefined reference to `read' collect2: ld returned 1 exit status cs-make: *** [gnutest.obj] Error 1 Please help me Regards, Vika --------------------------------- Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlos at codesourcery.com Mon Jan 22 17:55:13 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Mon, 22 Jan 2007 12:55:13 -0500 Subject: [coldfire-gnu-discuss] GNU link error with code sourcery In-Reply-To: <43626.2834.qm@web58811.mail.re1.yahoo.com> References: <43626.2834.qm@web58811.mail.re1.yahoo.com> Message-ID: <20070122175512.GH18600@lios> On Mon, Jan 22, 2007 at 08:27:07AM -0800, vika vika wrote: > CF2_CC := m68k-coff-gcc -m5200 -gstabs -I$(All my source code include > path) CodeSourcery does not provide "m68k-coff-gcc", if you would would like a Coldfire COFF target please contact sales at codesourcery.com. CodeSourcery provides Coldfire ELF, Coldfire GNU/Linux, and Coldfire uCLibc targets. The missing symbols you are seeing are normally provided by the C library. Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From vika238 at yahoo.com Mon Jan 22 20:03:08 2007 From: vika238 at yahoo.com (vika vika) Date: Mon, 22 Jan 2007 12:03:08 -0800 (PST) Subject: [coldfire-gnu-discuss] GNU link error with code sourcery In-Reply-To: <20070122175512.GH18600@lios> Message-ID: <729943.66798.qm@web58813.mail.re1.yahoo.com> I am sorry it was a typing mistake It should be m68k-elf-gcc My problem is with m68k-elf-gcc only Hi , I have done fo;owing steps to install codesourcery elf version 1) Installed in D:\CS 2) Path for D:\CS\bin got set automaticaly 3) My target processor is coldfire 5275 Tried to compile some source code with following options but got these linking errors CF2_CC := m68k-elf-gcc -m5200 -gstabs -I$(All my source code include path) $(All OBJS): %.o: ./path/%.c $(CF2_CC) -c $(my header inclede paths) -Wa,-adhls=$*.ls -o $@ $< gnutest.obj: $(All OBJS) linkfile.ld $(CF2_CC) -m5200 -Tlinkfile.ld -nostartfiles -o $@ $(All OBJS) makebuf.c:(.text+0xba): undefined reference to `isatty' d:/cs/bin/../lib/gcc/m68k-elf/4.1.1/../../../../m68k-elf/lib\libc.a(sbrkr.o): In function `_sbrk_r': sbrkr.c:(.text+0x10): undefined reference to `sbrk' d:/cs/bin/../lib/gcc/m68k-elf/4.1.1/../../../../m68k-elf/lib\libc.a(writer.o): In function `_write_r ': writer.c:(.text+0x18): undefined reference to `write' d:/cs/bin/../lib/gcc/m68k-elf/4.1.1/../../../../m68k-elf/lib\libc.a(fstatr.o): In function `_fstat_r ': fstatr.c:(.text+0x14): undefined reference to `fstat' d:/cs/bin/../lib/gcc/m68k-elf/4.1.1/../../../../m68k-elf/lib\libc.a(lseekr.o): In function `_lseek_r ': lseekr.c:(.text+0x18): undefined reference to `lseek' d:/cs/bin/../lib/gcc/m68k-elf/4.1.1/../../../../m68k-elf/lib\libc.a(readr.o): In function `_read_r': readr.c:(.text+0x18): undefined reference to `read' collect2: ld returned 1 exit status cs-make: *** [gnutest.obj] Error 1 Please help me Regards, Vika Carlos O'Donell wrote: On Mon, Jan 22, 2007 at 08:27:07AM -0800, vika vika wrote: > CF2_CC := m68k-coff-gcc -m5200 -gstabs -I$(All my source code include > path) CodeSourcery does not provide "m68k-coff-gcc", if you would would like a Coldfire COFF target please contact sales at codesourcery.com. CodeSourcery provides Coldfire ELF, Coldfire GNU/Linux, and Coldfire uCLibc targets. The missing symbols you are seeing are normally provided by the C library. Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 --------------------------------- TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at codesourcery.com Mon Jan 22 20:32:15 2007 From: kazu at codesourcery.com (Kazu Hirata) Date: Mon, 22 Jan 2007 15:32:15 -0500 Subject: [coldfire-gnu-discuss] GNU link error with code sourcery In-Reply-To: <729943.66798.qm@web58813.mail.re1.yahoo.com> References: <729943.66798.qm@web58813.mail.re1.yahoo.com> Message-ID: <45B51F4F.7080109@codesourcery.com> Hi Vika, > CF2_CC := m68k-elf-gcc -m5200 -gstabs -I$(All my source code include > path) > $(All OBJS): %.o: ./path/%.c > $(CF2_CC) -c $(my header inclede paths) -Wa,-adhls=$*.ls -o $@ $< > > gnutest.obj: $(All OBJS) linkfile.ld > $(CF2_CC) -m5200 -Tlinkfile.ld -nostartfiles -o $@ $(All OBJS) > > > > makebuf.c:(.text+0xba): undefined reference to `isatty' > > d:/cs/bin/../lib/gcc/m68k-elf/4.1.1/../../../../m68k-elf/lib\libc.a(sbrkr.o): > In function `_sbrk_r': > sbrkr.c:(.text+0x10): undefined reference to `sbrk' Functions like sbrk, write, and fstat are in libcf.a. You might want to check that linkfile.ld contains: GROUP(-lc -lunhosted -lcf) See D:\CS\m68k-elf/lib/m5208/m5208evb-rom.ld for an example. Regards, Kazu Hirata From carlos at codesourcery.com Mon Jan 22 20:38:02 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Mon, 22 Jan 2007 15:38:02 -0500 Subject: [coldfire-gnu-discuss] GNU link error with code sourcery In-Reply-To: <729943.66798.qm@web58813.mail.re1.yahoo.com> References: <20070122175512.GH18600@lios> <729943.66798.qm@web58813.mail.re1.yahoo.com> Message-ID: <20070122203801.GL18600@lios> On Mon, Jan 22, 2007 at 12:03:08PM -0800, vika vika wrote: > gnutest.obj: $(All OBJS) linkfile.ld > $(CF2_CC) -m5200 -Tlinkfile.ld -nostartfiles -o $@ $(All OBJS) You are using your own linker script "linkfile.ld" and not one of the default scripts provided in Sourcery G++. We recommend you start with a default script, and make the changes you need. You are using Coldfire ELF, which means there is no operating system running on the CPU. Without an operating system you need to rely on the host (Windows or Linux) to help print to the screen. When the host (usually a debugger) helps your program we call this "semi-hosting." If you are not going to use "printf" or don't need semi-hosting functionality, then you can link in "-lunhosted" to resolve your missing symbols. The default Sourcery G++ linker scripts show how to do this. Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From vika238 at yahoo.com Mon Jan 22 23:09:26 2007 From: vika238 at yahoo.com (vika vika) Date: Mon, 22 Jan 2007 15:09:26 -0800 (PST) Subject: [coldfire-gnu-discuss] GNU link error with code sourcery In-Reply-To: <20070122203801.GL18600@lios> Message-ID: <324225.35503.qm@web58813.mail.re1.yahoo.com> Carlos and Kazu Thanks for your help I put dummy functions for that all undefined functions ...I am not using any std. OS so I have implemented malloc (not using sbrk) and printf (serial port ). I will also Ref your linker file. Thank you Vika Carlos O'Donell wrote: On Mon, Jan 22, 2007 at 12:03:08PM -0800, vika vika wrote: > gnutest.obj: $(All OBJS) linkfile.ld > $(CF2_CC) -m5200 -Tlinkfile.ld -nostartfiles -o $@ $(All OBJS) You are using your own linker script "linkfile.ld" and not one of the default scripts provided in Sourcery G++. We recommend you start with a default script, and make the changes you need. You are using Coldfire ELF, which means there is no operating system running on the CPU. Without an operating system you need to rely on the host (Windows or Linux) to help print to the screen. When the host (usually a debugger) helps your program we call this "semi-hosting." If you are not going to use "printf" or don't need semi-hosting functionality, then you can link in "-lunhosted" to resolve your missing symbols. The default Sourcery G++ linker scripts show how to do this. Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 --------------------------------- TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlos at codesourcery.com Tue Jan 23 02:15:16 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Mon, 22 Jan 2007 21:15:16 -0500 Subject: [coldfire-gnu-discuss] GNU link error with code sourcery In-Reply-To: <324225.35503.qm@web58813.mail.re1.yahoo.com> References: <20070122203801.GL18600@lios> <324225.35503.qm@web58813.mail.re1.yahoo.com> Message-ID: <20070123021514.GM18600@lios> On Mon, Jan 22, 2007 at 03:09:26PM -0800, vika vika wrote: > Carlos and Kazu Thanks for your help > > I put dummy functions for that all undefined functions ...I am not using > any std. OS so I have implemented malloc (not using sbrk) and printf > (serial port ). I will also Ref your linker file. > > Thank you > Vika I'm glad we could be of help! Feel free to email the list if you have any other problems. Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From vika238 at yahoo.com Tue Jan 23 22:14:12 2007 From: vika238 at yahoo.com (vika vika) Date: Tue, 23 Jan 2007 14:14:12 -0800 (PST) Subject: [coldfire-gnu-discuss] GNU link error with code sourcery In-Reply-To: <20070123021514.GM18600@lios> Message-ID: <432812.60041.qm@web58805.mail.re1.yahoo.com> Hi All I could compile and link my source code with codesourcery GNU but now I am facing problem with C++ constructor. my program crash at c++ constructor. I am giving my linker file. C program works fine. I am linking my code as follows CF2_CC :=m68k-elf-gcc -fno-builtin -mcpu=5275 -mdiv -gstabs CF2_CCP :=m68k-elf-g++ -fno-builtin -mcpu=5275 -mdiv -gstabs //c++ code $(OBJS_CC): %.o: ./xyz/xyx/%.cpp $(CF2_CCP) -c -Wa,-adhls=$*.ls -o $@ $< //similarly c code //linking all with g++ gnutest.obj: $(C_CPP_OBJ) linkfile.ld $(CF2_CCP) $(LDFLAGS) -Tlinkfile.ld -lgcc -nostartfiles -o $@ $(C_CPP_OBJ) My linker file MEMORY { sdram (RWX) : ORIGIN = 0x00000000, LENGTH = 0x01000000 vector_ram (RWX) : ORIGIN = 0x00000000, LENGTH = 0x00000400 user (RWX) : ORIGIN = 0x00020000, LENGTH = 0x00FE0000 sram (RWX) : ORIGIN = 0x20000000, LENGTH = 0x00010000 ext_sram (RWX) : ORIGIN = 0x30000000, LENGTH = 0x00080000 ipsbar (RWX) : ORIGIN = 0x40000000, LENGTH = 0x40000000 ext_flash (RWX) : ORIGIN = 0xFFE00000, LENGTH = 0x00200000 } SECTIONS { .sdram : {} > sdram .vector_ram : {} > vector_ram .ipsbar : {} > ipsbar .sram : {} > sram .ext_sram : {} > ext_sram .ext_flash : {} > ext_flash .vectors : { vectors.o (.text) } > user .text : { . = ALIGN (0x10); *(.text) . = ALIGN(0x10); __CTOR_LIST__ = .; ___CTOR_LIST__ = .; LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2) *(.ctors) LONG(0) __CTOR_END__ = .; __DTOR_LIST__ = .; ___DTOR_LIST__ = .; LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2) *(.dtors) LONG(0) __DTOR_END__ = .; . = ALIGN (0x10); *(.rodata) } > user .data : { __DATA_ROM = .; __DATA_RAM = .; . = ALIGN (0x10); *(.data) . = ALIGN (0x10); *(.sdata) __DATA_END = .; } > user .bss : { . = ALIGN (0x10); __BSS_START = .; *(.sbss) *(SCOMMON) *(.bss) *(COMMON) __BSS_END = .; } > user .custom : { . = ALIGN (0x10); __HEAP_START = .; . = . + 0x30000; __HEAP_END = .; __SP_END = .; . = . + 0x30000; __SP_INIT = .; } > user __IPSBAR = ADDR(.ipsbar); __VECTOR_RAM = ADDR(.vector_ram); __SDRAM = ADDR(.sdram); __SDRAM_SIZE = 0x01000000; __SRAM = ADDR(.sram); __SRAM_SIZE = 0x00010000; __EXT_SRAM = ADDR(.ext_sram); __EXT_SRAM_SIZE = 0x00080000; __EXT_FLASH = ADDR(.ext_flash); __EXT_FLASH_SIZE = 0x00200000; } Thank you Regards, Vika Carlos O'Donell wrote: On Mon, Jan 22, 2007 at 03:09:26PM -0800, vika vika wrote: > Carlos and Kazu Thanks for your help > > I put dummy functions for that all undefined functions ...I am not using > any std. OS so I have implemented malloc (not using sbrk) and printf > (serial port ). I will also Ref your linker file. > > Thank you > Vika I'm glad we could be of help! Feel free to email the list if you have any other problems. Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 --------------------------------- 8:00? 8:25? 8:40? Find a flick in no time with theYahoo! Search movie showtime shortcut. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at codesourcery.com Tue Jan 23 22:18:21 2007 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Tue, 23 Jan 2007 17:18:21 -0500 Subject: [coldfire-gnu-discuss] GNU link error with code sourcery In-Reply-To: <432812.60041.qm@web58805.mail.re1.yahoo.com> References: <20070123021514.GM18600@lios> <432812.60041.qm@web58805.mail.re1.yahoo.com> Message-ID: <20070123221820.GG6004@caradoc.them.org> On Tue, Jan 23, 2007 at 02:14:12PM -0800, vika vika wrote: > gnutest.obj: $(C_CPP_OBJ) linkfile.ld > $(CF2_CCP) $(LDFLAGS) -Tlinkfile.ld -lgcc -nostartfiles -o $@ $(C_CPP_OBJ) Why are you using -nostartfiles? Things usually won't work right if you do that, because the C and C++ runtimes won't be properly initialized. You can probably remove -lgcc too. Is it because you want to override the initialization code? I think there's another way you're supposed to do that - but I don't know it myself. -- Daniel Jacobowitz CodeSourcery From vika238 at yahoo.com Tue Jan 23 23:28:37 2007 From: vika238 at yahoo.com (vika vika) Date: Tue, 23 Jan 2007 15:28:37 -0800 (PST) Subject: [coldfire-gnu-discuss] GNU link error with code sourcery In-Reply-To: <20070123221820.GG6004@caradoc.them.org> Message-ID: <790752.41659.qm@web58802.mail.re1.yahoo.com> Hi Daniel , -nostartfiles is to avoid startup program was useful in my old GNU compiler That worked..thanks for your valuable suggestion .I could move forward today .. :) Regards, Vika Daniel Jacobowitz wrote: On Tue, Jan 23, 2007 at 02:14:12PM -0800, vika vika wrote: > gnutest.obj: $(C_CPP_OBJ) linkfile.ld > $(CF2_CCP) $(LDFLAGS) -Tlinkfile.ld -lgcc -nostartfiles -o $@ $(C_CPP_OBJ) Why are you using -nostartfiles? Things usually won't work right if you do that, because the C and C++ runtimes won't be properly initialized. You can probably remove -lgcc too. Is it because you want to override the initialization code? I think there's another way you're supposed to do that - but I don't know it myself. -- Daniel Jacobowitz CodeSourcery --------------------------------- Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zwb at xanet.edu.cn Fri Jan 26 08:20:37 2007 From: zwb at xanet.edu.cn (zwb at xanet.edu.cn) Date: Fri, 26 Jan 2007 16:20:37 +0800 Subject: m68k-uclinux-20060615 tool chains error Message-ID: <20070126083108.9F5B511F80F@lax-gw07.mroute.net> When I compiled a uclinux kernel of 2.6.19-uc0 for a coldfire with gcc version 4.1.1 (m68k-uclinux-20060615), I got the following compiler faults: ...... m68k-uclinux-gcc -Wp,-MD,fs/proc/.proc_misc.o.d -nostdinc -isystem /usr/local/lib/gcc/m68k-uclinux/4.1.1/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -m5200 -D__linux__ -DUTS_SYSNAME=\"uClinux\" -fomit-frame-pointer -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(proc_misc)" -D"KBUILD_MODNAME=KBUILD_STR(proc)" -c -o fs/proc/.tmp_proc_misc.o fs/proc/proc_misc.c fs/proc/proc_misc.c: In function 'show_stat': fs/proc/proc_misc.c:531: internal compiler error: in find_reloads_address_1, at reload.c:5577 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make[2]: *** [fs/proc/proc_misc.o] Error 1 make[1]: *** [fs/proc] Error 2 make: *** [fs] Error 2 The proprocessed source is gziped and attached. ????????Zheng Weibin ????????zwb at mail.xanet.edu.cn ??????????2007-01-26 -------------- next part -------------- A non-text attachment was scrubbed... Name: proc_misc.i.gz Type: application/octet-stream Size: 78036 bytes Desc: not available URL: From nathan at codesourcery.com Fri Jan 26 10:11:09 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Fri, 26 Jan 2007 10:11:09 +0000 Subject: [coldfire-gnu-discuss] m68k-uclinux-20060615 tool chains error In-Reply-To: <20070126083108.9F5B511F80F@lax-gw07.mroute.net> References: <20070126083108.9F5B511F80F@lax-gw07.mroute.net> Message-ID: <45B9D3BD.8090701@codesourcery.com> zwb at xanet.edu.cn wrote: > When I compiled a uclinux kernel of 2.6.19-uc0 for a coldfire > with gcc version 4.1.1 (m68k-uclinux-20060615), I got the > following compiler faults: Where did this compiler come from? I do not recognize the version identification as a CodeSourcery toolchain. CodeSourcery produce toolchains identify themselves as something like gcc version 4.1.0 (CodeSourcery Freescale 4.1-14) > m68k-uclinux-gcc -Wp,-MD,fs/proc/.proc_misc.o.d -nostdinc -isystem /usr/local/lib/gcc/m68k-uclinux/4.1.1/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -m5200 -D__linux__ -DUTS_SYSNAME=\"uClinux\" -fomit-frame-pointer -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(proc_misc)" -D"KBUILD_MODNAME=KBUILD_STR(proc)" -c -o fs/proc/.tmp_proc_misc.o fs/proc/proc_misc.c > fs/proc/proc_misc.c: In function 'show_stat': > fs/proc/proc_misc.c:531: internal compiler error: in find_reloads_address_1, at reload.c:5577 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > make[2]: *** [fs/proc/proc_misc.o] Error 1 > make[1]: *** [fs/proc] Error 2 Neither our current release nor the 4.1-14 release (which is the closest CSL release to the 20060615 date you give) crash.1 nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From vika238 at yahoo.com Mon Jan 29 15:03:31 2007 From: vika238 at yahoo.com (vika vika) Date: Mon, 29 Jan 2007 07:03:31 -0800 (PST) Subject: Licensing policy for Codesourcery In-Reply-To: <20070123021514.GM18600@lios> Message-ID: <311988.4890.qm@web58801.mail.re1.yahoo.com> Hi All, Can some brief me licensing policy of coldfire GNU tool which is freely downloadable. (command line version) ? I want to take decision for using it in company. Regards, Vika --------------------------------- Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at codesourcery.com Mon Jan 29 15:50:01 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Mon, 29 Jan 2007 15:50:01 +0000 Subject: [coldfire-gnu-discuss] Licensing policy for Codesourcery In-Reply-To: <311988.4890.qm@web58801.mail.re1.yahoo.com> References: <311988.4890.qm@web58801.mail.re1.yahoo.com> Message-ID: <45BE17A9.7080301@codesourcery.com> vika vika wrote: > Hi All, > Can some brief me licensing policy of coldfire GNU tool which is freely > downloadable. (command line version) ? > I want to take decision for using it in company. The license conditions are in the LICENSE.txt file under share/docs/freescale-coldfire-4.1-32-m68k-elf. If you want to use a toolchain for development you may want to consider one of the Sourcery G++ subscriptions, as that will provide you with support, bug fixes and updates. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From mark at codesourcery.com Mon Jan 29 16:56:36 2007 From: mark at codesourcery.com (Mark Mitchell) Date: Mon, 29 Jan 2007 08:56:36 -0800 Subject: [coldfire-gnu-discuss] Licensing policy for Codesourcery In-Reply-To: <311988.4890.qm@web58801.mail.re1.yahoo.com> References: <311988.4890.qm@web58801.mail.re1.yahoo.com> Message-ID: <45BE2744.2010904@codesourcery.com> vika vika wrote: > Can some brief me licensing policy of coldfire GNU tool which is freely > downloadable. (command line version) ? > I want to take decision for using it in company. Sourcery G++ Lite Edition (the no-cost version of Sourcery G++ available for download from our web site, which includes only command-line tools) comes with a Getting Started Guide which talks about the various licenses that apply. Most of the programs are available under the terms of the GPL. Most of the libraries are either LGPL, BSD, or something similar. You can use Sourcery G++ to build proprietary programs and there is no cost for using Sourcery G++ Lite Edition. -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From vika238 at yahoo.com Mon Jan 29 17:00:12 2007 From: vika238 at yahoo.com (vika vika) Date: Mon, 29 Jan 2007 09:00:12 -0800 (PST) Subject: [coldfire-gnu-discuss] Licensing policy for Codesourcery In-Reply-To: <45BE17A9.7080301@codesourcery.com> Message-ID: <193596.84929.qm@web58803.mail.re1.yahoo.com> I have gone through Sourcery G++ Lite License. I installed exe named "freescale-coldfire-4.1.32-m68-elf.exe " I want to use components which are mentioned as GNU GPL License and Newlib 1) GNU compiler collection 2) GNU Binary Utilities 3) GNU MAKE 4) NewLIB C Library (Newlib License) I want to conform that when I install exe as mentioned above I am not installing any thing which do not have GNU GPL or Newlib License. Please Help me to undertand the containt of tool and licensing policy. Regards, Vika Nathan Sidwell wrote: vika vika wrote: > Hi All, > Can some brief me licensing policy of coldfire GNU tool which is freely > downloadable. (command line version) ? > I want to take decision for using it in company. The license conditions are in the LICENSE.txt file under share/docs/freescale-coldfire-4.1-32-m68k-elf. If you want to use a toolchain for development you may want to consider one of the Sourcery G++ subscriptions, as that will provide you with support, bug fixes and updates. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk --------------------------------- Want to start your own business? Learn how on Yahoo! Small Business. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at codesourcery.com Mon Jan 29 17:03:53 2007 From: mark at codesourcery.com (Mark Mitchell) Date: Mon, 29 Jan 2007 09:03:53 -0800 Subject: [coldfire-gnu-discuss] Licensing policy for Codesourcery In-Reply-To: <193596.84929.qm@web58803.mail.re1.yahoo.com> References: <193596.84929.qm@web58803.mail.re1.yahoo.com> Message-ID: <45BE28F9.4070407@codesourcery.com> vika vika wrote: > I have gone through Sourcery G++ Lite License. > > I installed exe named "freescale-coldfire-4.1.32-m68-elf.exe " > > I want to use components which are mentioned as GNU GPL License and Newlib > 1) GNU compiler collection > 2) GNU Binary Utilities > 3) GNU MAKE > 4) NewLIB C Library (Newlib License) > > I want to conform that when I install exe as mentioned above I am not > installing any thing which do not have GNU GPL or Newlib License. The package contains some components which are under other licenses. In particular, the Sourcery G++ Debug Sprites are CodeSourcery proprietary code, and some of the documentation provided, as well as the installer itself, are CodeSourcery proprietary. You have to read the Getting Started for full details. -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From haluongvn at gmail.com Tue Jan 30 03:59:15 2007 From: haluongvn at gmail.com (Ha Luong) Date: Tue, 30 Jan 2007 10:59:15 +0700 Subject: Problem with -mhard-float Message-ID: <61577c8f0701291959u4f6413d5o2c4889b6b3e4485c@mail.gmail.com> Dear Sir, I use -mhard-float as follow $ m68k-elf-gcc -c -mcpu=5282 -mhard-float -O3 -DMCF5282_BOARD -DNDEBUG -DAUTOGO=TRUE -I. -I../th/gcc_cf/al -I../th/src -o gcc_cf/obj/anytoi.o ../th/src/anytoi.c and I got the error : C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s: Assembler messages: C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:859: Error: scale factor invalid on this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a2,%a0 .l*8),%a0' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:870: Error: scale factor invalid on this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a2,%a0 .l*8),%a0' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:881: Error: scale factor invalid on this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a2,%a0 .l*8),%a0' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:892: Error: scale factor invalid on this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a2,%a0 .l*8),%a0' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:903: Error: scale factor invalid on this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a2,%a0 .l*8),%a0' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:914: Error: scale factor invalid on this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a2,%a0 .l*8),%a0' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:925: Error: scale factor invalid on this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a2,%a0 .l*8),%a0' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:936: Error: scale factor invalid on this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a2,%a0 .l*8),%a0' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:947: Error: scale factor invalid on this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a2,%a0 .l*8),%a0' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:957: Error: scale factor invalid on this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a1,%a0 .l*8),%a0' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:2018: Error: scale factor invalid o n this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a1,%d 1.l*8),%a1' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:2030: Error: scale factor invalid o n this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a3,%a 1.l*8),%a3' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:2042: Error: scale factor invalid o n this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a4,%a 3.l*8),%a4' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:2054: Error: scale factor invalid o n this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a1,%a 4.l*8),%a1' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:2066: Error: scale factor invalid o n this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a3,%a 1.l*8),%a3' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:2078: Error: scale factor invalid o n this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a4,%a 3.l*8),%a4' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:2090: Error: scale factor invalid o n this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a1,%a 4.l*8),%a1' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:2103: Error: scale factor invalid o n this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a1,%d 1.l*8),%a1' ignored C:\DOCUME~1\haluong\LOCALS~1\Temp/ccuYaaaa.s:2114: Error: scale factor invalid o n this architecture; needs cpu32 or 68020 or higher -- statement `lea -48(%a3,%a 1.l*8),%a3' ignored I wonder I could use floating point hard option in Coldfire 5282 or not ? Thanks Ha Luong -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at codesourcery.com Tue Jan 30 09:59:37 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Tue, 30 Jan 2007 09:59:37 +0000 Subject: [coldfire-gnu-discuss] Problem with -mhard-float In-Reply-To: <61577c8f0701291959u4f6413d5o2c4889b6b3e4485c@mail.gmail.com> References: <61577c8f0701291959u4f6413d5o2c4889b6b3e4485c@mail.gmail.com> Message-ID: <45BF1709.3070005@codesourcery.com> Ha Luong wrote: > Dear Sir, > I use -mhard-float as follow > $ m68k-elf-gcc -c -mcpu=5282 -mhard-float -O3 -DMCF5282_BOARD > -DNDEBUG -DAUTOGO=TRUE -I. -I../th/gcc_cf/al -I../th/src -o > gcc_cf/obj/anytoi.o ../th/src/anytoi.c > and I got the error : The 5282 cpu has no floating point unit. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From okalex at gmail.com Wed Jan 31 21:12:28 2007 From: okalex at gmail.com (Alex Parkinson) Date: Wed, 31 Jan 2007 16:12:28 -0500 Subject: M52233DEMO and GDB Message-ID: <1ec5776b0701311312x5baa21bic4f531b8eff93c40@mail.gmail.com> Hi all, I'm trying to debug a simple "Hello, World!" program using GDB and the P&E USB MultiLink BDM located on the M52233DEMO board. I've compiled the program and run GDB as shown below, but I'm unable to connect to the BDM properly. The drivers seem to be installed properly, but I keep getting an error stating "Cannot find a matching debug device". I'm not sure if this is due to the fact that I'm specifying the M52235EVB, despite the fact that I'm actually using the M52233DEMO, or if there's a different problem. I'm pretty new to all of this, so any guidance (or even some info on where I can learn this on my own) would be greatly appreciated. Thanks, Alex Parkinson C:\Work\Personal\Coldfire\Hello>m68k-elf-gcc -mcpu=52235 -o hello -T m52235evb-ram-hosted.ld hello.c C:\Work\Personal\Coldfire\Hello>m68k-elf-gdb hello GNU gdb (Sourcery G++ Lite 4.1-32) 6.6.50.20061124-cvs Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-mingw32 --target=m68k-elf". For bug reporting instructions, please see: . .. (no debugging symbols found) (gdb) target remote | m68k-elf-sprite pe: m52235evb Remote debugging using | m68k-elf-sprite pe: m52235evb m68k-elf-sprite:error:Cannot find a matching debug device Remote communication error: No error. (gdb) target remote | m68k-elf-sprite pe: m52233demo A program is being debugged already. Kill it? (y or n) y Remote communication error: No error. Remote debugging using | m68k-elf-sprite pe: m52233demo m68k-elf-sprite:error:Cannot find a matching debug device Remote communication error: No error. (gdb) -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlos at codesourcery.com Wed Jan 31 21:20:03 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Wed, 31 Jan 2007 16:20:03 -0500 Subject: [coldfire-gnu-discuss] M52233DEMO and GDB In-Reply-To: <1ec5776b0701311312x5baa21bic4f531b8eff93c40@mail.gmail.com> References: <1ec5776b0701311312x5baa21bic4f531b8eff93c40@mail.gmail.com> Message-ID: <20070131212002.GD22964@lios> On Wed, Jan 31, 2007 at 04:12:28PM -0500, Alex Parkinson wrote: > I'm trying to debug a simple "Hello, World!" program using GDB and the P&E > USB MultiLink BDM located on the M52233DEMO board. I've compiled the > program and run GDB as shown below, but I'm unable to connect to the BDM > properly. The drivers seem to be installed properly, but I keep getting > an error stating "Cannot find a matching debug device". I'm not sure if > this is due to the fact that I'm specifying the M52235EVB, despite the > fact that I'm actually using the M52233DEMO, or if there's a different > problem. I'm pretty new to all of this, so any guidance (or even some > info on where I can learn this on my own) would be greatly appreciated. The "Getting Started" guide has a section on "Connection Problems". --- The message "Cannot find a matching debug devic"e means that no P&E device could be found matching the device-url that you used. Use the -i to enumerate the devices available. --- Could you provide use with the output of running the sprite with only the "-i" option? e.g. m68k-elf-sprite -i Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From carlos at codesourcery.com Wed Jan 31 22:06:54 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Wed, 31 Jan 2007 17:06:54 -0500 Subject: [coldfire-gnu-discuss] M52233DEMO and GDB In-Reply-To: <1ec5776b0701311342m7426f71dtc694e8d7ec1852f6@mail.gmail.com> References: <1ec5776b0701311312x5baa21bic4f531b8eff93c40@mail.gmail.com> <20070131212002.GD22964@lios> <1ec5776b0701311342m7426f71dtc694e8d7ec1852f6@mail.gmail.com> Message-ID: <20070131220654.GF22964@lios> On Wed, Jan 31, 2007 at 04:42:06PM -0500, Alex Parkinson wrote: > Thanks for the quick response. Using -i shows that the board is listed as > m52230demo. When I enumerate the device in gdb, I no longer get the > "Cannot find a matching debug device" error, but I still get a statement > that says "Remote communication error: no error". Am I doing this > properly? Please read Chapter 3 of the Getting Started guide. If you find anything is missing please contact the list. Two things to note: > C:\Work\Personal\Coldfire\Hello>m68k-elf-sprite -i > CodeSourcery ColdFire Debug Sprite (Sourcery G++ Lite 4.1-32) > ccs: [timeout=&speed=] CCS Adaptor > ccs://$Host:$Port/$Chainpos - CCS address > pe: [speed=&memory-timeout=] P&E Adaptor > pe://USBMultilink/PE6011570 - USB1 : USB-ML-CF REF : M52230DEMO > (PE6011570) The device URL is "pe://USBMultilink/PE6011570" > C:\Work\Personal\Coldfire\Hello>m68k-elf-gdb hello > GNU gdb (Sourcery G++ Lite 4.1-32) 6.6.50.20061124-cvs > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "--host=i686-mingw32 --target=m68k-elf". > For bug reporting instructions, please see: > . > .. > (no debugging symbols found) > (gdb) target remote | m68k-elf-sprite -i pe: m52230demo > Remote debugging using | m68k-elf-sprite -i pe: m52230demo You should use: "target remote | m68k-elf-sprite pe://USBMultilink/PE6011570 " Chapter 3 in our Getting Started guide covers this usage in detail. Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716