From nathan at codesourcery.com Thu Mar 1 15:43:50 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Thu, 01 Mar 2007 15:43:50 +0000 Subject: [coldfire-gnu-discuss] M52235EVB - Problem using malloc - Access Error Attempted Write to Write-Protected Space In-Reply-To: <200702281354.l1SDs1w5018519@mail33.syd.optusnet.com.au> References: <200702281354.l1SDs1w5018519@mail33.syd.optusnet.com.au> Message-ID: <45E6F4B6.3080409@codesourcery.com> Daniel McLean wrote: > Thanks for the quick response Nathan.. > > What test would you like in terms of a test case? I've tried a simple program: int main () { printf ("boo\n"); malloc (5); printf ("ya\n"); return 0; } and it works fine for me from ROM on a 5208 board. I didn't have a 52235 board I could run this on. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From levailla at enseirb.fr Fri Mar 2 14:08:44 2007 From: levailla at enseirb.fr (LE VAILLANT Guillaume) Date: Fri, 02 Mar 2007 15:08:44 +0100 Subject: [coldfire-gnu-discuss] Problem with -m5307 Message-ID: <20070302150844.fs85kc9ysc0skc04@www.enseirb.fr> Hi, I'm trying to add linphone to uClinux for coldfire (without video and without the gnome interface). I'm using the m68k-uclinux-gcc (Sourcery G++ Lite 4.1-32) 4.1.1 toolchain. Everything seems to go well (compilation of kernel, uClibc, ncurses, readline, osip2, ortp...) until I try to compile exosip (which is included in the linphone sources). Here is the error I get : ucfront-gcc m68k-uclinux-gcc -m5307 -DCONFIG_COLDFIRE -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/usr/include -DHAVE_PTHREAD -DOSIP_MT -DENABLE_TRACE -DNEW_TIMER -DSM -DMSN_SUPPORT -DUSE_TMP_BUFFER -Os -g -fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall -DEMBED -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -fno-strict-aliasing -MT eXosip.lo -MD -MP -MF .deps/eXosip.Tpo -c eXosip.c -o eXosip.o {standard input}: Assembler messages: {standard input}:10330: Error: invalid instruction for this architecture; needs 68000 or higher (68000 [68ec000, 68hc000, 68hc001, 68008, 68302, 68306, 68307, 68322, 68356], 68010, 68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060], cpu32 [68330, 68331, 68332, 68333, 68334, 68336, 68340, 68341, 68349, 68360]) -- statement `rorw $8,%d0' ignored {standard input}:10388: Error: invalid instruction for this architecture; needs 68000 or higher (68000 [68ec000, 68hc000, 68hc001, 68008, 68302, 68306, 68307, 68322, 68356], 68010, 68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060], cpu32 [68330, 68331, 68332, 68333, 68334, 68336, 68340, 68341, 68349, 68360]) -- statement `rorw $8,%d0' ignored make[6]: *** [eXosip.lo] Erreur 1 make[6]: Leaving directory `/home/glv/Coldfire/uClinux-dist/user/linphone/linphone-1.6.0/exosip' So it seems the assembler doesn't recognize the architecture (5307). Then I tried to add "-Wa,-m5307" to the compilation line, and this time I got another error : if /bin/sh ../libtool --tag=CC --mode=compile ucfront-gcc m68k-uclinux-gcc -m5307 -DCONFIG_COLDFIRE -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/usr/include -DHAVE_PTHREAD -DOSIP_MT -DENABLE_TRACE -DNEW_TIMER -DSM -DMSN_SUPPORT -DUSE_TMP_BUFFER -Wa,-m5307 -fno-strict-aliasing -MT udp.lo -MD -MP -MF ".deps/udp.Tpo" -c -o udp.lo udp.c; \ then mv -f ".deps/udp.Tpo" ".deps/udp.Plo"; else rm -f ".deps/udp.Tpo"; exit 1; fi ucfront-gcc m68k-uclinux-gcc -m5307 -DCONFIG_COLDFIRE -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/usr/include -DHAVE_PTHREAD -DOSIP_MT -DENABLE_TRACE -DNEW_TIMER -DSM -DMSN_SUPPORT -DUSE_TMP_BUFFER -Wa,-m5307 -fno-strict-aliasing -MT udp.lo -MD -MP -MF .deps/udp.Tpo -c udp.c -o udp.o udp.c: In function 'eXosip_read_message': udp.c:2153: error: impossible constraint in 'asm' udp.c:2175: error: impossible constraint in 'asm' udp.c:2189: error: impossible constraint in 'asm' make[6]: *** [udp.lo] Erreur 1 make[6]: Leaving directory `/home/glv/Coldfire/uClinux-dist/user/linphone/linphone-1.6.0/exosip' So I tried to see if something looked wrong with these lines (2153, 2175, 2189), but there are only calls to FD_SET() or FD_ISSET(). There are many of these calls in the code and they don't seem to generate errors... Therefore, if someone knows where the problem may come from, please help me... Guillaume LE VAILLANT ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From nathan at codesourcery.com Fri Mar 2 14:30:56 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Fri, 02 Mar 2007 14:30:56 +0000 Subject: [coldfire-gnu-discuss] Problem with -m5307 In-Reply-To: <20070302150844.fs85kc9ysc0skc04@www.enseirb.fr> References: <20070302150844.fs85kc9ysc0skc04@www.enseirb.fr> Message-ID: <45E83520.6060805@codesourcery.com> LE VAILLANT Guillaume wrote: > Hi, > {standard input}: Assembler messages: > {standard input}:10330: Error: invalid instruction for this > architecture; needs 68000 or higher (68000 [68ec000, 68hc000, 68hc001, > 68008, 68302, 68306, 68307, 68322, 68356], 68010, 68020 [68k, 68ec020], > 68030 [68ec030], 68040 [68ec040], 68060 [68ec060], cpu32 [68330, 68331, > 68332, 68333, 68334, 68336, 68340, 68341, 68349, 68360]) -- statement > `rorw $8,%d0' ignored > {standard input}:10388: Error: invalid instruction for this > architecture; needs 68000 or higher (68000 [68ec000, 68hc000, 68hc001, > 68008, 68302, 68306, 68307, 68322, 68356], 68010, 68020 [68k, 68ec020], > 68030 [68ec030], 68040 [68ec040], 68060 [68ec060], cpu32 [68330, 68331, > 68332, 68333, 68334, 68336, 68340, 68341, 68349, 68360]) -- statement > `rorw $8,%d0' ignored These are messages that the rorw $8,%d0 instruction is not supported on the m5307 cpu. The 5307 is an ISA A cpu. No coldfire ISA has a rotate instruction. I'm guessing this is coming from an assembly insert -- if it isn't then it's a compiler bug. To investigate further a testcase will be needed. > udp.c: In function 'eXosip_read_message': > udp.c:2153: error: impossible constraint in 'asm' > udp.c:2175: error: impossible constraint in 'asm' > udp.c:2189: error: impossible constraint in 'asm' > make[6]: *** [udp.lo] Erreur 1 > make[6]: Leaving directory > `/home/glv/Coldfire/uClinux-dist/user/linphone/linphone-1.6.0/exosip' > > So I tried to see if something looked wrong with these lines (2153, > 2175, 2189), but there are only calls to FD_SET() or FD_ISSET(). There > are many of these calls in the code and they don't seem to generate > errors... Those must be being implemented as macros containing an erroneous assembly insert. to help further we're going to need *) preprocessed source code (you can get this by adding -save-temps to the compile line) *) the exact command lines you're using to invoke the compiler (you're driving the compiler via ucfront-gcc. We need the command given to m68k-uclinux-gcc. If you're unsure how to get that then add -v to the compile line, and include the messages you get). nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From dan at codesourcery.com Fri Mar 2 14:33:50 2007 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Fri, 2 Mar 2007 09:33:50 -0500 Subject: [coldfire-gnu-discuss] Problem with -m5307 In-Reply-To: <45E83520.6060805@codesourcery.com> References: <20070302150844.fs85kc9ysc0skc04@www.enseirb.fr> <45E83520.6060805@codesourcery.com> Message-ID: <20070302143347.GO17380@caradoc.them.org> On Fri, Mar 02, 2007 at 02:30:56PM +0000, Nathan Sidwell wrote: > to help further we're going to need Actually, I know this one! There was a -I/usr/include in the posted command line. Find whatever is adding that, and make it stop. You're getting an i686 assembly version of FD_ISSET from your host. -- Daniel Jacobowitz CodeSourcery From levailla at enseirb.fr Fri Mar 2 14:47:28 2007 From: levailla at enseirb.fr (LE VAILLANT Guillaume) Date: Fri, 02 Mar 2007 15:47:28 +0100 Subject: [coldfire-gnu-discuss] Problem with -m5307 In-Reply-To: <20070302143347.GO17380@caradoc.them.org> References: <20070302150844.fs85kc9ysc0skc04@www.enseirb.fr> <45E83520.6060805@codesourcery.com> <20070302143347.GO17380@caradoc.them.org> Message-ID: <20070302154728.fk8oablusws88cks@www.enseirb.fr> Quoting Daniel Jacobowitz : > On Fri, Mar 02, 2007 at 02:30:56PM +0000, Nathan Sidwell wrote: >> to help further we're going to need > > Actually, I know this one! > > There was a -I/usr/include in the posted command line. Find whatever > is adding that, and make it stop. You're getting an i686 assembly > version of FD_ISSET from your host. > > -- > Daniel Jacobowitz > CodeSourcery > I removed the -I/usr/include and now it compiles perfectly well. Thanks a lot for your help ! This bad include option seems to come from the configure script of exosip, and indeed it creates conflicts between headers. Thanks again and have a nice day. Guillaume LE VAILLANT ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From update at yourfreemortgageguide.com Sat Mar 3 03:38:42 2007 From: update at yourfreemortgageguide.com (FreeMortgageGuide) Date: Sat, 03 Mar 2007 03:38:42 Subject: " Is now a good time to review your mortgage deal ? " for coldfire-gnu-discuss@codesourcery.com on Sat, 03 Mar 2007 03:38:42 Message-ID: <20070303033842.17549.qmail@yourfreemortgageguide.com> Dear Business Professional, We would like to introduce a brand new web site designed especially for busy business professionals; www.YourFreeMortgageGuide.com YourFreeMortgageGuide.com provides access to a national alliance of mortgage advisers throughout the UK who are all professionally qualified to help you choose the right mortgage or re-mortgage for you. If you would like to speak to a qualified mortgage adviser, free of charge and with no obligation, please go to www.YourFreeMortgageGuide.com and complete a short on-line form. Kind regards, The YourFreeMortgageGuide.com team PS With over 8,000 mortgage deals available, it pays to talk to an expert. To stop receiving these mailings go to http://www.YourFreeMortgageGuide.com/emailcancel.htm?email=coldfire-gnu-discuss at codesourcery.com C Copyright YourFreeMortgageGuide.com. 2007. All rights reserved -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.mclean at optusnet.com.au Mon Mar 5 04:52:27 2007 From: daniel.mclean at optusnet.com.au (Daniel McLean) Date: Mon, 5 Mar 2007 14:52:27 +1000 Subject: [coldfire-gnu-discuss] M52235EVB - Problem using malloc - Access Error Attempted Write to Write-Protected Space In-Reply-To: <45E6F4B6.3080409@codesourcery.com> Message-ID: <200703050452.l254qbjD009389@mail33.syd.optusnet.com.au> Nathan, I've tried your test case and I still get the access exception. I've disassembled the malloc_r object file from libc, and by comparing this output to the newlib source code (downloaded from CodeSourcery) it seems like malloc_r is incorrectly accessing memory quite early in the piece. 0x11E from the start of malloc_r (in the disassembly). It would seem that this is right at the start of the bin selection logic for malloc_r. Being that malloc is a fairly tried and tested routine, I'm beginning to think that the problem may be caused by my build setup whether it is the libraries I have been using or the compiler options or similar. Just to make sure that my C runtime init is performed correctly, I've written test code that checks that the .bss section is zeroed out properly and that the .data section is correctly copied from ROM to RAM, and this seems fine. I guess it is worth asking exactly what libraries I should be linking against? There are some libraries in CodeSourcery/m68k-elf/lib and then there are libraries underneath certain folders: eg. m5208, m5213, etc. As the 52235 isn't explicitly listed, does it matter which libraries I link against? I've tried the ones in CodeSourcery/m68k-elf/lib and CodeSourcery/m68k-elf/lib/m5213 with no success. As newlib has been compiled with re-entrancy support is anything required to be setup or otherwise exported form the linker file for malloc to work correctly? It seems like malloc is not even progressing far enough through to call sbrk, and I've tried both my own version and the one in libcf and it makes not difference. One other thing I did notice is that the av variable used to track the bin allocation by malloc is originally empty.. Is this expected? Any help you could provide would be much appreciated... Thanks Daniel -----Original Message----- From: Nathan Sidwell [mailto:nathan at codesourcery.com] Sent: Friday, 2 March 2007 1:44 AM To: Daniel McLean Cc: coldfire-gnu-discuss at codesourcery.com Subject: Re: [coldfire-gnu-discuss] M52235EVB - Problem using malloc - Access Error Attempted Write to Write-Protected Space Daniel McLean wrote: > Thanks for the quick response Nathan.. > > What test would you like in terms of a test case? I've tried a simple program: int main () { printf ("boo\n"); malloc (5); printf ("ya\n"); return 0; } and it works fine for me from ROM on a 5208 board. I didn't have a 52235 board I could run this on. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.5/707 - Release Date: 1/03/2007 2:43 PM From nathan at codesourcery.com Mon Mar 5 11:08:28 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Mon, 05 Mar 2007 11:08:28 +0000 Subject: [coldfire-gnu-discuss] M52235EVB - Problem using malloc - Access Error Attempted Write to Write-Protected Space In-Reply-To: <200703050452.l254qbjD009389@mail33.syd.optusnet.com.au> References: <200703050452.l254qbjD009389@mail33.syd.optusnet.com.au> Message-ID: <45EBFA2C.9080308@codesourcery.com> Daniel McLean wrote: > I've disassembled the malloc_r object file from libc, and by comparing this > output to the newlib source code (downloaded from CodeSourcery) it seems > like malloc_r is incorrectly accessing memory quite early in the piece. > 0x11E from the start of malloc_r (in the disassembly). It would seem that > this is right at the start of the bin selection logic for malloc_r. This suggests to me that the data segment is not being correctly initialized -- how have you verified that? > Just to make sure that my C runtime init is performed correctly, I've > written test code that checks that the .bss section is zeroed out properly > and that the .data section is correctly copied from ROM to RAM, and this > seems fine. Have you checked that this program: static int j = 5; int main () { return 0; } ... has the expected value in j when you're in main? > I guess it is worth asking exactly what libraries I should be linking > against? There are some libraries in CodeSourcery/m68k-elf/lib and then > there are libraries underneath certain folders: eg. m5208, m5213, etc. As > the 52235 isn't explicitly listed, does it matter which libraries I link > against? I've tried the ones in CodeSourcery/m68k-elf/lib and > CodeSourcery/m68k-elf/lib/m5213 with no success. These different libraries are known as multilibs. Each directory is tuned for a different set of coldfire cores and is selected automatically by the compiler. All you need to provide is the -mcpu=52235 option, and it will map it onto the right set. You can use the -v option to see exactly what is passed to the linker. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From daniel.mclean at optusnet.com.au Mon Mar 5 12:51:14 2007 From: daniel.mclean at optusnet.com.au (Daniel McLean) Date: Mon, 5 Mar 2007 22:51:14 +1000 Subject: [coldfire-gnu-discuss] M52235EVB - Problem using malloc - Access Error Attempted Write to Write-Protected Space In-Reply-To: <45EBFA2C.9080308@codesourcery.com> Message-ID: <200703051251.l25CpM7j008150@mail21.syd.optusnet.com.au> Hi Nathan, Thanks for you help. You were correct in being suspicious of my data initialisation. I had an offset problem in my linker control file that was causing the data and BSS sections to be 1k further along in memory than they should have been. (My mistake as I'd marked the vector RAM table as NOLOAD) The reason I didn't pick this earlier was because my comparison routines used the markers in the linker control file that I had exported which were in the addresses that were 1k further along. Again, your help was greatly appreciated. Thanks Daniel -----Original Message----- From: Nathan Sidwell [mailto:nathan at codesourcery.com] Sent: Monday, 5 March 2007 9:08 PM To: Daniel McLean Cc: coldfire-gnu-discuss at codesourcery.com Subject: Re: [coldfire-gnu-discuss] M52235EVB - Problem using malloc - Access Error Attempted Write to Write-Protected Space Daniel McLean wrote: > I've disassembled the malloc_r object file from libc, and by comparing this > output to the newlib source code (downloaded from CodeSourcery) it seems > like malloc_r is incorrectly accessing memory quite early in the piece. > 0x11E from the start of malloc_r (in the disassembly). It would seem that > this is right at the start of the bin selection logic for malloc_r. This suggests to me that the data segment is not being correctly initialized -- how have you verified that? > Just to make sure that my C runtime init is performed correctly, I've > written test code that checks that the .bss section is zeroed out properly > and that the .data section is correctly copied from ROM to RAM, and this > seems fine. Have you checked that this program: static int j = 5; int main () { return 0; } ... has the expected value in j when you're in main? > I guess it is worth asking exactly what libraries I should be linking > against? There are some libraries in CodeSourcery/m68k-elf/lib and then > there are libraries underneath certain folders: eg. m5208, m5213, etc. As > the 52235 isn't explicitly listed, does it matter which libraries I link > against? I've tried the ones in CodeSourcery/m68k-elf/lib and > CodeSourcery/m68k-elf/lib/m5213 with no success. These different libraries are known as multilibs. Each directory is tuned for a different set of coldfire cores and is selected automatically by the compiler. All you need to provide is the -mcpu=52235 option, and it will map it onto the right set. You can use the -v option to see exactly what is passed to the linker. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.7/710 - Release Date: 4/03/2007 1:58 PM From nathan at codesourcery.com Mon Mar 5 12:58:19 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Mon, 05 Mar 2007 12:58:19 +0000 Subject: [coldfire-gnu-discuss] M52235EVB - Problem using malloc - Access Error Attempted Write to Write-Protected Space In-Reply-To: <200703051251.l25CpM7j008150@mail21.syd.optusnet.com.au> References: <200703051251.l25CpM7j008150@mail21.syd.optusnet.com.au> Message-ID: <45EC13EB.6060305@codesourcery.com> Daniel , > Thanks for you help. You were correct in being suspicious of my data > initialisation. I had an offset problem in my linker control file that was > causing the data and BSS sections to be 1k further along in memory than they > should have been. (My mistake as I'd marked the vector RAM table as NOLOAD) glad you've found the problem. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From elbenard at gmail.com Wed Mar 7 16:58:02 2007 From: elbenard at gmail.com (Eric BENARD) Date: Wed, 07 Mar 2007 17:58:02 +0100 Subject: [coldfire-gnu-discuss] gcc-4.1-30 & SRAM In-Reply-To: <45AFB76F.6010008@gmail.com> References: <45AF98A1.8040903@gmail.com> <45AFB3D8.3050204@codesourcery.com> <45AFB76F.6010008@gmail.com> Message-ID: <45EEEF1A.3060303@gmail.com> Eric BENARD wrote: > Nathan Sidwell wrote : >> 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. here is the dirty way I found : m68k-uclinux-gcc -DHAVE_CONFIG_H -I. -Iinclude $CFLAGS -o $i $LIBOGGSRC_O $LIBSRC_O $APPSOBJ_O $i.o -lc -lm m68k-uclinux-objcopy --output-target binary -j .sramcode $i.gdb $i.bin Function to put in SRAM are prefixed with : __attribute__((__section__(".sramcode"))) Then I have a small app which loads app.bin at the right address in SRAM. And then it's possible to execute the app, after comenting out the address validity check in linux/fs/binfmt_flat.c : if (!flat_reloc_valid(r, start_brk - start_data + text_len)) { /* printk("BINFMT_FLAT: reloc outside program 0x%x (0 - 0x%x/0x%x)", (int) r,(int)(start_brk-start_code),(int)text_len); goto failed; */ } Very dirty but that works ... Eric From elbenard at gmail.com Wed Mar 7 17:02:23 2007 From: elbenard at gmail.com (Eric BENARD) Date: Wed, 07 Mar 2007 18:02:23 +0100 Subject: Data & SRAM Message-ID: <45EEF01F.6080608@gmail.com> Hi, after putting some code in SRAM, I still don't manage to get enough speed improvement. I would like to know if there is an easy way to put data & stack of one application in SRAM. I've tried several options in the linker configuration file but I still don't manage to get the app to execute properly. Any simple idea (or even a dirty idea if it works ;-) ? Best regards Eric From nathan at codesourcery.com Wed Mar 7 18:23:43 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 07 Mar 2007 18:23:43 +0000 Subject: [coldfire-gnu-discuss] Data & SRAM In-Reply-To: <45EEF01F.6080608@gmail.com> References: <45EEF01F.6080608@gmail.com> Message-ID: <45EF032F.9090907@codesourcery.com> Eric BENARD wrote: > Hi, > > after putting some code in SRAM, I still don't manage to get enough > speed improvement. > I would like to know if there is an easy way to put data & stack of one > application in SRAM. > I've tried several options in the linker configuration file but I still > don't manage to get the app to execute properly. The trick here is going to be to convince the uclinux loader to allocate the data segment to the SRAM. That's going to involve kernel hackery. It might be possible to place the stack into SRAM by judicous use of an assembly wrapper that moves SP. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From petter at network-electronics.com Fri Mar 9 14:49:03 2007 From: petter at network-electronics.com (Petter) Date: Fri, 9 Mar 2007 15:49:03 +0100 Subject: M52235EVB and running code from flash Message-ID: <1173451743.9606.21.camel@localhost> An HTML attachment was scrubbed... URL: From nathan at codesourcery.com Fri Mar 9 15:14:04 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Fri, 09 Mar 2007 15:14:04 +0000 Subject: [coldfire-gnu-discuss] M52235EVB and running code from flash In-Reply-To: <1173451743.9606.21.camel@localhost> References: <1173451743.9606.21.camel@localhost> Message-ID: <45F179BC.3070504@codesourcery.com> Petter wrote: > My question: does anybody have a working hello world project for > Sourcery G++, 5223x is target, running from flash (not copying itself > from flash to ram during power-up and then running from ram) ? The next release of Sourcery G++ will support programming CFI devices. We'll be adding support for programming non-CFI interal flash memory, but it is unlikely to be ready for the next release -- it'll be an update later in the year. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From mark at codesourcery.com Fri Mar 9 18:05:17 2007 From: mark at codesourcery.com (Mark Mitchell) Date: Fri, 09 Mar 2007 10:05:17 -0800 Subject: [coldfire-gnu-discuss] M52235EVB and running code from flash In-Reply-To: <45F179BC.3070504@codesourcery.com> References: <1173451743.9606.21.camel@localhost> <45F179BC.3070504@codesourcery.com> Message-ID: <45F1A1DD.2090004@codesourcery.com> Nathan Sidwell wrote: > Petter wrote: > >> My question: does anybody have a working hello world project for >> Sourcery G++, 5223x is target, running from flash (not copying itself >> from flash to ram during power-up and then running from ram) ? > > The next release of Sourcery G++ will support programming CFI devices. > We'll be adding support for programming non-CFI interal flash memory, > but it is unlikely to be ready for the next release -- it'll be an > update later in the year. Nathan, it sounds like Peter might be looking for the ROM linker scripts? Peter, as it sounds like your evaluating Sourcery G++ Personal/Professional, would you please file an issue about the problem you're having through our customer support tracker? Thanks, -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From daniel.mclean at optusnet.com.au Mon Mar 12 02:22:49 2007 From: daniel.mclean at optusnet.com.au (Daniel McLean) Date: Mon, 12 Mar 2007 12:22:49 +1000 Subject: Making malloc threadsafe In-Reply-To: <45F179BC.3070504@codesourcery.com> References: <1173451743.9606.21.camel@localhost> <45F179BC.3070504@codesourcery.com> Message-ID: <45F4B979.7090800@optusnet.com.au> Hi, I was just wondering if it is possible to make malloc thread safe with Sourcery G++ Lite? It seems that libc defines _malloc_lock and _malloc_unlock already. If I make sure that all my calls to malloc in my code are thread safe (using mutual exclusion) will this ensure that memory allocation is in fact thread safe? Or are there places that malloc is called inside the C library such that without implementing _malloc_lock and _malloc_unlock malloc it won't be thread safe? If so how can I make sure that malloc is thread safe? Thanks Daniel From daniel.mclean at optusnet.com.au Mon Mar 12 02:34:01 2007 From: daniel.mclean at optusnet.com.au (Daniel McLean) Date: Mon, 12 Mar 2007 12:34:01 +1000 Subject: [coldfire-gnu-discuss] Making malloc threadsafe In-Reply-To: <45F4B979.7090800@optusnet.com.au> References: <1173451743.9606.21.camel@localhost> <45F179BC.3070504@codesourcery.com> <45F4B979.7090800@optusnet.com.au> Message-ID: <45F4BC19.6010307@optusnet.com.au> It seems I may have partially solved this problem myself. If I don't replace malloc_lock/unlock in one of my own utility libraries that I link in, but instead implement them in the main.c file it seems to stop the linker saying that they have been redefined.. Is there a better way of doing this however (a function attribute or linker option) that tells the compiler or linker that I want to use my version (implemented in a library or otherwise) of these functions? Thanks Daniel Daniel McLean wrote: > Hi, > > I was just wondering if it is possible to make malloc thread safe with > Sourcery G++ Lite? It seems that libc defines _malloc_lock and > _malloc_unlock already. If I make sure that all my calls to malloc in > my code are thread safe (using mutual exclusion) will this ensure that > memory allocation is in fact thread safe? Or are there places that > malloc is called inside the C library such that without implementing > _malloc_lock and _malloc_unlock malloc it won't be thread safe? > > If so how can I make sure that malloc is thread safe? > Thanks > Daniel > > From carlos at codesourcery.com Mon Mar 12 04:24:00 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Mon, 12 Mar 2007 00:24:00 -0400 Subject: [coldfire-gnu-discuss] Making malloc threadsafe In-Reply-To: <45F4B979.7090800@optusnet.com.au> References: <1173451743.9606.21.camel@localhost> <45F179BC.3070504@codesourcery.com> <45F4B979.7090800@optusnet.com.au> Message-ID: <20070312042400.GZ24281@lios> On Mon, Mar 12, 2007 at 12:22:49PM +1000, Daniel McLean wrote: > I was just wondering if it is possible to make malloc thread safe with > Sourcery G++ Lite? It seems that libc defines _malloc_lock and > _malloc_unlock already. If I make sure that all my calls to malloc in > my code are thread safe (using mutual exclusion) will this ensure that > memory allocation is in fact thread safe? Or are there places that > malloc is called inside the C library such that without implementing > _malloc_lock and _malloc_unlock malloc it won't be thread safe? > > If so how can I make sure that malloc is thread safe? Which targets are you using? Coldfire GNU/Linux, Coldfire uCLinux? Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From daniel.mclean at optusnet.com.au Mon Mar 12 04:29:10 2007 From: daniel.mclean at optusnet.com.au (Daniel McLean) Date: Mon, 12 Mar 2007 14:29:10 +1000 Subject: [coldfire-gnu-discuss] Making malloc threadsafe In-Reply-To: <20070312042400.GZ24281@lios> References: <1173451743.9606.21.camel@localhost> <45F179BC.3070504@codesourcery.com> <45F4B979.7090800@optusnet.com.au> <20070312042400.GZ24281@lios> Message-ID: <45F4D716.8000103@optusnet.com.au> Hi Carlos, I'm using the ELF compiler. I'm running the on a small RTOS (www.freeRTOS.org), as opposed to Linux... Thanks Daniel Carlos O'Donell wrote: > On Mon, Mar 12, 2007 at 12:22:49PM +1000, Daniel McLean wrote: > >> I was just wondering if it is possible to make malloc thread safe with >> Sourcery G++ Lite? It seems that libc defines _malloc_lock and >> _malloc_unlock already. If I make sure that all my calls to malloc in >> my code are thread safe (using mutual exclusion) will this ensure that >> memory allocation is in fact thread safe? Or are there places that >> malloc is called inside the C library such that without implementing >> _malloc_lock and _malloc_unlock malloc it won't be thread safe? >> >> If so how can I make sure that malloc is thread safe? >> > > Which targets are you using? Coldfire GNU/Linux, Coldfire uCLinux? > > Cheers, > Carlos. > From carlos at codesourcery.com Mon Mar 12 04:46:31 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Mon, 12 Mar 2007 00:46:31 -0400 Subject: [coldfire-gnu-discuss] Making malloc threadsafe In-Reply-To: <45F4D716.8000103@optusnet.com.au> References: <1173451743.9606.21.camel@localhost> <45F179BC.3070504@codesourcery.com> <45F4B979.7090800@optusnet.com.au> <20070312042400.GZ24281@lios> <45F4D716.8000103@optusnet.com.au> Message-ID: <20070312044631.GA24281@lios> On Mon, Mar 12, 2007 at 02:29:10PM +1000, Daniel McLean wrote: > I'm using the ELF compiler. I'm running the on a small RTOS > (www.freeRTOS.org), as opposed to Linux... That narrows the scope down to a single C library (newlib). Could you post the error your are seeing using the tools? Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From sales at onggie.com Mon Mar 12 04:44:27 2007 From: sales at onggie.com (sales at onggie.com) Date: Mon, 12 Mar 2007 12:44:27 +0800 Subject: Affordable Quality IT And Design Services Message-ID: <17dd801c76461$1d6e1f30$6e02a8c0@chainfusion.net> Dear coldfire-gnu-discuss, Are you looking for IT & design freelancers? We, ONGGIE provide full range of affordable quality IT & design services to meet your interest: ? Application Development ? Website Design ? Photo-editing / Wedding Album Design ? Corporate Stationary Design ? Graphic Design ? Multimedia Presentation ? Application Interface Design ? Painting We found your contact from codesourcery. We believe our service has the capability to expand and strengthen your company's potential by improving the IT workflow and corporate presentation. We have experienced expertise in software development and creative designs to ensure the achievements of your investments. Your IT requirements will be addressed with the utmost concern while our professionals undertake every care to deliver beyond your expectations. For further information, please call: +65 68260618 or visit http://www.onggie.com for a glance of our creative works. Best Regards, ONGGIE -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at codesourcery.com Mon Mar 12 08:44:04 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Mon, 12 Mar 2007 08:44:04 +0000 Subject: [coldfire-gnu-discuss] Making malloc threadsafe In-Reply-To: <45F4BC19.6010307@optusnet.com.au> References: <1173451743.9606.21.camel@localhost> <45F179BC.3070504@codesourcery.com> <45F4B979.7090800@optusnet.com.au> <45F4BC19.6010307@optusnet.com.au> Message-ID: <45F512D4.9070404@codesourcery.com> Daniel, newlib's malloc cannot be made thread-safe without writing OS specific code. Namely some kind of semaphore in the malloc_lock/malloc_unlock functions that you found. You need to replace those. Simply wrapping all your own calls in equivalent code is insufficient, as newlib uses malloc internally. > It seems I may have partially solved this problem myself. If I don't > replace malloc_lock/unlock in one of my own utility libraries that I > link in, but instead implement them in the main.c file it seems to stop > the linker saying that they have been redefined.. Right, this is probably a consequence of the usual linker rules in resolving missing symbols (you don't give a command line, so I cannot be sure). Namely, all explicitly specified object files are pulled in, then the libraries are searched for remaining missing symbols. Each library is repeatedly scanned in turn until no new objects from it are pulled in. Then the linker moves on to the next library. Libraries can be grouped so they are repeatedly scanned as a group, rather than individually. I'll have to check newlib to see whether the dummy lock/unlock functions are in the same object file as something else that is being pulled in. > Is there a better way of doing this however (a function attribute or > linker option) that tells the compiler or linker that I want to use my > version (implemented in a library or otherwise) of these functions? hmm, making the dummy malloc_lock malloc_unlock functions in newlib weak would probably be sufficient. I'll add that to the feature wish list. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From daniel.mclean at optusnet.com.au Mon Mar 12 08:52:29 2007 From: daniel.mclean at optusnet.com.au (Daniel McLean) Date: Mon, 12 Mar 2007 18:52:29 +1000 Subject: [coldfire-gnu-discuss] Making malloc threadsafe In-Reply-To: <45F512D4.9070404@codesourcery.com> References: <1173451743.9606.21.camel@localhost> <45F179BC.3070504@codesourcery.com> <45F4B979.7090800@optusnet.com.au> <45F4BC19.6010307@optusnet.com.au> <45F512D4.9070404@codesourcery.com> Message-ID: <45F514CD.6000601@optusnet.com.au> Hi Nathan, Thanks for the answer. I had expected them to be declared as weak but on checking the newlib code it appears they aren't. I guess the answer I was sort of looking for was whether or not there was the opposite to a weak attribute (eg. a strong attribute) which causes a particular function to overrule any other one during the link process.. I couldn't see this in the docs but am happy enough with my solution at the moment... As for thread safeness, the RTOS I'm using (FreeRTOS) has functions which ensure exclusivity, which I have used for my malloc_lock and malloc_unlock routines, so I'm pretty happy that malloc should be threadsafe... Thanks again for the help, Daniel Nathan Sidwell wrote: > Daniel, > > newlib's malloc cannot be made thread-safe without writing OS specific > code. Namely some kind of semaphore in the malloc_lock/malloc_unlock > functions that you found. You need to replace those. Simply wrapping > all your own calls in equivalent code is insufficient, as newlib uses > malloc internally. > >> It seems I may have partially solved this problem myself. If I don't >> replace malloc_lock/unlock in one of my own utility libraries that I >> link in, but instead implement them in the main.c file it seems to >> stop the linker saying that they have been redefined.. > > Right, this is probably a consequence of the usual linker rules in > resolving missing symbols (you don't give a command line, so I cannot > be sure). Namely, all explicitly specified object files are pulled > in, then the libraries are searched for remaining missing symbols. > Each library is repeatedly scanned in turn until no new objects from > it are pulled in. Then the linker moves on to the next library. > Libraries can be grouped so they are repeatedly scanned as a group, > rather than individually. I'll have to check newlib to see whether > the dummy lock/unlock functions are in the same object file as > something else that is being pulled in. > >> Is there a better way of doing this however (a function attribute or >> linker option) that tells the compiler or linker that I want to use >> my version (implemented in a library or otherwise) of these functions? > > hmm, making the dummy malloc_lock malloc_unlock functions in newlib > weak would probably be sufficient. I'll add that to the feature wish > list. > > nathan > From sales at chainfusion.com Thu Mar 15 05:07:01 2007 From: sales at chainfusion.com (sales at chainfusion.com) Date: Thu, 15 Mar 2007 13:07:01 +0800 Subject: Customizable eDistriFusion - Gain control of your distribution software Message-ID: <1669201c766bf$c3a20370$6e02a8c0@chainfusion.net> Dear coldfire-gnu-discuss, Get customizable eDistriFusion, gain control of your distribution software. eDistriFusion is design to be: ? customizable to suit the ever changing business environment, ? build on a 3-tier software architecture for easy maintenance, ? and web based to support 24x7 and internationalization operation. Customizable: eDistriFusion is developed in C# using Microsoft Visual Studio as the development platform, allows source files to be open and customized to suit your business needs. Besides the customizable distribution software, the package also comes with an integrated code generator to generate source code from database design, for more efficient and consistent software customization. 3-Tier: eDistriFusion has a 3-Tier architecture, and software modifications are by tier, resulting in a modular and organized software, with no worry about messy and hard to maintain codes. The software is also object oriented by design. Web Based: eDistriFusion is a web based solution, whereby its hosted onto a web server and allows access within or outside office. It is on the Microsoft .net framework and support xml web services for interface with other systems. We found your contact from www.codesourcery.com. For more information or software demonstration, call Chris at +65 62999686 or email sales at chainfusion.com Best Regards, ChainFusion -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrelipinski at sympatico.ca Fri Mar 16 02:31:45 2007 From: andrelipinski at sympatico.ca (Andre Lipinski) Date: Thu, 15 Mar 2007 22:31:45 -0400 Subject: Objective-C Message-ID: Hello, I've been looking for tools to use Objective-C with a ColdFire based system. I see that a number of your staffers have contributed to libobjc in GCC and wonder if your tools support development in ObjC? Best, Andre. From nathan at codesourcery.com Fri Mar 16 09:44:06 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Fri, 16 Mar 2007 09:44:06 +0000 Subject: [coldfire-gnu-discuss] Objective-C In-Reply-To: References: Message-ID: <45FA66E6.9050707@codesourcery.com> Andre , > I've been looking for tools to use Objective-C with a ColdFire based > system. I see that a number of your staffers have contributed to libobjc > in GCC and wonder if your tools support development in ObjC? We've not tried building Objective-C for ColdFire. The tools should work with objective-c enabled, just as well as any other objective-c system. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From andrelipinski at sympatico.ca Fri Mar 16 19:05:14 2007 From: andrelipinski at sympatico.ca (Andre Lipinski) Date: Fri, 16 Mar 2007 15:05:14 -0400 Subject: [coldfire-gnu-discuss] Objective-C In-Reply-To: <45FA66E6.9050707@codesourcery.com> References: <45FA66E6.9050707@codesourcery.com> Message-ID: Nathan, Okay, sounds good... I see from the CodeSourcery site that you've got G++ compilers -- are these substantially modified(cut-down) or enhanced from GCC? I've also been through the GCC project site and found that your staff contribute much to GCC and are largely responsible for improved ColdFire support in GCC which is just WONDERFUL! I'm a Mac SW engineer and have many years of ObjC experience, and many Mb of source code, some of which I'd like to reuse in an embedded project I'm working on. I'd like to see a ColdFire development and debug environment on Mac OS X using XCode if possible, Eclipse if necessary. If successful it could be a boon to Mac developers who are keen on ColdFire and want a "mainstream" embedded solution without giving up their Macs. I'd like to get your opinion of what might be involved in making this happen. I think building a toolchain should be quite doable based on what I've read at the GCC site and your comments this morning. But putting it all together with hardware (I'm thinking a NetBurner 5282 based module) and actually getting it to work could be something I'm not prepared to do. I certainly am prepared to spend significant time on this, but don't want to "reinvent the wheel." Could you please help me understand what I'm getting myself into? Best, Andre. On Mar 16, 2007, at 5:44 AM, Nathan Sidwell wrote: > Andre , >> I've been looking for tools to use Objective-C with a ColdFire >> based system. I see that a number of your staffers have >> contributed to libobjc in GCC and wonder if your tools support >> development in ObjC? > > We've not tried building Objective-C for ColdFire. The tools > should work with objective-c enabled, just as well as any other > objective-c system. > > nathan > > -- > Nathan Sidwell :: http://www.codesourcery.com :: > CodeSourcery > nathan at codesourcery.com :: http:// > www.planetfall.pwp.blueyonder.co.uk From nathan at codesourcery.com Fri Mar 16 21:31:28 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Fri, 16 Mar 2007 21:31:28 +0000 Subject: [coldfire-gnu-discuss] Objective-C In-Reply-To: References: <45FA66E6.9050707@codesourcery.com> Message-ID: <45FB0CB0.3060307@codesourcery.com> Andre, > I see from the CodeSourcery site that you've got G++ compilers -- are > these substantially modified(cut-down) or enhanced from GCC? I've also > been through the GCC project site and found that your staff contribute > much to GCC and are largely responsible for improved ColdFire support in > GCC which is just WONDERFUL! Thank you :) The toolchains we provide have the ColdFire patches ported to stable GCC branches (4.1 is the current release, and 4.2 is arriving shortly). Mainline FSF has the ColdFire changes and those will work their way into 4.3. In addition, we validate the binaries we provided by building them in a controlled environment and running the testsuites on a variety of target boards. > I'm a Mac SW engineer and have many years of ObjC experience, and many > Mb of source code, some of which I'd like to reuse in an embedded > project I'm working on. I'd like to see a ColdFire development and debug > environment on Mac OS X using XCode if possible, Eclipse if necessary. > If successful it could be a boon to Mac developers who are keen on > ColdFire and want a "mainstream" embedded solution without giving up > their Macs. The SourceryG++ product includes Eclipse integration. We're not currently supporting Mac as a host system, but would consider it if there was demand. > I'd like to get your opinion of what might be involved in making this > happen. I think building a toolchain should be quite doable based on > what I've read at the GCC site and your comments this morning. But > putting it all together with hardware (I'm thinking a NetBurner 5282 > based module) and actually getting it to work could be > something I'm not prepared to do. I certainly am prepared to spend > significant time on this, but don't want to "reinvent the wheel." It depends where you think your strengths are and what you want to spend your time on. Do you want to develop and validate a toolchain, or do you want to write programs :) nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From andrelipinski at sympatico.ca Fri Mar 16 21:36:26 2007 From: andrelipinski at sympatico.ca (Andre Lipinski) Date: Fri, 16 Mar 2007 17:36:26 -0400 Subject: [coldfire-gnu-discuss] Objective-C In-Reply-To: <45FB0CB0.3060307@codesourcery.com> References: <45FA66E6.9050707@codesourcery.com> <45FB0CB0.3060307@codesourcery.com> Message-ID: <141A11CB-8AAF-4702-8201-F6A8C4BF7E98@sympatico.ca> Nathan, On Mar 16, 2007, at 5:31 PM, Nathan Sidwell wrote: > Andre, >> I see from the CodeSourcery site that you've got G++ compilers -- >> are these substantially modified(cut-down) or enhanced from GCC? >> I've also been through the GCC project site and found that your >> staff contribute much to GCC and are largely responsible for >> improved ColdFire support in GCC which is just WONDERFUL! > > Thank you :) The toolchains we provide have the ColdFire patches > ported to stable GCC branches (4.1 is the current release, and 4.2 > is arriving shortly). Mainline FSF has the ColdFire changes and > those will work their way into 4.3. In addition, we validate the > binaries we provided by building them in a controlled environment > and running the testsuites on a variety of target boards. Does that include the NetBurner modules? > >> I'm a Mac SW engineer and have many years of ObjC experience, and >> many Mb of source code, some of which I'd like to reuse in an >> embedded project I'm working on. I'd like to see a ColdFire >> development and debug environment on Mac OS X using XCode if >> possible, Eclipse if necessary. If successful it could be a boon >> to Mac developers who are keen on ColdFire and want a "mainstream" >> embedded solution without giving up their Macs. > > The SourceryG++ product includes Eclipse integration. We're not > currently supporting Mac as a host system, but would consider it if > there was demand. What exactly would it take to move forward? > >> I'd like to get your opinion of what might be involved in making >> this happen. I think building a toolchain should be quite doable >> based on what I've read at the GCC site and your comments this >> morning. But putting it all together with hardware (I'm thinking a >> NetBurner 5282 based module) and actually getting it to work could be >> something I'm not prepared to do. I certainly am prepared to spend >> significant time on this, but don't want to "reinvent the wheel." > > It depends where you think your strengths are and what you want to > spend your time on. Do you want to develop and validate a > toolchain, or do you want to write programs :) I would consider both a good use of my time and abilities. Just how much time is needed, in your experience? Best, Andre. From david at westcontrol.com Mon Mar 19 07:04:00 2007 From: david at westcontrol.com (David Brown) Date: Mon, 19 Mar 2007 08:04:00 +0100 Subject: [coldfire-gnu-discuss] Objective-C In-Reply-To: <45FB0CB0.3060307@codesourcery.com> References: <45FA66E6.9050707@codesourcery.com> <45FB0CB0.3060307@codesourcery.com> Message-ID: <45FE35E0.8080002@westcontrol.com> Nathan Sidwell wrote: > Andre, >> I see from the CodeSourcery site that you've got G++ compilers -- are >> these substantially modified(cut-down) or enhanced from GCC? I've also >> been through the GCC project site and found that your staff contribute >> much to GCC and are largely responsible for improved ColdFire support >> in GCC which is just WONDERFUL! > > Thank you :) The toolchains we provide have the ColdFire patches ported > to stable GCC branches (4.1 is the current release, and 4.2 is arriving > shortly). Mainline FSF has the ColdFire changes and those will work > their way into 4.3. In addition, we validate the binaries we provided by > building them in a controlled environment and running the testsuites on > a variety of target boards. > I just read about that on the gcc website - I too am glad to see your ColdFire improvements being merged back to the mainline. The fact that you guys are willing and able to contribute ColdFire improvements to gcc is the biggest reason for my choosing Code Sourcery in the first place ("willing" and "able" counting roughly equally). Well done! From what I have read on the gcc website, gcc 4.2 has a number of small improvements, but gcc 4.3 is a more substantial improvement. Is that right? We may be looking at ARM development in the near future - do you also work directly on improvements on the ARM target of gcc? mvh., David From nathan at codesourcery.com Mon Mar 19 09:01:07 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Mon, 19 Mar 2007 09:01:07 +0000 Subject: [coldfire-gnu-discuss] Objective-C In-Reply-To: <45FE35E0.8080002@westcontrol.com> References: <45FA66E6.9050707@codesourcery.com> <45FB0CB0.3060307@codesourcery.com> <45FE35E0.8080002@westcontrol.com> Message-ID: <45FE5153.2060705@codesourcery.com> David Brown wrote: > From what I have read on the gcc website, gcc 4.2 has a number of small > improvements, but gcc 4.3 is a more substantial improvement. Is that > right? I've not looked closely at the 4.2 changes. I understand it has a number of optimizer improvements, which at least include the alias analyser. FSF 4.2 will not include the ColdFire improvments, but CS has ported those to our version of 4.2, which will be released shortly. > We may be looking at ARM development in the near future - do you also > work directly on improvements on the ARM target of gcc? Yes. We're ARM's official developer of GCC for ARM targets and have been adding new pieces of ARM support for several years now. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From b2murray at engmail.uwaterloo.ca Mon Mar 19 15:44:36 2007 From: b2murray at engmail.uwaterloo.ca (Brad Murray) Date: Mon, 19 Mar 2007 11:44:36 -0400 Subject: Coldfire compiler issue on 64-bit vista Message-ID: <8062e7cc0703190844n755c88ffiaffb0c248ec03f00@mail.gmail.com> Morning all, I ran into an issue this morning when trying to compile C to a 68k elf file. This was previously working on Windows XP (32-bit), but over the weekend I upgraded OSes and my build no longer works. I am attempting to run it with m68k-elf-gcc.exe set to run as administrator I run the following command... *m68k-elf-gcc.exe -m5307 -nostdlib --omit-frame-pointer -Ttext 0x10000000 -o gec9001.elf ".\foo.c"* and I receive the following error message... *m68k-elf-gcc.exe: CreateProcess: No such file or directory* Any help would be greatly appreciated. Thanks, Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlos at codesourcery.com Mon Mar 19 16:33:29 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Mon, 19 Mar 2007 12:33:29 -0400 Subject: [coldfire-gnu-discuss] Coldfire compiler issue on 64-bit vista In-Reply-To: <8062e7cc0703190844n755c88ffiaffb0c248ec03f00@mail.gmail.com> References: <8062e7cc0703190844n755c88ffiaffb0c248ec03f00@mail.gmail.com> Message-ID: <20070319163329.GD18128@lios> On Mon, Mar 19, 2007 at 11:44:36AM -0400, Brad Murray wrote: > I ran into an issue this morning when trying to compile C to a 68k elf > file. This was previously working on Windows XP (32-bit), but over the > weekend I upgraded OSes and my build no longer works. I am attempting to > run it with m68k-elf-gcc.exe set to run as administrator > > I run the following command... > > m68k-elf-gcc.exe -m5307 -nostdlib --omit-frame-pointer -Ttext 0x10000000 > -o gec9001.elf ".\foo.c" > > and I receive the following error message... > > m68k-elf-gcc.exe: CreateProcess: No such file or directory > > Any help would be greatly appreciated. There is no workaround for this. This issue has already been fixed. This fix will be available when we release public support for Windows Vista. If you need a solution immediately please consider a "Professional" subscription: http://www.codesourcery.com/gnu_toolchains/sgpp/editions.html Thank you for using Sourcery G++! Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From nathan at codesourcery.com Mon Mar 19 17:29:54 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Mon, 19 Mar 2007 17:29:54 +0000 Subject: [coldfire-gnu-discuss] Coldfire compiler issue on 64-bit vista In-Reply-To: <8062e7cc0703190844n755c88ffiaffb0c248ec03f00@mail.gmail.com> References: <8062e7cc0703190844n755c88ffiaffb0c248ec03f00@mail.gmail.com> Message-ID: <45FEC892.8080702@codesourcery.com> Brad, > I ran into an issue this morning when trying to compile C to a 68k elf > file. This was previously working on Windows XP (32-bit), but over the > weekend I upgraded OSes and my build no longer works. I am attempting to > run it with m68k-elf-gcc.exe set to run as administrator > /m68k-elf-gcc.exe: CreateProcess: No such file or directory/ Yes, we're aware of this issue with Vista. FSF GCC suffers the same problem. A fix will be available in our upcoming release. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From thespecialbrad at gmail.com Mon Mar 19 17:38:59 2007 From: thespecialbrad at gmail.com (Brad Murray) Date: Mon, 19 Mar 2007 13:38:59 -0400 Subject: [coldfire-gnu-discuss] Coldfire compiler issue on 64-bit vista In-Reply-To: <45FEC892.8080702@codesourcery.com> References: <8062e7cc0703190844n755c88ffiaffb0c248ec03f00@mail.gmail.com> <45FEC892.8080702@codesourcery.com> Message-ID: <8062e7cc0703191038g685149ddv185966aa830aefc1@mail.gmail.com> Apparently installing to C:\Codesourcery G++\ instead of C:\Program Files\Codesourcery G++\ is a valid work around for the time being. Thanks for your help, Brad On 3/19/07, Nathan Sidwell wrote: > > Brad, > > I ran into an issue this morning when trying to compile C to a 68k elf > > file. This was previously working on Windows XP (32-bit), but over the > > weekend I upgraded OSes and my build no longer works. I am attempting to > > run it with m68k-elf-gcc.exe set to run as administrator > > > /m68k-elf-gcc.exe: CreateProcess: No such file or directory/ > > Yes, we're aware of this issue with Vista. FSF GCC suffers the same > problem. A > fix will be available in our upcoming release. > > nathan > > -- > Nathan Sidwell :: http://www.codesourcery.com :: > CodeSourcery > nathan at codesourcery.com :: > http://www.planetfall.pwp.blueyonder.co.uk > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sales at wusic.com Tue Mar 20 07:25:00 2007 From: sales at wusic.com (sales at wusic.com) Date: Tue, 20 Mar 2007 15:25:00 +0800 Subject: Budget international callback service Message-ID: <2f6a01c76ac0$de972160$1102a8c0@chainfusion.net> Dear coldfire-gnu-discuss, Are you looking for a money saving international callback service that can earn you money at the same time? Go for WUSIC. With the revolutionary telephony callback technology, you can save up to 75% of your current local and overseas call bills and at the same time enjoy the excellent voice call quality. Try it now! Stop paying high charges on all local (Singapore) out going calls. With WUSIC, all local calls are just 5 cents 24 hours round the clock, and: ? No more expensive phone bills by local telco's monopoly ? No more expensive long distance calls ? No more expensive IDD roaming charges ? Enjoy the service anywhere in the world ? Go further, be the Distributor and start earning money. Everyone around you has a mobile phone - UNLIMITED potentials ? Guaranteed real sensational SAVINGS for your customers ? Simple training and instant activation for trial usage by transferring credits between mobile phones globally ? Online Topup (using Credit Card or Internet Banking) We found your contact from www.codesourcery.com, we would like to invite you to our weekly seminar to teach you how to Save $ Make $ while you call. The seminar is held on every Thursday from 7pm to 8pm at our office: 289 Beach Road, #05-01, Singapore 199552. For more information, please visit http://www.wusic.com or call Jo at +65 62999686 / [ Click to Call ] Jo now for FREE or email sales at wusic.com. Best Regards, Wusic -------------- next part -------------- An HTML attachment was scrubbed... URL: From paam at cegetel.net Tue Mar 20 16:39:37 2007 From: paam at cegetel.net (Philippe ROUVEYROL) Date: Tue, 20 Mar 2007 17:39:37 +0100 Subject: listing options Message-ID: <000801c76b0e$5b27d600$f6744856@phil5a43b14938> Hello, When i enable listing options with command line: m68k-elf-gcc -mcpu=5208 -c -O1 -Wall -g -Wa,-alhmns=timer.lst timer.c the source and op code is misaligned and first line is truncated. i.e: 34:timer.c **** MCF_ICR5 = 0x2; 28 oveq #2,%d0 29 001a 7002 move.b %d0,-66813883 30 001c 13C0 FC04 .loc 1 36 0 30 8045 35:timer.c **** 36:timer.c **** } 31 lk %fp 32 0022 4E5E rts 33 0024 4E75 .LFE2: it's a bad command? thanks, philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlos at codesourcery.com Wed Mar 21 15:12:31 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Wed, 21 Mar 2007 11:12:31 -0400 Subject: [coldfire-gnu-discuss] listing options In-Reply-To: <000801c76b0e$5b27d600$f6744856@phil5a43b14938> References: <000801c76b0e$5b27d600$f6744856@phil5a43b14938> Message-ID: <20070321151229.GQ18128@lios> On Tue, Mar 20, 2007 at 05:39:37PM +0100, Philippe ROUVEYROL wrote: > Hello, > > When i enable listing options with command line: > m68k-elf-gcc -mcpu=5208 -c -O1 -Wall -g -Wa,-alhmns=timer.lst > timer.c > > the source and op code is misaligned and first line is truncated. > i.e: > 34:timer.c **** MCF_ICR5 = 0x2; > 28 oveq #2,%d0 > 29 001a 7002 move.b %d0,-66813883 > 30 001c 13C0 FC04 .loc 1 36 0 > 30 8045 > 35:timer.c **** > 36:timer.c **** } > 31 lk %fp > 32 0022 4E5E rts > 33 0024 4E75 .LFE2: > > it's a bad command? Could you provide the original source code? Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From carlos at codesourcery.com Wed Mar 21 23:04:20 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Wed, 21 Mar 2007 19:04:20 -0400 Subject: RE?: [coldfire-gnu-discuss] listing options In-Reply-To: <445D2D771F0EFB488935D63813D727C05C2207@blvsrvexch1.imaje.intra> References: <445D2D771F0EFB488935D63813D727C00BC0C9D8@blvsrvexch1.imaje.intra> <20070321181130.GX18128@lios> <445D2D771F0EFB488935D63813D727C05C2207@blvsrvexch1.imaje.intra> Message-ID: <20070321230420.GA26700@lios> On Wed, Mar 21, 2007 at 07:16:07PM +0100, Philippe Rouveyrol wrote: > I use windows 2000 OK, I was able to reproduce this on our Windows test systems. We will be looking at this issues. Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From david at westcontrol.com Tue Mar 27 14:40:57 2007 From: david at westcontrol.com (David Brown) Date: Tue, 27 Mar 2007 16:40:57 +0200 Subject: Coldfire v1 core Message-ID: <46092CF9.6050004@westcontrol.com> Are there any plans regarding support for the v1 ColdFire core? I have heard (but can't confirm) that Freescale are beginning to provide samples for larger customers, and will be available sometime this year. I don't expect there will much work needed to get basic v1 core support (i.e., disabling instructions that are not supported in the v1 core, and linker files for the various devices as they come out), but more complete support would optimise for the new instructions. There is also debugger support to consider. I have no concrete plans to use the devices at the moment, but if they live up to their aim of ColdFire power at 8-bit price and package sizes, they could be very interesting. mvh., David From mark at codesourcery.com Tue Mar 27 15:05:25 2007 From: mark at codesourcery.com (Mark Mitchell) Date: Tue, 27 Mar 2007 08:05:25 -0700 Subject: [coldfire-gnu-discuss] Coldfire v1 core In-Reply-To: <46092CF9.6050004@westcontrol.com> References: <46092CF9.6050004@westcontrol.com> Message-ID: <460932B5.6080800@codesourcery.com> David Brown wrote: > Are there any plans regarding support for the v1 ColdFire core? Yes, stay tuned. -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From andreas at cryptkeeper.org Wed Mar 28 07:07:51 2007 From: andreas at cryptkeeper.org (Andreas Engberg) Date: Wed, 28 Mar 2007 00:07:51 -0700 Subject: Weird behavior in gdb (m5475) ? Message-ID: Hi, I've been having problems with gdb and the m5475 development board. Bear with me as I try to explain>>> I have the 4.1-32 version. I have a simple 'hello world' program running in RAM. It compiles and links ok. I set up the target using sprite and everything seems to be ok (I can read/write to valid memory regions including mbar). After issuing a 'target remote' command, everything is still fine. Or is it? At first, I thought I forgot to load the application. It loads nicely but the problem is still there. Here is the deal: I try to read address 0x4e2 (part of the puts function): (gdb) x /i 0x4e2 0x4e2 <_puts_r+18>: movel %d2,%fp@(20463) (gdb) x /x 0x4e2 0x4e2 <_puts_r+18>: 0x2d424fef This is close but no cigar. According to objdump, the data (or in this case instruction) at address 0x4e2 should be : 4e2: 2d42 ffe4 movel %d2,%fp@(-28) These error are scattered through out the coldfire side. Some are minor, like the one above, but some are interpreted as different instructions. I've tried changing the speed of my Multilink. No change. Tried to write my own board spec file for m5475. No change. Frankly, I'm puzzled. It could be that all the sdram controller settings are off. I would think that should have greater impact than this. The data is really close what it should be but not 100% exact. Or does something happen in the bdm driver that I'm not aware of? Ideas? Suggestions? Oh, I've also downloaded the 30day pro. version but the problem persist. I'll try to go back to an older version of the toolchain to see if that makes any difference. Thanks, Andreas From nathan at codesourcery.com Wed Mar 28 09:48:53 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 28 Mar 2007 10:48:53 +0100 Subject: [coldfire-gnu-discuss] Weird behavior in gdb (m5475) ? In-Reply-To: References: Message-ID: <460A3A05.6080200@codesourcery.com> Andreas Engberg wrote: > (gdb) x /i 0x4e2 > 0x4e2 <_puts_r+18>: movel %d2,%fp@(20463) > (gdb) x /x 0x4e2 > 0x4e2 <_puts_r+18>: 0x2d424fef > > This is close but no cigar. According to objdump, the data (or in this > case instruction) at address 0x4e2 should be : > 4e2: 2d42 ffe4 movel %d2,%fp@(-28) > Frankly, I'm puzzled. hm, we've never seen this. We did notice a problem on our 5485 board where the P&E wiggler would report multiple bus errors after a single erroneous access (the bus error behaviour was sticky, and cleared after a time). P&E confirmed a firmware bug and we'll be providing updated windows drivers in the next release (which is imminent). I don't know if other issues were fixed at the same time. Have you verified whether individual writes by gdb are read back correctly. Try both byte and long writes with multiple alignments. It's extremely odd that only certain parts of the 32bit word are being scrambled like so -- and only certain addresses. > Ideas? Suggestions? Oh, I've also downloaded the 30day pro. version but > the problem persist. Well, you can always avail yourself of the technical support that that evaluation provides :) nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk