From kevin.bube at mahr.de Mon Apr 2 13:39:15 2007 From: kevin.bube at mahr.de (Kevin Bube) Date: Mon, 02 Apr 2007 15:39:15 +0200 Subject: m68k-elf-sprite cannot talk to Coldfire board Message-ID: Hi list, I downloaded your Gnu toolchain 4.1-32 for Windows (great work, btw.). Now I try to get a "Hello, world" program running for an mcf5474evb processor. I compiled the programm and try to debug it under m68k-elf-gdb with m68k-elf-sprite. Unfortunately I am stuck in the following: D:\workspace\Example\src>m68k-elf-gdb 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: . (gdb) file hello.elf Reading symbols from D:\workspace\Example\src/hello.elf...done. (gdb) target remote | m68k-elf-sprite -v pe://ParallelPortCable m5485evb Remote debugging using | m68m68k-elf-sprite:k-elf-sprite -v peCodeSourcery ColdF ire Debug Sprite (Sourcery G++ Lite 4.1-32) ://ParallelPortCable m5485evb m68k-elf-sprite:Using P&E DLL version: ColdFire Interface Libraries Version 3.14 (http://www.pemicro.com) m68k-elf-sprite:Opening P&E ParallelPortCable port 1 (LPT1 : Parallel Port 1 (Ad dress $0378)) m68k-elf-sprite:Setting connection speed to -1 m68k-elf-sprite:Doing I/O to stdin/stdout m68k-elf-sprite:Firmware version unavailable m68k-elf-sprite:Remote device ready m68k-elf-sprite:Floating point support enabled m68k-elf-sprite:Cache support enabled m68k-elf-sprite:Init write-control 0xc0f=0x10000000 m68k-elf-sprite:Init write-control 0xc04=0x20000021 m68k-elf-sprite:Init write-control 0xc05=0x20001021 m68k-elf-sprite:Init write-memory 32 bits 0x1000050c=0x40000000 m68k-elf-sprite:Init write-memory 32 bits 0x10000514=0x100d80 m68k-elf-sprite:Init write-memory 32 bits 0x10000510=0xff0001 m68k-elf-sprite:Init write-memory 32 bits 0x10000500=0xfe000000 m68k-elf-sprite:Init write-memory 32 bits 0x10000508=0x1980 m68k-elf-sprite:Init write-memory 32 bits 0x10000504=0x1f0001 m68k-elf-sprite:Init write-memory 32 bits 0x10000004=0x2aa m68k-elf-sprite:Init write-memory 32 bits 0x10000020=0x19 m68k-elf-sprite:Init write-memory 32 bits 0x10000024=0x0 m68k-elf-sprite:Init write-memory 32 bits 0x10000108=0x53722930 m68k-elf-sprite:Init write-memory 32 bits 0x1000010c=0x24330000 m68k-elf-sprite:Init write-memory 32 bits 0x10000104=0xe10f0002 m68k-elf-sprite:Init write-memory 32 bits 0x10000100=0x40010000 m68k-elf-sprite:Init write-memory 32 bits 0x10000100=0x5890000 m68k-elf-sprite:Init write-memory 32 bits 0x10000104=0xe10f0002 m68k-elf-sprite:Init write-memory 32 bits 0x10000104=0xe10f0004 m68k-elf-sprite:Init write-memory 32 bits 0x10000104=0xe10f0004 m68k-elf-sprite:Init write-memory 32 bits 0x10000100=0x1890000 m68k-elf-sprite:Init write-memory 32 bits 0x10000104=0x710f0f00 m68k-elf-sprite:Init delay 100000us m68k-elf-sprite:Memory [0x0,+0x4000000) ram m68k-elf-sprite:Memory [0x20000000,+0x1000) ram m68k-elf-sprite:Memory [0x20001000,+0x1000) ram m68k-elf-sprite:Memory [0x40000000,+0x1000000) rom m68k-elf-sprite:Memory [0xfe000000,+0x200000) rom m68k-elf-sprite:Target reset m68k-elf-sprite:Got packet: 'qSupported' m68k-elf-sprite:Sent response: 'PacketSize=1f40;qXfer:memory-map:read+;qXfer:fea tures:read+' m68k-elf-sprite:Got packet: 'Hc-1' m68k-elf-sprite:Sent response: '' m68k-elf-sprite:Got packet: 'qC' m68k-elf-sprite:Sent response: 'unset' m68k-elf-sprite:Got packet: 'qOffsets' m68k-elf-sprite:Sent response: '' m68k-elf-sprite:Got packet: '?' m68k-elf-sprite:Sent response: 'S00' m68k-elf-sprite:Got packet: 'Hg0' m68k-elf-sprite:Sent response: '' m68k-elf-sprite:Got packet: 'g' m68k-elf-sprite:Sent response: 'cf43701307400740573186cb5d5ee1af9182f46cbfd334a1 d65a1ef37dfbbb6b2bd3513e5b7ef3b99f589fb37d62780c08bdbdd78f3325b3f6241d79fda532f8 00002708000000007fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff 7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff0000000000000000 00000000' m68k-elf-sprite:Got packet: 'qXfer:features:read:CHECKSUMS:0,1000' m68k-elf-sprite:Sent response: 'lfbfdef12d60f4b5e81f1af631305bea492599535 cf-co re.xml 2ffca16d012bd150f910720ae92dc0b1ea8178f7 cf-fp.xml ' m68k-elf-sprite:Got packet: 'qXfer:features:read:target.xml:0,1000' m68k-elf-sprite:Sent response: 'l' m68k-elf-sprite:Got packet: 'qXfer:features:read:cf-core.xml:0,1000' m68k-elf-sprite:Sent response: 'l ' m68k-elf-sprite:Got packet: 'qXfer:features:read:cf-fp.xml:0,1000' m68k-elf-sprite:Sent response: 'l , ' m68k-elf-sprite:Got packet: 'g' 0x00000000 in _m68k-elf-sprite:Sent response: 'cf43701307400740573186cb5d5ee1af9 182f46cbfd334a1d65a1ef37dfbbb6b2bd3513e5b7ef3b99f589fb37d62780c08bdbdd78f3325b3f 6241d79fda532f800002708000000007fffffffffffffff7fffffffffffffff7fffffffffffffff7 fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff7fffffffffffffff0 00000000000000000000000' _VECTOR_RAM () at vectors.s:295 295 start: m68k-elf-sprite:Got packet: 'qSymbol::' m68k-elf-sprite:Sent response: '' Current language: auto; currently asm (gdb) load m68k-elf-sprite:Got packet: 'qXfer:memory-map:read::0,fff' Loading section .vector_ram, size 0x420 lma 0x0 m68k-elf-sprite:Sent response: 'l ' m68k-elf-sprite:Got binary X packet: 'X0,0...' m68k-elf-sprite:Sent response: 'OK' m68k-elf-sprite:Got binary X packet: 'X0,420...' m68k-elf-sprite:Loading section .fini, size 0x6 lma 0x420 Sent response: 'OK' m68k-elf-sprite:Got binary X packet: 'X420,6...' m68k-elf-sprite:Sent response: 'OK' Loading section .init, size 0xc lma 0x426 m68k-elf-sprite:Got binary X packet: 'X426,c...' m68k-elf-sprite:Sent response: 'OK' Loading section .eh_frame, size 0x4 lma 0x434 m68k-elf-sprite:Got binary X packet: 'X434,4...' m68k-elf-sprite:Sent response: 'OK' Loading section .ctors, size 0x8 lma 0x438 m68k-elf-sprite:Got binary X packet: 'X438,8...' m68k-elf-sprite:Sent response: 'OK' Loading section .dtors, size 0x8 lma 0x440 m68k-elf-sprite:Got binary X packet: 'X440,8...' m68k-elf-sprite:Sent response: 'OK' Loading section .jcr, size 0x4 lma 0x448 m68k-elf-sprite:Got binary X packet: 'X448,4...' m68k-elf-sprite:Sent response: 'OK' Loading section .sdram, size 0x2640 lma 0x500 m68k-elf-sprite:Got binary X packet: 'X500,1f10...' m68k-elf-sprite:Sent response: 'OK' m68k-elf-sprite:Got binary X packet: 'X2410,730...' m68k-elf-sprite:Loading section .main_application_data, size 0x40 lma 0x4000500 Sent response: 'OK' m68k-elf-sprite:Got binary X packet: 'X4000500,40...' m68k-elf-sprite:error:Hardware device not ready m68k-elf-sprite:Closing P&E device Remote communication error: No error. (gdb) The device on the parallel port seems to get detected and some commands get exchanged, but suddenly an error occurs. Any ideas? Regards, Kevin From nathan at codesourcery.com Mon Apr 2 14:03:38 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Mon, 02 Apr 2007 15:03:38 +0100 Subject: [coldfire-gnu-discuss] m68k-elf-sprite cannot talk to Coldfire board In-Reply-To: References: Message-ID: <46110D3A.9090900@codesourcery.com> Kevin Bube wrote: > Hi list, > > I downloaded your Gnu toolchain 4.1-32 for Windows (great work, btw.). > > Now I try to get a "Hello, world" program running for an mcf5474evb > processor. I compiled the programm and try to debug it under > (gdb) file hello.elf > Reading symbols from D:\workspace\Example\src/hello.elf...done. > (gdb) target remote | m68k-elf-sprite -v pe://ParallelPortCable m5485evb > > The device on the parallel port seems to get detected and some commands > get exchanged, but suddenly an error occurs. Any ideas? Do you know whether the m5474evb board can use the same configuration file as the m5485evb board? From what I've seen of an m5475evb board they are different. Unfortunately I don't have any information on the m5474evb board to know what a config file should look like. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From andrux76 at gmail.com Mon Apr 2 20:01:15 2007 From: andrux76 at gmail.com (Andreas Engberg) Date: Mon, 02 Apr 2007 13:01:15 -0700 Subject: [coldfire-gnu-discuss] m68k-elf-sprite cannot talk to Coldfire board In-Reply-To: <46110D3A.9090900@codesourcery.com> References: <46110D3A.9090900@codesourcery.com> Message-ID: > Do you know whether the m5474evb board can use the same configuration > file as the m5485evb board? From what I've seen of an m5475evb board > they are different. Unfortunately I don't have any information on the > m5474evb board to know what a config file should look like. I believe the only configuration difference is no data flash but a bigger code flash. > m68k-elf-sprite:Loading section .main_application_data, size 0x40 lma > 0x4000500 > Sent response: 'OK' > m68k-elf-sprite:Got binary X packet: 'X4000500,40...' > m68k-elf-sprite:error:Hardware device not ready > m68k-elf-sprite:Closing P&E device > Remote communication error: No error. > (gdb) I bet that SP (or maybe PC) gets set to an unwanted address causing a bus error. I had this happening to me with the m5475evb. Try editing your linker script and change the stack to something less than max. Good luck, Andreas From dan at codesourcery.com Tue Apr 3 14:15:45 2007 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Tue, 3 Apr 2007 10:15:45 -0400 Subject: [coldfire-gnu-discuss] m68k-elf-sprite cannot talk to Coldfire board In-Reply-To: References: Message-ID: <20070403141542.GF6474@caradoc.them.org> (Thanks for including the -v output - that was very helpful :-) On Mon, Apr 02, 2007 at 03:39:15PM +0200, Kevin Bube wrote: > (gdb) load > m68k-elf-sprite:Got packet: 'qXfer:memory-map:read::0,fff' > Loading section .vector_ram, size 0x420 lma 0x0 > m68k-elf-sprite:Sent response: 'l > > > > > > > ' > m68k-elf-sprite:Got binary X packet: 'X4000500,40...' > m68k-elf-sprite:error:Hardware device not ready > m68k-elf-sprite:Closing P&E device > Remote communication error: No error. > (gdb) Nathan, do we support flash programming on these boards (in 4.1-32)? That's presumably a flash address, but IIRC it would be type="flash" if we supported programming it. -- Daniel Jacobowitz CodeSourcery From nathan at codesourcery.com Tue Apr 3 14:21:02 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Tue, 03 Apr 2007 15:21:02 +0100 Subject: [coldfire-gnu-discuss] m68k-elf-sprite cannot talk to Coldfire board In-Reply-To: <20070403141542.GF6474@caradoc.them.org> References: <20070403141542.GF6474@caradoc.them.org> Message-ID: <461262CE.2010509@codesourcery.com> Daniel Jacobowitz wrote: > (Thanks for including the -v output - that was very helpful :-) >> m68k-elf-sprite:Got binary X packet: 'X4000500,40...' >> m68k-elf-sprite:error:Hardware device not ready >> m68k-elf-sprite:Closing P&E device >> Remote communication error: No error. >> (gdb) > > Nathan, do we support flash programming on these boards (in 4.1-32)? > That's presumably a flash address, but IIRC it would be type="flash" > if we supported programming it. oh, I missed that. Flash programming is not supported in the 4.1-32 release. However, the sprite error is not that. Looking carefully, I see GDB is trying to write to address 04000500, but that's not contained in the memory map -- so there is no memory there. I think it is the P&E bug we encountered with the 5485 board and writing to non-existant memory. We got a bus error, it appears that Kevin gets a more fatal error. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From gristroph at ascendant-es.com Tue Apr 3 18:34:31 2007 From: gristroph at ascendant-es.com (Gunnar Ristroph) Date: Tue, 3 Apr 2007 13:34:31 -0500 Subject: m68k-elf-sprite:libborunwind.so.6.0: cannot open shared object file Message-ID: <47044908AC48E340B328D9EC035719F311048D@bigbark.AES.local> m68k-elf-sprite seems to require a shared library called libborunwind.so.6.0 (needed by programs made with something called Kylix? I don't really know what this library is) $ ./m68k-elf-sprite pe: m5208evb m68k-elf-sprite:libborunwind.so.6.0: cannot open shared object file: No such file or directory m68k-elf-sprite:Cannot load P&E library 'libUnit_cfz.so' m68k-elf-sprite:error:Failed to initialize device I'm sure that libUnit_cfz.so is there (in /usr/lib), so I think second message ("Cannot load P&E library 'libUnit_cfz.so'") is nothing to worry about, I think the first error is actually causing the problem (also I get a different behavior if I delete /usr/lib/libUnit_cfz.so I get the same message with m68k-uclinux-sprite Here is some additional information: ./m68k-elf-sprite --version CodeSourcery ColdFire Debug Sprite (Sourcery G++ Lite 4.1-32) ./m68k-uclinux-sprite --version CodeSourcery ColdFire Debug Sprite (Sourcery G++ Lite 4.1-32) The host system is Debian Linux with kernel version is 2.6.18 I can't find any Debian packages that provide libborunwind.so.6.0 Any help would be appreciated, Gunnar -------------- next part -------------- An HTML attachment was scrubbed... URL: From gristroph at ascendant-es.com Tue Apr 3 18:40:26 2007 From: gristroph at ascendant-es.com (Gunnar Ristroph) Date: Tue, 3 Apr 2007 13:40:26 -0500 Subject: [coldfire-gnu-discuss] m68k-elf-sprite:libborunwind.so.6.0: cannot open shared object file References: <47044908AC48E340B328D9EC035719F311048D@bigbark.AES.local> Message-ID: <47044908AC48E340B328D9EC035719F311048E@bigbark.AES.local> Incidentally, I noticed that it seems like this file should have been including in the sprite-driver, the setup.sh has: cp ../lib/bplrtl.so.6.9.0 /usr/lib/bplrtl.so.6.9.0 fi if [ ! -r /usr/lib/bplvisualclx.so.6.9.0 ] ; then cp ../lib/bplvisualclx.so.6.9.0 /usr/lib/bplvisualclx.so.6.9.0 fi if [ ! -r /usr/lib/libborunwind.so.6.0 ] ; then cp ../lib/libborunwind.so.6.0 /usr/lib/libborunwind.so.6.0 fi if [ ! -x /sbin/wdreg ] ; then cp ../redist/wdreg /sbin/wdreg but the files aren't exactly there these error messages appear: cp: cannot stat `../lib/bplrtl.so.6.9.0': No such file or directory cp: cannot stat `../lib/bplvisualclx.so.6.9.0': No such file or directory cp: cannot stat `../lib/libborunwind.so.6.0': No such file or directory -----Original Message----- From: Gunnar Ristroph [mailto:gristroph at ascendant-es.com] Sent: Tue 4/3/2007 1:34 PM To: coldfire-gnu-discuss at codesourcery.com Subject: [coldfire-gnu-discuss] m68k-elf-sprite:libborunwind.so.6.0: cannot open shared object file m68k-elf-sprite seems to require a shared library called libborunwind.so.6.0 (needed by programs made with something called Kylix? I don't really know what this library is) $ ./m68k-elf-sprite pe: m5208evb m68k-elf-sprite:libborunwind.so.6.0: cannot open shared object file: No such file or directory m68k-elf-sprite:Cannot load P&E library 'libUnit_cfz.so' m68k-elf-sprite:error:Failed to initialize device I'm sure that libUnit_cfz.so is there (in /usr/lib), so I think second message ("Cannot load P&E library 'libUnit_cfz.so'") is nothing to worry about, I think the first error is actually causing the problem (also I get a different behavior if I delete /usr/lib/libUnit_cfz.so I get the same message with m68k-uclinux-sprite Here is some additional information: ./m68k-elf-sprite --version CodeSourcery ColdFire Debug Sprite (Sourcery G++ Lite 4.1-32) ./m68k-uclinux-sprite --version CodeSourcery ColdFire Debug Sprite (Sourcery G++ Lite 4.1-32) The host system is Debian Linux with kernel version is 2.6.18 I can't find any Debian packages that provide libborunwind.so.6.0 Any help would be appreciated, Gunnar -------------- next part -------------- An HTML attachment was scrubbed... URL: From update at yourfreemortgageguide.com Thu Apr 5 07:55:09 2007 From: update at yourfreemortgageguide.com (FreeMortgageGuide) Date: Thu, 05 Apr 2007 07:55:09 Subject: " Is now a good time to review your mortgage deal ? " for coldfire-gnu-discuss@codesourcery.com on Thu, 05 Apr 2007 07:55:09 Message-ID: <20070405065509.10062.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 info at onestopforinternetmarketing.com Fri Apr 6 03:33:37 2007 From: info at onestopforinternetmarketing.com (Gregg & Glenn) Date: 6 Apr 2007 03:33:37 -0000 Subject: Your VIP Invitation Only Pass Message-ID: <20070406033337.1534.qmail@mx0.glcmail.com> I've just put together your VIP internet marketing package. It's worth well over $1,000 but it's yours free when you go to this url. http://www.onestopforinternetmarketing.com I will also be giving you much more valuable information that will help you promote your business online. Over the next couple of years it will become even more crucial to be experienced in online marketing, this is your chance to get ahead of your competition. I have put up a video that talks about my credentials so that you will realize that not only are you getting an incredible package of tools for NOTHING, but you will also have access to someone who has well over 10 years online marketing experience. http://www.onestopforinternetmarketing.com Make sure you watch the video that explains just some of what you're going to get. See You On The Other Side! Gregg P.S. I can only help someone who is willing to help themselves. If you are serious about marketing online we can do a lot to help you. GLC Ventures, Inc. 711 S. Carson Street Ste 4 Carson City, NV 89701 If you wish to stop receiving future emails from us, please go here: http://secure.titancommerce.com/contactdb-public/r.html?id=6936908:PRmyeqhuc:2121269 From nathan at codesourcery.com Fri Apr 6 08:23:27 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Fri, 06 Apr 2007 09:23:27 +0100 Subject: spam messages Message-ID: <4616037F.6050706@codesourcery.com> We're sorry about the recent spam messages that have made it through to the mailing list. We're working on fixing this. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From dan at codesourcery.com Mon Apr 9 11:55:36 2007 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Mon, 9 Apr 2007 07:55:36 -0400 Subject: [coldfire-gnu-discuss] m68k-elf-sprite:libborunwind.so.6.0: cannot open shared object file In-Reply-To: <47044908AC48E340B328D9EC035719F311048E@bigbark.AES.local> References: <47044908AC48E340B328D9EC035719F311048D@bigbark.AES.local> <47044908AC48E340B328D9EC035719F311048E@bigbark.AES.local> Message-ID: <20070409115533.GO6474@caradoc.them.org> On Tue, Apr 03, 2007 at 01:40:26PM -0500, Gunnar Ristroph wrote: > Incidentally, I noticed that it seems like this file should have been including in the sprite-driver, the setup.sh has: > > cp ../lib/bplrtl.so.6.9.0 /usr/lib/bplrtl.so.6.9.0 > fi > if [ ! -r /usr/lib/bplvisualclx.so.6.9.0 ] ; then > cp ../lib/bplvisualclx.so.6.9.0 /usr/lib/bplvisualclx.so.6.9.0 > fi > if [ ! -r /usr/lib/libborunwind.so.6.0 ] ; then > cp ../lib/libborunwind.so.6.0 /usr/lib/libborunwind.so.6.0 > fi > if [ ! -x /sbin/wdreg ] ; then > cp ../redist/wdreg /sbin/wdreg > > but the files aren't exactly there these error messages appear: > > cp: cannot stat `../lib/bplrtl.so.6.9.0': No such file or directory > cp: cannot stat `../lib/bplvisualclx.so.6.9.0': No such file or directory > cp: cannot stat `../lib/libborunwind.so.6.0': No such file or directory I don't remember the details - maybe someone else on the list does - but I believe this was a bug in the latest P&E driver package. Either the libraries are there but the cp command is too early, or else they were in a previous version and omitted from this one. -- Daniel Jacobowitz CodeSourcery From nathan at codesourcery.com Tue Apr 10 08:57:03 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Tue, 10 Apr 2007 09:57:03 +0100 Subject: [coldfire-gnu-discuss] m68k-elf-sprite:libborunwind.so.6.0: cannot open shared object file In-Reply-To: <20070409115533.GO6474@caradoc.them.org> References: <47044908AC48E340B328D9EC035719F311048D@bigbark.AES.local> <47044908AC48E340B328D9EC035719F311048E@bigbark.AES.local> <20070409115533.GO6474@caradoc.them.org> Message-ID: <461B515F.1010602@codesourcery.com> Daniel Jacobowitz wrote: > I don't remember the details - maybe someone else on the list does - > but I believe this was a bug in the latest P&E driver package. Either > the libraries are there but the cp command is too early, or else they > were in a previous version and omitted from this one. I think it was a mixture of both. We're still waiting for an updated linux driver from P&E. Meanwhile, I attach the missing files. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk -------------- next part -------------- A non-text attachment was scrubbed... Name: pe-libs.tgz Type: application/x-compressed-tar Size: 935322 bytes Desc: not available URL: From David.Seymour at freescale.com Tue Apr 10 15:49:12 2007 From: David.Seymour at freescale.com (Seymour David-ra2693) Date: Tue, 10 Apr 2007 08:49:12 -0700 Subject: [coldfire-gnu-discuss] m68k-elf-sprite:libborunwind.so.6.0: cannot open shared object file In-Reply-To: <461B515F.1010602@codesourcery.com> References: <47044908AC48E340B328D9EC035719F311048D@bigbark.AES.local> <47044908AC48E340B328D9EC035719F311048E@bigbark.AES.local> <20070409115533.GO6474@caradoc.them.org> <461B515F.1010602@codesourcery.com> Message-ID: I've been working to get the P&E USBMultilink Linux drivers working on FC3 and SUSE10. I took a clean SUSE10 distribution and then downloaded the latest P&E driver from their web site (Note: had to register for account) called pe_driver_ver_323_2_811.tar.gz. I ran the install as root and when it called ./windriver/redist/configure it had errors finding the referenced within the setup.sh script. So I found where a copy of the header was and added the entire path to the script and re-ran the script. It tripped up in one more location and I add the full path to the to the "/lib/modules/2.6.18.2-34-default/source/include/linux/vermagic.h" which was called from the "make" step. I then re-ran the script. It was then successful. I then installed the CodeSourcery ColdFire ELF GNU tools for Linux, added the following to my .bashrc PATH variable and "source .bashrc". PATH=/home/david/freescale-coldfire-4.1/bin:/home/david/freescale-coldfi re-4.1/m68k-elf/include:/home/david/freescale-coldfire-4.1/m68k-elf/lib: $PATH I then plugged in my USBMultilink cable and executed the "m68k-elf-sprite -i" command (NOTE: Must be root for this to work) and saw the hardware listed. Also when run ddd or m68k-elf-gdb I must be root to access the m68k-elf-sprite drive. I hope P&E can fix it so I can be a normal user. Hope this helps. Regards, David David E Seymour -----Original Message----- From: Nathan Sidwell [mailto:nathan at codesourcery.com] Sent: Tuesday, April 10, 2007 3:57 AM To: Daniel Jacobowitz Cc: Gunnar Ristroph; coldfire-gnu-discuss at codesourcery.com Subject: Re: [coldfire-gnu-discuss] m68k-elf-sprite:libborunwind.so.6.0: cannot open shared object file Daniel Jacobowitz wrote: > I don't remember the details - maybe someone else on the list does - > but I believe this was a bug in the latest P&E driver package. Either > the libraries are there but the cp command is too early, or else they > were in a previous version and omitted from this one. I think it was a mixture of both. We're still waiting for an updated linux driver from P&E. Meanwhile, I attach the missing files. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From kevin.bube at mahr.de Wed Apr 11 08:17:56 2007 From: kevin.bube at mahr.de (Kevin Bube) Date: Wed, 11 Apr 2007 10:17:56 +0200 Subject: [coldfire-gnu-discuss] m68k-elf-sprite cannot talk to Coldfire board References: <46110D3A.9090900@codesourcery.com> Message-ID: "Andreas Engberg" writes: > I bet that SP (or maybe PC) gets set to an unwanted address causing a > bus error. I had this happening to me with the m5475evb. Try editing > your linker script and change the stack to something less than max. Yes, I think you are correct about this. We investigated further and found that SP gets set to 0x40102700 which does not exist. This occurs randomly. We are in an endless loop which does nothing but increment a counter. Sometimes we reach just one iteration, sometimes 10 or more. After we jump to the adress, we end up in the exception handler but never get out, because we hit this adress over and over again. Maybe this is some sort of timing problem, as we can nearly go through the whole application if we use single line stepping in the debugger. I attached the initialisation file for the board. I tried reducing the stack size as suggested, but this did not help either. Regards, Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: test.xml Type: application/xml Size: 1580 bytes Desc: Init URL: From nathan at codesourcery.com Wed Apr 11 09:15:22 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 11 Apr 2007 10:15:22 +0100 Subject: [coldfire-gnu-discuss] m68k-elf-sprite:libborunwind.so.6.0: cannot open shared object file In-Reply-To: References: <47044908AC48E340B328D9EC035719F311048D@bigbark.AES.local> <47044908AC48E340B328D9EC035719F311048E@bigbark.AES.local> <20070409115533.GO6474@caradoc.them.org> <461B515F.1010602@codesourcery.com> Message-ID: <461CA72A.4060106@codesourcery.com> Seymour David-ra2693 wrote: > I then plugged in my USBMultilink cable and executed the > "m68k-elf-sprite -i" command (NOTE: Must be root for this to work) and > saw the hardware listed. > > Also when run ddd or m68k-elf-gdb I must be root to access the > m68k-elf-sprite drive. I hope P&E can fix it so I can be a normal user. We reported this issue to P&E. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From codesourcery at gustad.com Tue Apr 17 14:08:24 2007 From: codesourcery at gustad.com (codesourcery at gustad.com) Date: Tue, 17 Apr 2007 16:08:24 +0200 (CEST) Subject: WELCOME to coldfire-gnu-discuss@codesourcery.com In-Reply-To: <1176807372.21102.ezmlm@codesourcery.com> References: <1176807372.21102.ezmlm@codesourcery.com> Message-ID: <20070417.160824.78479728.petter@filestore.home.gustad.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 clue is to put the text section into the flash. Here's from my linker script: MEMORY { ram (rwx) : ORIGIN = 512M, LENGTH = 32K flash (rx) : ORIGIN = 0, LENGTH = 256K ipsbar (rwx) : ORIGIN = 0x40000000, LENGTH = 0x0 } ... .text : { *(.text .text.*) . = ALIGN(0x4); } > flash as well as the rodata: .rodata : { *(.rodata .rodata.*) . = ALIGN(0x4); } > flash Petter From codesourcery at gustad.com Tue Apr 17 15:30:30 2007 From: codesourcery at gustad.com (codesourcery at gustad.com) Date: Tue, 17 Apr 2007 17:30:30 +0200 (CEST) Subject: Debugging/Running program in internal Flash. In-Reply-To: <20070417.160824.78479728.petter@filestore.home.gustad.com> References: <1176807372.21102.ezmlm@codesourcery.com> <20070417.160824.78479728.petter@filestore.home.gustad.com> Message-ID: <20070417.173030.56861691.petter@filestore.home.gustad.com> From: codesourcery at gustad.com Subject: [coldfire-gnu-discuss] Re: WELCOME to coldfire-gnu-discuss at codesourcery.com Date: Tue, 17 Apr 2007 16:08:24 +0200 (CEST) > >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 clue is to put the text section into the flash. Here's from my > linker script: > > MEMORY > { > ram (rwx) : ORIGIN = 512M, LENGTH = 32K > flash (rx) : ORIGIN = 0, LENGTH = 256K > ipsbar (rwx) : ORIGIN = 0x40000000, LENGTH = 0x0 > } > ... > > .text : > { > *(.text .text.*) > . = ALIGN(0x4); > } > flash > > as well as the rodata: > > .rodata : > { > *(.rodata .rodata.*) > . = ALIGN(0x4); > } > flash > > > Petter That was my first post after joining the mailing list. I simply replied to the first message from the list and forgot to change the subject. Sorry. From Tom.Malnar at christiedigital.com Tue Apr 17 18:06:55 2007 From: Tom.Malnar at christiedigital.com (Malnar, Tom) Date: Tue, 17 Apr 2007 14:06:55 -0400 Subject: Coldfire Toolchain packed structure bug version 4.1.30 and newer Message-ID: <0384B41A03232C45B676D09A0173AB1E51CFBE@cdskitexg01.cds.int> We recently ugraded our tools to version 4.1.30 for the coldfire from 3.4. Our processor is a MCF5475VR266. We noticed a new bug in the assembler code produced when dereferencing a packed structure. 1. The bug occurs in gcc and g++. 2. The bug occurs when using: #pramga pack(1) or __attribute__ ((__packed__,aligned(1))) directives 3. The code was built using the following command line options: gcc -g -Wall -o obj/main.o -c main.c 4. The assembly code was dumped using: m68k-linux-gnu-objdump -lS src/testCode/obj/main.o 5. The code used in our example #include struct TestStruct { unsigned short var1; }; int main() { struct TestStruct varStruct; struct TestStruct *pVarStruct = &varStruct; varStruct.var1 = 1; pVarStruct->var1 = 2; return 0; } 6. The good assembly code produced: src/testCode/obj/main.o: file format elf32-m68k Disassembly of section .text: 00000000
: main(): main.c:7 struct TestStruct { unsigned short var1; }; int main() { 0: 4e56 fff8 linkw %fp,#-8 main.c:9 volatile TestStruct varStruct; volatile TestStruct *pVarStruct = &varStruct; 4: 41ee fffa lea %fp@(-6),%a0 8: 2d48 fffc movel %a0,%fp@(-4) main.c:10 varStruct.var1 = 1; c: 7001 moveq #1,%d0 e: 3d40 fffa movew %d0,%fp@(-6) main.c:11 pVarStruct->var1 = 2; 12: 206e fffc moveal %fp@(-4),%a0 16: 30bc 0002 movew #2,%a0@ main.c:12 return 0; 1a: 4280 clrl %d0 main.c:13 } 1c: 4e5e unlk %fp 1e: 4e75 rts 7. Code that exhibits the issue: #include struct __attribute__ ((__packed__,aligned(1))) TestStruct { unsigned short var1; }; int main() { struct TestStruct varStruct; struct TestStruct *pVarStruct = &varStruct; varStruct.var1 = 1; pVarStruct->var1 = 2; return 0; } 8. The assembly created by the source above. Problem: the deference of the unsigned short variable and move is done in two 1 byte moves, plus there also seems to be a lot of extra assembly instructions. src/testCode/obj/main.o: file format elf32-m68k Disassembly of section .text: 00000000
: main(): main.c:7 struct __attribute__ ((__packed__,aligned(1))) TestStruct { unsigned short var1; }; int main() { 0: 4e56 fff8 linkw %fp,#-8 main.c:9 TestStruct varStruct; TestStruct *pVarStruct = &varStruct; 4: 41ee fffa lea %fp@(-6),%a0 8: 2d48 fffc movel %a0,%fp@(-4) main.c:10 varStruct.var1 = 1; c: 7001 moveq #1,%d0 e: 3d40 fffa movew %d0,%fp@(-6) main.c:11 pVarStruct->var1 = 2; 12: 206e fffc moveal %fp@(-4),%a0 16: 1010 moveb %a0@,%d0 18: 4281 clrl %d1 1a: c081 andl %d1,%d0 1c: 1000 moveb %d0,%d0 1e: 1080 moveb %d0,%a0@ 20: 1028 0001 moveb %a0@(1),%d0 24: 4281 clrl %d1 26: c081 andl %d1,%d0 28: 1000 moveb %d0,%d0 2a: a541 mov3ql #2,%d1 2c: 8081 orl %d1,%d0 2e: 1000 moveb %d0,%d0 30: 1140 0001 moveb %d0,%a0@(1) main.c:12 return 0; 34: 4280 clrl %d0 main.c:13 } 36: 4e5e unlk %fp 38: 4e75 rts 9. One point to add. If we create an unsigned short pointer and assign it to pVarStruct->var1 the assembly code produced when dereferencing the unsigned short pointer is correct. Does anyone have any suggestions on some things we could try? Will this issue be addressed in a future tool chain release? Thanks. - Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlos at codesourcery.com Wed Apr 18 16:15:50 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Wed, 18 Apr 2007 12:15:50 -0400 Subject: [coldfire-gnu-discuss] Coldfire Toolchain packed structure bug version 4.1.30 and newer In-Reply-To: <0384B41A03232C45B676D09A0173AB1E51CFBE@cdskitexg01.cds.int> References: <0384B41A03232C45B676D09A0173AB1E51CFBE@cdskitexg01.cds.int> Message-ID: <20070418161548.GO32515@lios> On Tue, Apr 17, 2007 at 02:06:55PM -0400, Malnar, Tom wrote: > We recently ugraded our tools to version 4.1.30 for the coldfire from 3.4. > Our processor is a MCF5475VR266. > We noticed a new bug in the assembler code produced when dereferencing a > packed structure. > > Does anyone have any suggestions on some things we could try? Will this > issue be addressed in a future tool chain release? Thank you for using Sourcery G++! The workaround in this case is to use: m68k-linux-gnu-gcc -mno-strict-align -g -Wall -c test.c The "-mno-strict-align" tells the compiler to relax the normal m68k alignment requirements. The Coldfire hardware (v2/3/4e) support unaligned loads and store so this should be OK. We will look into this issue. Thanks! Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From Tom.Malnar at christiedigital.com Wed Apr 18 21:30:56 2007 From: Tom.Malnar at christiedigital.com (Malnar, Tom) Date: Wed, 18 Apr 2007 17:30:56 -0400 Subject: [coldfire-gnu-discuss] Coldfire Toolchain packed structure bug version 4.1.30 and newer In-Reply-To: <20070418161548.GO32515@lios> Message-ID: <0384B41A03232C45B676D09A0173AB1E51CFD0@cdskitexg01.cds.int> Thank Carlos, I really appreciate the quick follow up. I just wanted to mention (may help your investigation) that there may be two issues. The assembly actually produced when the alignment was 1 is very bad. I assume when alignment was 1 that my 'short' variable was treated as two bytes. To move two bytes, something like: moveal %fp@(-4),%a0 clrl %d0 moveb %d0,%a0@ mov3ql #2,%d0 moveb %d0,%a0@(1) would do the job. The code it produced was: 12: 206e fffc moveal %fp@(-4),%a0 16: 1010 moveb %a0@,%d0 18: 4281 clrl %d1 1a: c081 andl %d1,%d0 1c: 1000 moveb %d0,%d0 1e: 1080 moveb %d0,%a0@ 20: 1028 0001 moveb %a0@(1),%d0 24: 4281 clrl %d1 26: c081 andl %d1,%d0 28: 1000 moveb %d0,%d0 2a: a541 mov3ql #2,%d1 2c: 8081 orl %d1,%d0 2e: 1000 moveb %d0,%d0 30: 1140 0001 moveb %d0,%a0@(1) Not sure if the issues are related or not, but it should probably be investigated. Thanks again. -----Original Message----- From: Carlos O'Donell [mailto:carlos at codesourcery.com] Sent: April 18, 2007 12:16 PM To: Malnar, Tom Cc: coldfire-gnu-discuss at codesourcery.com; Nathan Sidwell Subject: Re: [coldfire-gnu-discuss] Coldfire Toolchain packed structure bug version 4.1.30 and newer On Tue, Apr 17, 2007 at 02:06:55PM -0400, Malnar, Tom wrote: > We recently ugraded our tools to version 4.1.30 for the coldfire from 3.4. > Our processor is a MCF5475VR266. > We noticed a new bug in the assembler code produced when dereferencing a > packed structure. > > Does anyone have any suggestions on some things we could try? Will this > issue be addressed in a future tool chain release? Thank you for using Sourcery G++! The workaround in this case is to use: m68k-linux-gnu-gcc -mno-strict-align -g -Wall -c test.c The "-mno-strict-align" tells the compiler to relax the normal m68k alignment requirements. The Coldfire hardware (v2/3/4e) support unaligned loads and store so this should be OK. We will look into this issue. Thanks! Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From carlos at codesourcery.com Wed Apr 18 22:16:26 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Wed, 18 Apr 2007 18:16:26 -0400 Subject: [coldfire-gnu-discuss] Coldfire Toolchain packed structure bug version 4.1.30 and newer In-Reply-To: <0384B41A03232C45B676D09A0173AB1E51CFD0@cdskitexg01.cds.int> References: <20070418161548.GO32515@lios> <0384B41A03232C45B676D09A0173AB1E51CFD0@cdskitexg01.cds.int> Message-ID: <20070418221626.GR32515@lios> On Wed, Apr 18, 2007 at 05:30:56PM -0400, Malnar, Tom wrote: > Thank Carlos, I really appreciate the quick follow up. > > I just wanted to mention (may help your investigation) that there may be > two issues. > > The assembly actually produced when the alignment was 1 is very bad. > I assume when alignment was 1 that my 'short' variable was treated as > two bytes. To move two bytes, something like: > > moveal %fp@(-4),%a0 > clrl %d0 > moveb %d0,%a0@ > mov3ql #2,%d0 > moveb %d0,%a0@(1) > > would do the job. The code it produced was: > > 12: 206e fffc moveal %fp@(-4),%a0 > 16: 1010 moveb %a0@,%d0 > 18: 4281 clrl %d1 > 1a: c081 andl %d1,%d0 > 1c: 1000 moveb %d0,%d0 > 1e: 1080 moveb %d0,%a0@ > 20: 1028 0001 moveb %a0@(1),%d0 > 24: 4281 clrl %d1 > 26: c081 andl %d1,%d0 > 28: 1000 moveb %d0,%d0 > 2a: a541 mov3ql #2,%d1 > 2c: 8081 orl %d1,%d0 > 2e: 1000 moveb %d0,%d0 > 30: 1140 0001 moveb %d0,%a0@(1) > > Not sure if the issues are related or not, but it should probably be > investigated. You need to turn on the compiler optimizations with "-O1" or higher if you want optimized code. If at "-O1" or higher you continue to see cases where the compiler is doing a poor job please report them to the list and we will look at them. Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716