From paul.mcconkey at cambridgeimaging.co.uk Fri Jun 1 17:16:21 2007 From: paul.mcconkey at cambridgeimaging.co.uk (Paul McConkey) Date: Fri, 1 Jun 2007 18:16:21 +0100 Subject: [coldfire-gnu-discuss] Interrupt Handler In-Reply-To: References: Message-ID: <59789F6B85725F4CAD78243CDDBA4C663A9724@SERVA.grange.local> This is what I do for MCF5282: __attribute__((interrupt_handler)) void some_isr() { } Cheers, Paul. -----Original Message----- From: Paul Georgief [mailto:pgeorgief at ucsd.edu] Sent: 31 May 2007 06:18 To: coldfire-gnu-discuss at codesourcery.com Subject: [coldfire-gnu-discuss] Interrupt Handler I have some old code I wrote on Codewarrior and have been moving it over to gcc. But, I'm stuck! I'm trying to write my ISR in C and have been having a problem figuring out the syntax used to implement the ISR. I've tried: /* The old(?) GCC way that I'm used to */ void __attribute__ ((interrupt)) my_Foo_ISR (void) { } /* The Codewarrior way */ __interrupt__ void my_Foo_ISR (void) { } /* Another GCC way -- specific to another chip */ interrupt (interruptX) my_Foo_ISR (void) { } and a few other weird attempts.... Either GCC says it ignores the syntax or it stops and says there is an error. I give up - what is the proper way? Is there an example that is available somewhere specifically showing this for the coldfire g++ port? Also, I've read the getting started manual (regarding the interrupts) - and it confused me. I know it'll make perfect sense once I see an example, but right now it is quite confusing. I have the following setup: Windows Host (XP) Sourcery G++ 4.1-39 ELF Version Target: mcf5235 Any help would be appreciated! Thank You, Paul From mwanaag at yahoo.com Fri Jun 1 23:17:07 2007 From: mwanaag at yahoo.com (santosh dwivedi) Date: Fri, 1 Jun 2007 16:17:07 -0700 (PDT) Subject: code warrior Library Linking with m68k-elf-gcc In-Reply-To: <59789F6B85725F4CAD78243CDDBA4C663A9724@SERVA.grange.local> Message-ID: <451665.9763.qm@web52112.mail.re2.yahoo.com> Hello Developers, "I am trying to use a library(This library is works well with code warrior on coldfire) with my application on coldfire. When I try to link this library to application ,I get assertion error in m68k-elf-gcc binutil tool chain /bfd/elf.c" Below is error output. My coldfire processor is MFC5280, I am using uCLinux. "---> main.c: In function `main': main.c:13: warning: `ch' might be used uninitialized in this function /usr/local/m68k-elf/bin/ld.real: bfd assertion fail ../../binutils-2.10/bfd/elf.c:1346 /usr/local/m68k-elf/bin/ld.real: bfd assertion fail ../../binutils-2.10/bfd/elf.c:1346 /usr/local/m68k-elf/bin/ld.real: bfd assertion fail ../../binutils-2.10/bfd/elf.c:1346 /usr/local/m68k-elf/bin/ld.real: bfd assertion fail ../../binutils-2.10/bfd/elf.c:1346 /usr/local/m68k-elf/bin/ld.real: bfd assertion fail ../../binutils-2.10/bfd/elf.c:1346 /home/sans/delnetMFC5280/MAC/802.15.4/mcf5282_802154/src/vb_zigbee_macphy/Source/libM5282_802154_Type_FFD.a: could not read symbols: Archive has no index; run ranlib to add one collect2: ld returned 1 exit status----<" To find out what is wrong I made my own small library with a function inside, and then tried to compile and link my application with it, all well fine and I was able to execute the program. I tried to use ranlib but same assertion error I get always. I tried to extract object files in library with ar , i get some object files by doing so but with assertion error. Is there something special with codewarrior library ? why it cant be linked with my application with m68-elf-gcc? Thanks for some suggestions to resolve this issue. Cheers Santosh ____________________________________________________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz From nathan at codesourcery.com Sat Jun 2 08:50:38 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Sat, 02 Jun 2007 09:50:38 +0100 Subject: [coldfire-gnu-discuss] Interrupt Handler In-Reply-To: <59789F6B85725F4CAD78243CDDBA4C663A9724@SERVA.grange.local> References: <59789F6B85725F4CAD78243CDDBA4C663A9724@SERVA.grange.local> Message-ID: <46612F5E.6000309@codesourcery.com> Paul McConkey wrote: > > This is what I do for MCF5282: > > __attribute__((interrupt_handler)) > void > some_isr() > { > } Yes. Some GCC targets use 'interrupt' and some use 'interrupt_handler', which is unfortunate. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From mark at codesourcery.com Sun Jun 3 23:55:48 2007 From: mark at codesourcery.com (Mark Mitchell) Date: Sun, 03 Jun 2007 16:55:48 -0700 Subject: [coldfire-gnu-discuss] code warrior Library Linking with m68k-elf-gcc In-Reply-To: <451665.9763.qm@web52112.mail.re2.yahoo.com> References: <451665.9763.qm@web52112.mail.re2.yahoo.com> Message-ID: <46635504.1080801@codesourcery.com> santosh dwivedi wrote: > Is there something special with codewarrior library ? > why it cant be linked with my application with > m68-elf-gcc? Certainly, the BFD assertion error indicates that something about the archive doesn't match binutils expectation. However, it doesn't look like you're using Sourcery G++: we've never used Binutils 2.10 for ColdFire. So, you might want to start by downloading our toolchains; it's possible that the version of Binutils either works or provides a better error message. -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From mwanaag at yahoo.com Mon Jun 4 17:40:28 2007 From: mwanaag at yahoo.com (santosh dwivedi) Date: Mon, 4 Jun 2007 10:40:28 -0700 (PDT) Subject: [coldfire-gnu-discuss] code warrior Library Linking with m68k-elf-gcc In-Reply-To: <46635504.1080801@codesourcery.com> Message-ID: <850872.50735.qm@web52109.mail.re2.yahoo.com> Dear Mark, You are right i was using binutils. Now I downloaded CodeSourcy G++ and tried to link the same library with it. I downloaded CodeSourcy G++ for windows host as well for Linux host. On Linux host I got again assertion error. But Windows Host was little bit better. Here is compilation output for both the hosts First Linux. How to fix it? is it impossible to link codewarrior Library for coldfore with uCLinux? Here is output of compilation: ******************************************************* In file included from /home/sans/delnetMFC5280/MAC/802.15.4/mcf5282_802154/src/cpu/mcf5282.h:31, from /home/sans/delnetMFC5280/MAC/802.15.4/mcf5282_802154/src/common/common.h:27, from main.c:7: /home/sans/delnetMFC5280/MAC/802.15.4/mcf5282_802154/src/cpu/headers/mcf5282_gpio.h:241:7: warning: no newline at end of file main.c: In function 'main': main.c:15: warning: 'ch' is used uninitialized in this function /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /home/sans/CodeSourcery/Sourcery_G++/m68k-uclinux/bin/ld.real: BFD (Sourcery G++ 4.2-9) 2.17 assertion fail /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 /tmp/ccigxvF8.o: In function `main': main.c:(.text+0xc): undefined reference to `asm_set_ipl' collect2: ld returned 1 exit status ******************************************************* ?????????????? Below Compilation by CodeSourcy on windows host machine. ************************************************ $ m68k-uclinux-gcc.exe -I. -Wall -m5307 -Os main.c -o pgm -Wl,-elf2flt,-static -L. -lM5282_802154_Type_FFD -lMAC -lc main.c:7:20: error: common.h: No such file or directory main.c: In function 'main': main.c:30: warning: implicit declaration of function 'asm_set_ipl' main.c:32: warning: implicit declaration of function 'printf' main.c:32: warning: incompatible implicit declaration of built-in function 'printf' ************************************************* >>In This one no assertion fail. Best Regards: Santosh --- Mark Mitchell wrote: > santosh dwivedi wrote: > > > Is there something special with codewarrior > library ? > > why it cant be linked with my application with > > m68-elf-gcc? > > Certainly, the BFD assertion error indicates that > something about the > archive doesn't match binutils expectation. > However, it doesn't look > like you're using Sourcery G++: we've never used > Binutils 2.10 for > ColdFire. So, you might want to start by > downloading our toolchains; > it's possible that the version of Binutils either > works or provides a > better error message. > > -- > Mark Mitchell > CodeSourcery > mark at codesourcery.com > (650) 331-3385 x713 > ____________________________________________________________________________________ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ From carlos at codesourcery.com Mon Jun 4 20:06:27 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Mon, 4 Jun 2007 16:06:27 -0400 Subject: [coldfire-gnu-discuss] code warrior Library Linking with m68k-elf-gcc In-Reply-To: <850872.50735.qm@web52109.mail.re2.yahoo.com> References: <46635504.1080801@codesourcery.com> <850872.50735.qm@web52109.mail.re2.yahoo.com> Message-ID: <20070604200626.GH16097@lios> On Mon, Jun 04, 2007 at 10:40:28AM -0700, santosh dwivedi wrote: > How to fix it? is it impossible to link codewarrior > Library for coldfore with uCLinux? > /scratch/nathan/cf-uclinux-4.2/obj/binutils-src-4.2-9-m68k-uclinux-i686-pc-linux-gnu/bfd/elf.c:2101 > /tmp/ccigxvF8.o: In function `main': > main.c:(.text+0xc): undefined reference to > `asm_set_ipl' > collect2: ld returned 1 exit status Santosh, It appears that the output files generated by CodeWarrior uses some facilities in ELF that binutils is unable to process. Are you able to rebuild the object files using only Sourcery G++? Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From syakovlev at thinksrs.com Fri Jun 1 17:00:26 2007 From: syakovlev at thinksrs.com (Sergei Yakovlev) Date: Fri, 01 Jun 2007 10:00:26 -0700 Subject: default hardware init in cf-crt0.s Message-ID: <466050AA.5080805@thinksrs.com> Where do I find default implementation of function __early_hardware_init_hook that is called within cf-crt0.s ? Thx. Sergei. From carlos at codesourcery.com Tue Jun 5 19:21:40 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Tue, 5 Jun 2007 15:21:40 -0400 Subject: [coldfire-gnu-discuss] default hardware init in cf-crt0.s In-Reply-To: <466050AA.5080805@thinksrs.com> References: <466050AA.5080805@thinksrs.com> Message-ID: <20070605192138.GA22482@lios> On Fri, Jun 01, 2007 at 10:00:26AM -0700, Sergei Yakovlev wrote: > Where do I find default implementation of function > __early_hardware_init_hook > that is called within cf-crt0.s ? The default implementation of __early_hardware_init_hook is at the bottom of the file (cf-crt0.S). Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From syakovlev at thinksrs.com Sat Jun 2 21:11:38 2007 From: syakovlev at thinksrs.com (Sergei Yakovlev) Date: Sat, 02 Jun 2007 14:11:38 -0700 Subject: makefile.init & makefile.defs Where are they? Message-ID: <4661DD0A.6040109@thinksrs.com> In automatically-generated makefile one can see lines: -include ../makefile.init and -include ../makefile.defs Where do I find these files? Thx. Sergei From carlos at codesourcery.com Thu Jun 7 14:32:44 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Thu, 7 Jun 2007 10:32:44 -0400 Subject: [coldfire-gnu-discuss] makefile.init & makefile.defs Where are they? In-Reply-To: <4661DD0A.6040109@thinksrs.com> References: <4661DD0A.6040109@thinksrs.com> Message-ID: <20070607143244.GK22482@lios> On Sat, Jun 02, 2007 at 02:11:38PM -0700, Sergei Yakovlev wrote: > In automatically-generated makefile one can see lines: > -include ../makefile.init > and > -include ../makefile.defs > Where do I find these files? They are automatically created and removed by the Sourcery G++ IDE. If you want full control over your Makefile you can use a "Standard Make" project. Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From petter at network-electronics.com Wed Jun 13 08:42:17 2007 From: petter at network-electronics.com (Petter) Date: Wed, 13 Jun 2007 10:42:17 +0200 Subject: Jump from assembly to C problem with boot code on MCF52233 Message-ID: <1181724137.20404.47.camel@pn-ubuntu> Hello, I am in the process of making a boot-code for field flash upgrade of the MCF52233. The MCF52235EVB is "compatible" with our product, and the software without boot-code is similar to this: http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&thread.id=2553 (which is a minimal TCP/IP stack without a RTOS running from flash on the MCF52235EVB, and can be compiled with the CodeSourcery toolchain) My problem occurs when jumping from assembly to C language in the application-code (boot-code runs initially and does this "switch" flawlessly). The output from gdb and my debugger (BDI2000) at the problem location: ----- 8< ----- 8< ----- (gdb) monitor rd D0 : 00000000 00000000 00000030 00000006 D4 : 00000018 a661a87d c40f9216 56d33015 A0 : 00000000 44035a4c 200000fc 401d0024 A4 : 1d047492 667d0fa0 00000000 20007ff0 PC : 00027fac SR : 00002704 (gdb) monitor info Target state : debug mode Debug entry cause : single step Current PC : 0x00027fac (gdb) monitor ti Target state : debug mode Debug entry cause : single step Current PC : 0x00000466 (gdb) monitor rd D0 : 00000000 00000000 00000030 00000006 D4 : 00000018 a661a87d c40f9216 56d33015 A0 : 00000000 44035a4c 200000fc 401d0024 A4 : 1d047492 667d0fa0 00000000 20007fe8 PC : 00000466 SR : 00002704 (gdb) ----- 8< ----- 8< ----- The code at 0x466 is the default vector handler for the boot-code, and seems to be related to an exception. The RAM vector table for the application-code (with exception "decoding") has not been set up yet. The disassembly before and after the jump: ----- 8< ----- 8< ----- 1001c: 7000 moveq #0,%d0 1001e: 7200 moveq #0,%d1 10020: 2f08 movel %a0,%sp at - 10022: 2f00 movel %d0,%sp at - 10024: 2f01 movel %d1,%sp at - 10026: 2f0e movel %fp,%sp at - 10028: 4ef9 0002 7fac jmp 27fac <__start1> ----- 8< ----- 8< ----- 00027fac <__start1>: 27fac: 4e56 fffc linkw %fp,#-4 27fb0: 2f02 movel %d2,%sp at - 27fb2: 203c 0003 5550 movel #218448,%d0 27fb8: 0c80 2000 0000 cmpil #536870912,%d0 27fbe: 672e beqs 27fee <__start1+0x42> ----- 8< ----- 8< ----- Here is some parts of relevant pieces in the linker script (... indicates removed stuff): ----- 8< ----- 8< ----- OUTPUT_ARCH(m68k) ENTRY(__start) SEARCH_DIR(.) __DYNAMIC = 0; MEMORY { rom (rx) : ORIGIN = 64K, LENGTH = 192K ram (rwx) : ORIGIN = 512M, LENGTH = 32K bootloader (rx) : ORIGIN = 0K, LENGTH = 48K bootconst (rx) : ORIGIN = 48K, LENGTH = 16K } PROVIDE (__stack = ORIGIN (ram) + LENGTH (ram)); ... SECTIONS { .text : { CREATE_OBJECT_SYMBOLS *(.app_start .app_start.*) *(.text .text.*) *(.gnu.linkonce.t.*) ... . = ALIGN(0x4); __INIT_SECTION__ = . ; LONG (0x4e560000) /* linkw %fp,#0 */ *(.init) SHORT (0x4e5e) /* unlk %fp */ SHORT (0x4e75) /* rts */ . = ALIGN(0x4); __FINI_SECTION__ = . ; LONG (0x4e560000) /* linkw %fp,#0 */ *(.fini) SHORT (0x4e5e) /* unlk %fp */ SHORT (0x4e75) /* rts */ *(.lit) . = ALIGN(4); _etext = .; } >rom ... .bootloader : { __interrupt_vector_boot = .; cf-boot.o(.bootloader) *(.bootloader .bootloader.*) } >bootloader .bootconst : { *(.bootconst .bootconst.*) } >bootconst } ----- 8< ----- 8< ----- Did I miss something regarding the linkw instruction in the linker script? Or is some assembly magic required before the jump? From nathan at codesourcery.com Wed Jun 13 08:57:43 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 13 Jun 2007 09:57:43 +0100 Subject: [coldfire-gnu-discuss] Jump from assembly to C problem with boot code on MCF52233 In-Reply-To: <1181724137.20404.47.camel@pn-ubuntu> References: <1181724137.20404.47.camel@pn-ubuntu> Message-ID: <466FB187.1080000@codesourcery.com> Petter wrote: > Hello, > > I am in the process of making a boot-code for field flash upgrade of the > MCF52233. The MCF52235EVB is "compatible" with our product, and the > software without boot-code is similar to this: > http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&thread.id=2553 > (which is a minimal TCP/IP stack without a RTOS running from flash on > the MCF52235EVB, and can be compiled with the CodeSourcery toolchain) > > My problem occurs when jumping from assembly to C language in the > application-code (boot-code runs initially and does this "switch" > flawlessly). > > The output from gdb and my debugger (BDI2000) at the problem location: > ----- 8< ----- 8< ----- > (gdb) monitor rd > D0 : 00000000 00000000 00000030 00000006 > D4 : 00000018 a661a87d c40f9216 56d33015 > A0 : 00000000 44035a4c 200000fc 401d0024 > A4 : 1d047492 667d0fa0 00000000 20007ff0 > PC : 00027fac SR : 00002704 > (gdb) monitor info > Target state : debug mode > Debug entry cause : single step > Current PC : 0x00027fac > (gdb) monitor ti > Target state : debug mode > Debug entry cause : single step > Current PC : 0x00000466 > (gdb) monitor rd > D0 : 00000000 00000000 00000030 00000006 > D4 : 00000018 a661a87d c40f9216 56d33015 > A0 : 00000000 44035a4c 200000fc 401d0024 > A4 : 1d047492 667d0fa0 00000000 20007fe8 > PC : 00000466 SR : 00002704 > (gdb) > ----- 8< ----- 8< ----- > > The code at 0x466 is the default vector handler for the boot-code, and > seems to be related to an exception. The RAM vector table for the > application-code (with exception "decoding") has not been set up yet. I'm guessing it's just indirected via an uninitialized vector. > Did I miss something regarding the linkw instruction in the linker > script? Or is some assembly magic required before the jump? I can't see anything obviously wrong. In taking the exception it has pushed some information onto the stack frame -- what exeption was taken? 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 Wed Jun 13 09:46:23 2007 From: petter at network-electronics.com (Petter) Date: Wed, 13 Jun 2007 11:46:23 +0200 Subject: [coldfire-gnu-discuss] Jump from assembly to C problem with boot code on MCF52233 In-Reply-To: <466FB187.1080000@codesourcery.com> References: <1181724137.20404.47.camel@pn-ubuntu> <466FB187.1080000@codesourcery.com> Message-ID: <1181727983.20404.68.camel@pn-ubuntu> On Wed, 2007-06-13 at 09:57 +0100, Nathan Sidwell wrote: > > Did I miss something regarding the linkw instruction in the linker > > script? Or is some assembly magic required before the jump? > > I can't see anything obviously wrong. In taking the exception it has > pushed > some information onto the stack frame -- what exeption was taken? Hm. Good question. The exception description of exception stack frames in the M68000 programmers reference manual seems a bit complicated and does not make sense at this point. Does this information help? ----- 8< ----- 8< ----- (gdb) monitor ti Target state : debug mode Debug entry cause : single step Current PC : 0x00010028 (gdb) x /8w 0x20007fe0 0x20007fe0: 0x00000152 0x00000000 0x401d0002 0x44035a3c 0x20007ff0: 0x00000000 0x00000000 0x00000000 0x00000000 (gdb) monitor ti Target state : debug mode Debug entry cause : single step Current PC : 0x00027fac (gdb) monitor ti Target state : debug mode Debug entry cause : single step Current PC : 0x00000466 (gdb) monitor rd D0 : 00000000 00000000 00000030 00000006 D4 : 00000018 a661a87d c40f9216 56d33015 A0 : 00000000 44035a4c 200000fc 401d0024 A4 : 1d047492 667d0fa0 00000000 20007fe8 PC : 00000466 SR : 00002704 (gdb) x /8w 0x20007fe0 0x20007fe0: 0x00000152 0x00000000 0x44082704 0x00027fac 0x20007ff0: 0x00000000 0x00000000 0x00000000 0x00000000 (gdb) ----- 8< ----- 8< ----- In the stack dump, 0x2704 seems to be the status register, and 0x00027fac should be the program counter. But 0x4408? Oh! I need to move on to the ColdFire reference manual :-) From petter at network-electronics.com Thu Jun 14 10:42:59 2007 From: petter at network-electronics.com (Petter) Date: Thu, 14 Jun 2007 12:42:59 +0200 Subject: [coldfire-gnu-discuss] Jump from assembly to C problem withboot code on MCF52233 In-Reply-To: <1181727983.20404.68.camel@pn-ubuntu> References: <1181724137.20404.47.camel@pn-ubuntu> <466FB187.1080000@codesourcery.com> <1181727983.20404.68.camel@pn-ubuntu> Message-ID: <1181817779.3094.18.camel@pn-ubuntu> An HTML attachment was scrubbed... URL: From syakovlev at thinksrs.com Fri Jun 15 21:41:51 2007 From: syakovlev at thinksrs.com (Sergei Yakovlev) Date: Fri, 15 Jun 2007 14:41:51 -0700 Subject: Is Lite v4.2-15 available? Message-ID: <4673079F.1050606@thinksrs.com> Is CodeSourcery Lite edition v4.2-15 available for download? Thx, Sergei. From mark at codesourcery.com Fri Jun 15 22:04:43 2007 From: mark at codesourcery.com (Mark Mitchell) Date: Fri, 15 Jun 2007 15:04:43 -0700 Subject: [coldfire-gnu-discuss] Is Lite v4.2-15 available? In-Reply-To: <4673079F.1050606@thinksrs.com> References: <4673079F.1050606@thinksrs.com> Message-ID: <46730CFB.5040902@codesourcery.com> Sergei Yakovlev wrote: > Is CodeSourcery Lite edition v4.2-15 available for download? No, Sourcery G++ 4.2-15 is a subscriber-only release. There is no Lite Edition version of that release. -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From syakovlev at thinksrs.com Fri Jun 15 23:04:14 2007 From: syakovlev at thinksrs.com (Sergei Yakovlev) Date: Fri, 15 Jun 2007 16:04:14 -0700 Subject: Does exist dongle locked license? Message-ID: <46731AEE.6080004@thinksrs.com> Does exist dongle locked license for CodeSourcery G++? Thx, Sergei. From mark at codesourcery.com Fri Jun 15 23:48:18 2007 From: mark at codesourcery.com (Mark Mitchell) Date: Fri, 15 Jun 2007 16:48:18 -0700 Subject: [coldfire-gnu-discuss] Does exist dongle locked license? In-Reply-To: <46731AEE.6080004@thinksrs.com> References: <46731AEE.6080004@thinksrs.com> Message-ID: <46732542.8080304@codesourcery.com> Sergei Yakovlev wrote: > Does exist dongle locked license for CodeSourcery G++? No, there does not. Sergei, this list is for users of Sourcery G++ Lite Edition. If you have questions about Personal and Professional Edition, please send mail to support at codesourcery.com. -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From kbsu-4 at energomera.ru Wed Jun 20 19:26:49 2007 From: kbsu-4 at energomera.ru (kbsu-4) Date: Wed, 20 Jun 2007 12:26:49 -0700 Subject: Lost promt In-Reply-To: <1271904129.20070620121946@energomera.ru> References: <1271904129.20070620121946@energomera.ru> Message-ID: <1203579761.20070620122649@energomera.ru> Hi, I working with CodeSoucery Lite (in the Windows). I connect my board (With MCF5271) to gdb with next : target remote | m68k-elf-sprite pe://ParallelPortCable 5271m load And next : break init_main continue Gdb connect to board, come to the debugging mode (I can step my programm), but lost promt in the Console window. When I type command to Console window I cannot get any action. When I make mistake? -- Sergey From nathan at codesourcery.com Wed Jun 20 08:50:34 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 20 Jun 2007 09:50:34 +0100 Subject: [coldfire-gnu-discuss] Lost promt In-Reply-To: <1203579761.20070620122649@energomera.ru> References: <1271904129.20070620121946@energomera.ru> <1203579761.20070620122649@energomera.ru> Message-ID: <4678EA5A.4070301@codesourcery.com> kbsu-4 wrote: > Hi, > I working with CodeSoucery Lite (in the Windows). > I connect my board (With MCF5271) to gdb with next : > > target remote | m68k-elf-sprite pe://ParallelPortCable 5271m > load > > And next : > > break init_main > continue > > Gdb connect to board, come to the debugging mode (I can step my > programm), but lost promt in the Console window. > When I type command to Console window I cannot get any action. > When I make mistake? We need a log of your gdb session to understand what is happening. What are the exact commands you typed to gdb, and what are its exact responses? nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From kbsu-4 at energomera.ru Wed Jun 20 20:07:58 2007 From: kbsu-4 at energomera.ru (kbsu-4) Date: Wed, 20 Jun 2007 13:07:58 -0700 Subject: Lost promt In-Reply-To: <1203579761.20070620122649@energomera.ru> References: <1271904129.20070620121946@energomera.ru> <1203579761.20070620122649@energomera.ru> Message-ID: <374471586.20070620130758@energomera.ru> Where can I get this log from CodeSoucery? P.S. I type all commands by "Open source Coldfire IDE Set up and configuration guide" (file "Coldfire IDE.pdf"), but I supply my commands in the and in the "Run\Debug\" dialog "Commands" tab. -- Sergey From nathan at codesourcery.com Wed Jun 20 09:19:32 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 20 Jun 2007 10:19:32 +0100 Subject: [coldfire-gnu-discuss] Lost promt In-Reply-To: <374471586.20070620130758@energomera.ru> References: <1271904129.20070620121946@energomera.ru> <1203579761.20070620122649@energomera.ru> <374471586.20070620130758@energomera.ru> Message-ID: <4678F124.308@codesourcery.com> kbsu-4 wrote: > Where can I get this log from CodeSoucery? > > P.S. I type all commands by "Open source Coldfire IDE > Set up and configuration guide" (file "Coldfire IDE.pdf"), but > I supply my commands in the and in > the "Run\Debug\" dialog "Commands" tab. Are you using Sourcery G++ Lite with an IDE? The Lite version is only supported from the command line. The non-lite versions of Sourcery G++ come with the Eclipse IDE and the debug launching is integrated into that. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From kbsu-4 at energomera.ru Wed Jun 20 20:29:32 2007 From: kbsu-4 at energomera.ru (kbsu-4) Date: Wed, 20 Jun 2007 13:29:32 -0700 Subject: Lost promt Message-ID: <626374586.20070620132932@energomera.ru> I load and install all software by file "Coldfire IDE.pdf" (sections file "How to get the software" and "Installing the software"). Installation file for CodeSoucery is "freescale-coldfire-4.1-32-m68k-elf.exe". From nathan at codesourcery.com Wed Jun 20 09:46:48 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 20 Jun 2007 10:46:48 +0100 Subject: [coldfire-gnu-discuss] Lost promt In-Reply-To: <626374586.20070620132932@energomera.ru> References: <626374586.20070620132932@energomera.ru> Message-ID: <4678F788.1030304@codesourcery.com> kbsu-4 wrote: > I load and install all software by file "Coldfire IDE.pdf" (sections > file "How to get the software" and "Installing the software"). > Installation file for CodeSoucery is "freescale-coldfire-4.1-32-m68k-elf.exe". 4.1-32 does not include eclipse. There is no 'Coldfire IDE.pdf' file in our distribution. The section titles you mention do not appear in the getting-started.pdf guide. Where did you obtain the software? furthermore, 4.1-32 is no longer supported. The current Sourcery G++ Lite release is 4.2-8, which you may obtain from http://www.codesourcery.com/gnu_toolchains/coldfire nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From kbsu-4 at energomera.ru Wed Jun 20 21:04:31 2007 From: kbsu-4 at energomera.ru (kbsu-4) Date: Wed, 20 Jun 2007 14:04:31 -0700 Subject: Lost promt Message-ID: <326127375.20070620140431@energomera.ru> 'Coldfire IDE.pdf' I get from http://www.cambridgeimaging.co.uk/wp_open-source-coldfire-ide.php. and IDE I get from http://www.codesourcery.com/gnu_toolchains/coldfire/releases.html. From nathan at codesourcery.com Wed Jun 20 10:17:16 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 20 Jun 2007 11:17:16 +0100 Subject: [coldfire-gnu-discuss] Lost promt In-Reply-To: <326127375.20070620140431@energomera.ru> References: <326127375.20070620140431@energomera.ru> Message-ID: <4678FEAC.5000107@codesourcery.com> kbsu-4 wrote: > 'Coldfire IDE.pdf' I get from > http://www.cambridgeimaging.co.uk/wp_open-source-coldfire-ide.php. Please contact cambridgeimaging about their instructions. > and IDE I get from > http://www.codesourcery.com/gnu_toolchains/coldfire/releases.html. where did you get the IDE? the version you named 4.1-32 has no IDE. The combination of software you appear to be trying to use, is not supported. If you want support, please use the full version of Sourcery G++. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From paul.mcconkey at cambridgeimaging.co.uk Wed Jun 20 10:52:47 2007 From: paul.mcconkey at cambridgeimaging.co.uk (Paul McConkey) Date: Wed, 20 Jun 2007 11:52:47 +0100 Subject: [coldfire-gnu-discuss] Lost promt In-Reply-To: <4678FEAC.5000107@codesourcery.com> References: <326127375.20070620140431@energomera.ru> <4678FEAC.5000107@codesourcery.com> Message-ID: <59789F6B85725F4CAD78243CDDBA4C663A9D35@SERVA.grange.local> Hi kbsu-4 wrote: > 'Coldfire IDE.pdf' I get from > http://www.cambridgeimaging.co.uk/wp_open-source-coldfire-ide.php. I'm responsible for this document and as I have no wish to tread on CodeSourcery's toes I'd like to point out the paragraph on support: "One of the best value packages around has to be that offered by CodeSourcery - as well as distributing their open-source GNU tool chains for free, they will also license you a full-featured Eclipse-based package which comes with full support for a very reasonable price. Their version of Eclipse also supports managed make files so you will not have to climb the almost vertical learning curve for GNU Make!". BTW I haven't seen the full version, but I'm basing my opinion on the quality of the Lite version. In case this isn't clear enough: If you need a supported toolchain and IDE, you need to get the full version of Sourcery G++, and you need to pay the very reasonable fee for it. Cheers, Paul. From mark at codesourcery.com Wed Jun 20 15:48:02 2007 From: mark at codesourcery.com (Mark Mitchell) Date: Wed, 20 Jun 2007 08:48:02 -0700 Subject: [coldfire-gnu-discuss] Lost promt In-Reply-To: <59789F6B85725F4CAD78243CDDBA4C663A9D35@SERVA.grange.local> References: <326127375.20070620140431@energomera.ru> <4678FEAC.5000107@codesourcery.com> <59789F6B85725F4CAD78243CDDBA4C663A9D35@SERVA.grange.local> Message-ID: <46794C32.1080902@codesourcery.com> Paul McConkey wrote: > "One of the best value packages around has to be that offered by > CodeSourcery - as well as distributing their open-source GNU tool chains > for free, they will also license you a full-featured Eclipse-based > package which comes with full support for a very reasonable price. Their > version of Eclipse also supports managed make files so you will not have > to climb the almost vertical learning curve for GNU Make!". Thank you very much for the very kind words! -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From kevin.kirspel at optimedical.com Mon Jun 25 17:18:26 2007 From: kevin.kirspel at optimedical.com (Kirspel, Kevin) Date: Mon, 25 Jun 2007 13:18:26 -0400 Subject: Invalid code generated with gcc-4.2 for target m68k-rtems. Message-ID: <7D98F062ABB46446A4152A61C0602F0D0C45A2@ormsmail.namerica.idexxi.com> I have downloaded the coldfire-4.2 source code and I have cross-compiled it for the m68k-rtems target (for use with mcf5329EVB). Everything builds and installs fine. After the tools are installed I compiled my OS. The compilation of the OS completes with no errors. When I run the OS using GDB, the program fails in the newlib memset() function. The PC register at the time of failure is at 0x400149ea. I disassembled the application (using m68k-rtems-objdump) and got the following output for memset(): 400149cc : 400149cc: 4e56 0000 linkw %fp,#0 400149d0: 2f03 movel %d3,%sp at - 400149d2: 2f02 movel %d2,%sp at - 400149d4: 262e 0008 movel %fp@(8),%d3 400149d8: 226e 0010 moveal %fp@(16),%a1 400149dc: 2203 movel %d3,%d1 400149de: 4282 clrl %d2 400149e0: 142e 000f moveb %fp@(15),%d2 400149e4: 7003 moveq #3,%d0 400149e6: b089 cmpl %a1,%d0 400149e8: 6406 bccs 400149f0 400149ea: e8c3 0164303 400149ec: 0782 bclr %d3,%d2 400149ee: 6712 beqs 40014a02 400149f0: 4a89 tstl %a1 400149f2: 6758 beqs 40014a4c 400149f4: 1002 moveb %d2,%d0 400149f6: 2041 moveal %d1,%a0 400149f8: d3c1 addal %d1,%a1 400149fa: 10c0 moveb %d0,%a0 at + 400149fc: b3c8 cmpal %a0,%a1 400149fe: 66fa bnes 400149fa 40014a00: 604a bras 40014a4c 40014a02: 2043 moveal %d3,%a0 40014a04: 2002 movel %d2,%d0 The instruction at 0x400149ea seems to be bogus. Is this a gcc/newlib compilation issue or a build environment issue? I performed the following steps during the build process: 1. unarchived binutils. 2. built binutils with the following configure statement: configure --target=m68k-rtems --prefix=/usr/local. 3. installed binutils. 4. unarchived gcc and newlib. 5. created symbolic link for newlib within gcc. 6. built gcc with the following configure statement: configure --target=m68k-rtems --with-gnu-as --with-gnu-ld --with-newlib --verbose --enable-threads --enable-languages="c,c++" --prefix=/usr/local. 7. installed gcc. 8. unarchived OS. 9. built OS with the following configure statement: configure --target=m68k-rtems --disable-posix --disable-itron --disable-networking --disable-cxx --enable-rtemsbsp=mcf5329EVB --prefix=/usr/local. 10. Did objdump on hello world sample application to see disassembly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at codesourcery.com Mon Jun 25 17:34:13 2007 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Mon, 25 Jun 2007 13:34:13 -0400 Subject: [coldfire-gnu-discuss] Invalid code generated with gcc-4.2 for target m68k-rtems. In-Reply-To: <7D98F062ABB46446A4152A61C0602F0D0C45A2@ormsmail.namerica.idexxi.com> References: <7D98F062ABB46446A4152A61C0602F0D0C45A2@ormsmail.namerica.idexxi.com> Message-ID: <20070625173412.GP11433@caradoc.them.org> On Mon, Jun 25, 2007 at 01:18:26PM -0400, Kirspel, Kevin wrote: > I have downloaded the coldfire-4.2 source code and I have cross-compiled it > for the m68k-rtems target (for use with mcf5329EVB). Everything builds and > installs fine. After the tools are installed I compiled my OS. The > compilation of the OS completes with no errors. When I run the OS using > GDB, the program fails in the newlib memset() function. The PC register at > the time of failure is at 0x400149ea. I disassembled the application (using > m68k-rtems-objdump) and got the following output for memset(): > 400149ea: e8c3 0164303 This instruction does not occur in any of the memset implementations we ship; I suspect it is a problem with your configuration when you rebuilt the tools. If I'm reading the disassembler table correctly, that is bftst - an instruction present on the 68020 but not on ColdFire. -- Daniel Jacobowitz CodeSourcery From nicolas at sdt.be Fri Jun 22 07:46:36 2007 From: nicolas at sdt.be (Van Impe Nicolas) Date: Fri, 22 Jun 2007 09:46:36 +0200 Subject: Jump from assembly to C problem with boot code on MCF52233 Message-ID: <000001c7b4a1$75f3e140$1e01a8c0@pcnicolas> Hello Peter Nordby, Did you find a solution for the "assembly jump problem" because I have the same problem. Thanks Nicolas Van impe -------------- next part -------------- An HTML attachment was scrubbed... URL: From M_J_Butcher at IEE.org Sat Jun 23 22:26:23 2007 From: M_J_Butcher at IEE.org (Mark Butcher) Date: Sun, 24 Jun 2007 00:26:23 +0200 Subject: Interrupts failing in 4.2-8 but had working in 4.1-32 Message-ID: <000001c7b5e5$88016700$6601a8c0@mjblp004> Hi There are some uTasker users who's projects are based on CodeSourcery GNU. Some registers users have 4.2.15 and found that the project would no longer run but immediately crashes due to an address error. Therefore I have just downloaded the 4.2-8 Lite (which is probably 4.2.15 like) to see what happens and it is the same on my M52235 board - the reference project doesn't run. The reason that I see is that the interrupt routines are trying to return using RTS (rather than RTI) which result in instant death. Can anyone explain why the __attribute__((interrupt_handler)) is no longer recognised and how to get around the problem? In the 4.1-32 Lite version we never had this problem. Best regards Mark Butcher Mark Butcher Bsc (Hons) MPhil MIEE M.J.Butcher Consulting Obere Bahnhofstr. 13, 5507 Mellingen 056 491 48 10 / 079 402 26 37 / Skype: M_J_Butcher www.mjbc.ch / www.uTasker.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kirspel at optimedical.com Mon Jun 25 17:45:54 2007 From: kevin.kirspel at optimedical.com (Kirspel, Kevin) Date: Mon, 25 Jun 2007 13:45:54 -0400 Subject: [coldfire-gnu-discuss] Jump from assembly to C problem with b oot code on MCF52233 Message-ID: <7D98F062ABB46446A4152A61C0602F0D0C45A3@ormsmail.namerica.idexxi.com> Not yet. -----Original Message----- From: Van Impe Nicolas [mailto:nicolas at sdt.be] Sent: Friday, June 22, 2007 3:47 AM To: coldfire-gnu-discuss at codesourcery.com Subject: [coldfire-gnu-discuss] Jump from assembly to C problem with boot code on MCF52233 Hello Peter Nordby, Did you find a solution for the "assembly jump problem" because I have the same problem... Thanks Nicolas Van impe -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kirspel at optimedical.com Mon Jun 25 19:17:16 2007 From: kevin.kirspel at optimedical.com (Kirspel, Kevin) Date: Mon, 25 Jun 2007 15:17:16 -0400 Subject: [coldfire-gnu-discuss] Invalid code generated with gcc-4.2 fo r target m68k-rtems. Message-ID: <7D98F062ABB46446A4152A61C0602F0D0C45A5@ormsmail.namerica.idexxi.com> When I compile gcc and install it, there is no m5329 lib directory created. When I look at the m68k-elf releases that you guys build I see a m5329 lib directory. When I run GCC and specify the -mcpu=5329 option, GCC can not find the libraries associated with that CPU and therefore picks the 68020 libraries as a default (I don't know if this is true but it explains why there is 68020 instructions in my output). How do I get GCC to compile and install the m5329 lib directories? By default I see the following processors in the lib directory M5200, m5206, m68000, m68030, m68040, m68060, mcpu32 -----Original Message----- From: Daniel Jacobowitz [mailto:dan at codesourcery.com] Sent: Monday, June 25, 2007 1:34 PM To: Kirspel, Kevin Cc: 'coldfire-gnu-discuss at codesourcery.com' Subject: Re: [coldfire-gnu-discuss] Invalid code generated with gcc-4.2 for target m68k-rtems. On Mon, Jun 25, 2007 at 01:18:26PM -0400, Kirspel, Kevin wrote: > I have downloaded the coldfire-4.2 source code and I have cross-compiled it > for the m68k-rtems target (for use with mcf5329EVB). Everything builds and > installs fine. After the tools are installed I compiled my OS. The > compilation of the OS completes with no errors. When I run the OS using > GDB, the program fails in the newlib memset() function. The PC register at > the time of failure is at 0x400149ea. I disassembled the application (using > m68k-rtems-objdump) and got the following output for memset(): > 400149ea: e8c3 0164303 This instruction does not occur in any of the memset implementations we ship; I suspect it is a problem with your configuration when you rebuilt the tools. If I'm reading the disassembler table correctly, that is bftst - an instruction present on the 68020 but not on ColdFire. -- Daniel Jacobowitz CodeSourcery From dan at codesourcery.com Mon Jun 25 19:21:57 2007 From: dan at codesourcery.com ('Daniel Jacobowitz') Date: Mon, 25 Jun 2007 15:21:57 -0400 Subject: [coldfire-gnu-discuss] Invalid code generated with gcc-4.2 fo r target m68k-rtems. In-Reply-To: <7D98F062ABB46446A4152A61C0602F0D0C45A5@ormsmail.namerica.idexxi.com> References: <7D98F062ABB46446A4152A61C0602F0D0C45A5@ormsmail.namerica.idexxi.com> Message-ID: <20070625192155.GA2133@caradoc.them.org> On Mon, Jun 25, 2007 at 03:17:16PM -0400, Kirspel, Kevin wrote: > When I compile gcc and install it, there is no m5329 lib directory created. > When I look at the m68k-elf releases that you guys build I see a m5329 lib > directory. When I run GCC and specify the -mcpu=5329 option, GCC can not > find the libraries associated with that CPU and therefore picks the 68020 > libraries as a default (I don't know if this is true but it explains why > there is 68020 instructions in my output). How do I get GCC to compile and > install the m5329 lib directories? By default I see the following > processors in the lib directory > > M5200, m5206, m68000, m68030, m68040, m68060, mcpu32 We've only added ColdFire configurations for m68k-elf, not for m68k-rtems. I recommend you use the m68k-elf tools, if you can. If not, you may be able to configure gcc with --with-cpu=5329. I don't remember if that works on m68k. -- Daniel Jacobowitz CodeSourcery From nathan at codesourcery.com Mon Jun 25 19:41:11 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Mon, 25 Jun 2007 20:41:11 +0100 Subject: [coldfire-gnu-discuss] Invalid code generated with gcc-4.2 fo r target m68k-rtems. In-Reply-To: <7D98F062ABB46446A4152A61C0602F0D0C45A5@ormsmail.namerica.idexxi.com> References: <7D98F062ABB46446A4152A61C0602F0D0C45A5@ormsmail.namerica.idexxi.com> Message-ID: <46801A57.10601@codesourcery.com> Kirspel, Kevin wrote: > When I compile gcc and install it, there is no m5329 lib directory created. > When I look at the m68k-elf releases that you guys build I see a m5329 lib > directory. When I run GCC and specify the -mcpu=5329 option, GCC can not > find the libraries associated with that CPU and therefore picks the 68020 > libraries as a default (I don't know if this is true but it explains why > there is 68020 instructions in my output). How do I get GCC to compile and > install the m5329 lib directories? By default I see the following > processors in the lib directory > > M5200, m5206, m68000, m68030, m68040, m68060, mcpu32 this doesn't look like a set of libraries that the 4.2 sources would build. It looks to be the set that the older FSF toolchain produces. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From nathan at codesourcery.com Mon Jun 25 20:00:23 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Mon, 25 Jun 2007 21:00:23 +0100 Subject: [coldfire-gnu-discuss] Interrupts failing in 4.2-8 but had working in 4.1-32 In-Reply-To: <000001c7b5e5$88016700$6601a8c0@mjblp004> References: <000001c7b5e5$88016700$6601a8c0@mjblp004> Message-ID: <46801ED7.8000609@codesourcery.com> Mark Butcher wrote: > Some registers users have 4.2.15 and found that the project would no > longer run but immediately crashes due to an address error. > Can anyone explain why the __attribute__((interrupt_handler)) is no > longer recognised and how to get around the problem? > > In the 4.1-32 Lite version we never had this problem. I have checked the 4.2-15 and 4.1-32 and both recognize interrupt_handler. If you are using SourceryG++ 4.2-15, and encounter a problem, please use the CodeSourcery portal to register a report. We shall need a testcase. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From carlos at codesourcery.com Mon Jun 25 20:19:06 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Mon, 25 Jun 2007 16:19:06 -0400 Subject: [coldfire-gnu-discuss] Interrupts failing in 4.2-8 but had working in 4.1-32 In-Reply-To: <000001c7b5e5$88016700$6601a8c0@mjblp004> References: <000001c7b5e5$88016700$6601a8c0@mjblp004> Message-ID: <20070625201906.GE4712@lios> On Sun, Jun 24, 2007 at 12:26:23AM +0200, Mark Butcher wrote: > There are some uTasker users who's projects are based on CodeSourcery GNU. > Some registers users have 4.2.15 and found that the project would no > longer run but immediately crashes due to an address error. > Therefore I have just downloaded the 4.2-8 Lite (which is probably 4.2.15 > like) to see what happens and it is the same on my M52235 board - the > reference project doesn't run. > The reason that I see is that the interrupt routines are trying to return > using RTS (rather than RTI) which result in instant death. How are the interrupt routines written? > Can anyone explain why the __attribute__((interrupt_handler)) is no longer > recognised and how to get around the problem? I can use __attribute__((interrupt_handler)) with our 4.2-8 Lite tools without a problem: cat >> test.c <: foo(): 0: 4e56 0000 linkw %fp,#0 4: 2f00 movel %d0,%sp at - 6: 4280 clrl %d0 8: 201f movel %sp at +,%d0 a: 4e5e unlk %fp c: 4e73 rte What problem are you seeing? Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From pgeorgief at ucsd.edu Mon Jun 25 20:51:25 2007 From: pgeorgief at ucsd.edu (Paul Georgief) Date: Mon, 25 Jun 2007 13:51:25 -0700 Subject: USB BDM Message-ID: <3B586A4C-B24D-4A72-A040-753800DEACAD@ucsd.edu> Hi: I'm using the USB BDM interface from P&E Micro and am having problems passing the 'speed' option to the default USB device ('pe:// USBMultilink'). When I specify the device using a unique device name such as 'pe://USBMultilink/PE6015837' - it works great and I have no problems. Is there a way to pass the speed option to a default device? The reason I ask is because I have more than one setup and it would be nice if I didn't have to remember which BDM is on which setup (and they do get moved/exchanged/lost/stolen/etc). Here is a printout of what I am getting: $ m68k-elf-sprite -i CodeSourcery ColdFire Debug Sprite (Sourcery G++ 4.1-39) ccs: [timeout=&speed=] CCS Adaptor ccs://$Host:$Port/$Chainpos - CCS address pe: [speed=&memory-timeout=] P&E Adaptor pe://USBMultilink/PE6015837 - USB1 : USB-ML-CF Rev C (PE6015837) pe://CycloneProMaxSerial:1 - COM1 : Serial Port 1 pe://ParallelPortCable:1 - LPT1 : Parallel Port 1 (Address $03BC) --- GDB (Note: the '4x4' is my XML device configuration file) --- **** IT SEES THE DEVICE, BUT MY SPEED SETTING IS INCORRECT **** (gdb) target remote | m68k-elf-sprite pe://USBMultilink 4x4 Remote communication error: No error. Remote debugging using | m68k-elf-sprite pe://USBMultilink 4x4 m68k-elf-sprite:Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF Rev C (PE6015837)) m68k-elf-sprite:error:Cannot establish communication with target Remote communication error: No error. **** I GET AN UNKNOWN DEVICE IF I PASS THE SPEED OPTION ***** (gdb) target remote | m68k-elf-sprite pe://USBMultilink?speed=2 4x4 Remote communication error: No error. Remote debugging using | m68k-elf-sprite pe://USBMultilink?speed=2 4x4 m68k-elf-sprite:error:Unknown device type `USBMultilink?speed=2' Remote communication error: No error. **** IT WORKS IF I SPECIFY THE EXACT BDM **** (gdb) target remote | m68k-elf-sprite pe://USBMultilink/PE6015837? speed=2 4x4 Remote communication error: No error. Remote debugging using | m68k-elf-sprite pe://USBMultilink/PE6015837? speed=2 4x4 m68k-elf-sprite:Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF Rev C (PE6015837)) m68k-elf-sprite:Target reset 0x00000000 in ?? () My configuration is as follows: Host: WinXP Target: mcf5235 Toolset: Sourcery G++ 4.1-39 BDM: USB-ML-CFE Rev. C Thanks, Paul From dan at codesourcery.com Mon Jun 25 20:56:30 2007 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Mon, 25 Jun 2007 16:56:30 -0400 Subject: [coldfire-gnu-discuss] USB BDM In-Reply-To: <3B586A4C-B24D-4A72-A040-753800DEACAD@ucsd.edu> References: <3B586A4C-B24D-4A72-A040-753800DEACAD@ucsd.edu> Message-ID: <20070625205628.GC2133@caradoc.them.org> On Mon, Jun 25, 2007 at 01:51:25PM -0700, Paul Georgief wrote: > **** I GET AN UNKNOWN DEVICE IF I PASS THE SPEED OPTION ***** > (gdb) target remote | m68k-elf-sprite pe://USBMultilink?speed=2 4x4 > Remote communication error: No error. > Remote debugging using | m68k-elf-sprite pe://USBMultilink?speed=2 4x4 > m68k-elf-sprite:error:Unknown device type `USBMultilink?speed=2' > Remote communication error: No error. Have you tried "pe://USBMultilink/?speed=2" ? -- Daniel Jacobowitz CodeSourcery From david at westcontrol.com Tue Jun 26 11:58:59 2007 From: david at westcontrol.com (David Brown) Date: Tue, 26 Jun 2007 13:58:59 +0200 Subject: Small data sections Message-ID: <4680FF83.80406@westcontrol.com> Just a passing thought... Some gcc targets support the concept of "small data section". This is particularly important for 32-bit RISC cpus (like the PPC), were an addressing mode of the form "Rx + 16bit" can fit in one instruction, while an absolute 32-bit address takes a lot of messing around to get the address into a register and then doing the real load or store. On a ColdFire, which has absolute long addressing modes, it is not nearly as important. However, there are a couple of reasons why small data sections could still be very interesting for ColdFires. One is that (Ax + 16bit) addressing mode requires 2 instruction words instead of 3 - a minor gain, which must be weighed against the loss of the base pointer (typically A5). The other is that many ColdFires have a certain amount of internal RAM, and there can be very significant speed gains by putting small data there. I am working on a program using a 5234 at the moment, and I see that access to the sdram can be very slow (relative to the core). I already have the stack at the top of the internal ram, but have plenty of space for more data. I can always use the "section" attribute to put specific data into the internal ram, but it would be *very* convenient if all small data went into its own section automatically, leaving larger buffers and arrays in the main ram. It would still save significant run time even if addressed using absolute long addressing - although to be *really* cunning, the internal ram could be placed at the very top or very bottom of memory, and accessed using absolute short addressing. mvh., David From nathan at codesourcery.com Tue Jun 26 12:04:36 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Tue, 26 Jun 2007 13:04:36 +0100 Subject: [coldfire-gnu-discuss] Small data sections In-Reply-To: <4680FF83.80406@westcontrol.com> References: <4680FF83.80406@westcontrol.com> Message-ID: <468100D4.3040600@codesourcery.com> David Brown wrote: > Just a passing thought... > > Some gcc targets support the concept of "small data section". This is > particularly important for 32-bit RISC cpus (like the PPC), were an > addressing mode of the form "Rx + 16bit" can fit in one instruction, > while an absolute 32-bit address takes a lot of messing around to get > the address into a register and then doing the real load or store. On a > ColdFire, which has absolute long addressing modes, it is not nearly as > important. thanks for your suggestion. As you probably realize, small data sections are a psABI design feature. We would be stepping outside of the m68k ABI by adding that to ColdFire. ABIs that have small data sections generally have a lot of registers -- mips and ppc have 32 integer registers, for instance. m68k has 8 address registers (arm has 16 registers, and I don't think the ARM EABI has small data references). Whether small data is a win on ColdFire is probably application-specific. We may get better mileage by teaching the compiler more about instruction costs and using section anchors. (The m68k port is one of the oldest gcc ports, and its age shows in certain places.) nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From pgeorgief at ucsd.edu Tue Jun 26 13:58:57 2007 From: pgeorgief at ucsd.edu (Paul Georgief) Date: Tue, 26 Jun 2007 06:58:57 -0700 Subject: [coldfire-gnu-discuss] USB BDM In-Reply-To: <20070625205628.GC2133@caradoc.them.org> References: <3B586A4C-B24D-4A72-A040-753800DEACAD@ucsd.edu> <20070625205628.GC2133@caradoc.them.org> Message-ID: <7D2939E6-563C-4855-B730-B44A618E2DAD@ucsd.edu> Daniel: On Jun 25, 2007, at 1:56 PM, Daniel Jacobowitz wrote: > On Mon, Jun 25, 2007 at 01:51:25PM -0700, Paul Georgief wrote: >> **** I GET AN UNKNOWN DEVICE IF I PASS THE SPEED OPTION ***** >> (gdb) target remote | m68k-elf-sprite pe://USBMultilink?speed=2 4x4 >> Remote communication error: No error. >> Remote debugging using | m68k-elf-sprite pe://USBMultilink?speed=2 >> 4x4 >> m68k-elf-sprite:error:Unknown device type `USBMultilink?speed=2' >> Remote communication error: No error. > > Have you tried "pe://USBMultilink/?speed=2" ? > > -- > Daniel Jacobowitz > CodeSourcery Tried it. It doesn't work. I get the following: (gdb) target remote | m68k-elf-sprite pe://USBMultilink/?speed=2 4x4 Remote debugging using | m68k-elf-sprite pe://USBMultilink/?speed=2 4x4 m68k-elf-sprite:error:Cannot find a matching debug device Remote communication error: No error. As before, If I attach the BDM specific serial number and type: target remote | m68k-elf-sprite pe://USBMultilink/PE6015837?speed=2 4x4 it works great. I was just hoping to get the speed option to work with the default device 'pe://USBMultilink', but it doesn't appear possible. -Paul From david at westcontrol.com Tue Jun 26 14:00:01 2007 From: david at westcontrol.com (David Brown) Date: Tue, 26 Jun 2007 16:00:01 +0200 Subject: [coldfire-gnu-discuss] Small data sections In-Reply-To: <468100D4.3040600@codesourcery.com> References: <4680FF83.80406@westcontrol.com> <468100D4.3040600@codesourcery.com> Message-ID: <46811BE1.7090902@westcontrol.com> Nathan Sidwell wrote: > David Brown wrote: >> Just a passing thought... >> >> Some gcc targets support the concept of "small data section". This is >> particularly important for 32-bit RISC cpus (like the PPC), were an >> addressing mode of the form "Rx + 16bit" can fit in one instruction, >> while an absolute 32-bit address takes a lot of messing around to get >> the address into a register and then doing the real load or store. On >> a ColdFire, which has absolute long addressing modes, it is not nearly >> as important. > > thanks for your suggestion. > > As you probably realize, small data sections are a psABI design > feature. We would be stepping outside of the m68k ABI by adding that to > ColdFire. ABIs that have small data sections generally have a lot of > registers -- mips and ppc have 32 integer registers, for instance. m68k > has 8 address registers (arm has 16 registers, and I don't think the ARM > EABI has small data references). > Yes, I understand it is outside the ABI. Clearly, you don't want to mess with this sort of thing when working with other software (such as ucLinux) - it's mainly for standalone embedded systems with dedicated software. While we are on the subject of ABI, another option that would be at least as useful would be parameter passing via registers rather than the stack. This would have a very large impact on the function call overhead and be especially for small functions (common in C++ programming). When you have a stack in sdram, the performance cost in pushing parameters onto the stack, only to load them again immediately afterwards, is very high. Again, I realise this leads to all sorts of complications involving libraries, command-line options, function attributes (so that you can mix and match if needed - like "fastcall" for the i386 target), etc. > Whether small data is a win on ColdFire is probably > application-specific. We may get better mileage by teaching the > compiler more about instruction costs and using section anchors. (The > m68k port is one of the oldest gcc ports, and its age shows in certain > places.) > Section anchors will allow (Ax + 16-bit offset) addressing for blocks of data, and is undoubtedly something that will help many types of code on many targets, not just the ColdFire. I gather there is also work going on regarding the re-ordering of data in the data sections (or even with structs) to take better advantage of cache lines. But the key point about having a small data section is the placement in fast memory, rather than the way it is accessed - if section anchors are soon realised, then there is probably nothing to be gained by addressing the small data in a specific manner. And yes, the benefits are application-specific - again, it is for dedicated embedded software running either without an OS, or with a fairly minimal one, since you have to be able to specifically place the small data section in internal memory to take advantage of it. mvh., David > nathan From carlos at codesourcery.com Tue Jun 26 19:22:05 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Tue, 26 Jun 2007 15:22:05 -0400 Subject: [coldfire-gnu-discuss] Interrupts failing in 4.2-8 but had working in 4.1-32 In-Reply-To: <46806163.2020406@thinksrs.com> References: <000001c7b5e5$88016700$6601a8c0@mjblp004> <20070625201906.GE4712@lios> <46806163.2020406@thinksrs.com> Message-ID: <20070626192205.GL4712@lios> On Sun, Jun 24, 2007 at 12:26:23AM +0200, Mark Butcher wrote: > There are some uTasker users who's projects are based on CodeSourcery GNU. > Some registers users have 4.2.15 and found that the project would no > longer run but immediately crashes due to an address error. > Therefore I have just downloaded the 4.2-8 Lite (which is probably 4.2.15 > like) to see what happens and it is the same on my M52235 board - the > reference project doesn't run. > The reason that I see is that the interrupt routines are trying to return > using RTS (rather than RTI) which result in instant death. We were able to reproduce this problem. We are looking into the issue. The workaround is to use -O1 instead of -Os. Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From dalomar at serrasold.com Thu Jun 28 12:30:14 2007 From: dalomar at serrasold.com (Daniel Alomar) Date: Thu, 28 Jun 2007 14:30:14 +0200 Subject: "no memory region specified for loadable section" error Message-ID: <4683A9D6.1040300@serrasold.com> Hi, I download the latest gnu-toolchain for the coldfire processor under Linux. When I'm compiling the uClinux, I get this error (with the toolchain (http://www.uclinux.org/pub/uClinux/m68k-elf-tools/tools-20061214/m68k-uclinux-tools-20061214.sh ) from Greg I didn't get this error): m68k-elf-ld -r -o fs.o open.o read_write.o devices.o file_table.o buffer.o super.o block_dev.o char_dev.o stat.o exec.o pipe.o namei.o fcntl.o ioctl.o readdir.o select.o fifo.o locks.o dcache.o inode.o attr.o bad_inode.o file.o iobuf.o dnotify.o filesystems.o namespace.o seq_file.o xattr.o quota.o binfmt_script.o binfmt_flat.o proc/proc.o partitions/partitions.o ext2/ext2.o ramfs/ramfs.o fat/fat.o msdos/msdos.o vfat/vfat.o nfs/nfs.o lockd/lockd.o nls/nls.o romfs/romfs.o make[3]: Leaving directory `/uClinux/uClinux-dist/linux-2.4.x/fs' make[2]: Leaving directory `/uClinux/uClinux-dist/linux-2.4.x/fs' m68k-elf-ld -T arch/m68knommu/platform/5282/SERRA/ram.ld arch/m68knommu/platform/5282/SERRA/crt0_ram.o init/main.o init/version.o init/do_mounts.o \ --start-group \ arch/m68knommu/kernel/kernel.o arch/m68knommu/mm/mm.o arch/m68knommu/platform/5282/platform.o kernel/kernel.o mmnommu/mmnommu.o fs/fs.o ipc/ipc.o \ drivers/char/char.o drivers/serial/serial.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/mtd/mtdlink.o drivers/media/media.o \ net/network.o \ /uClinux/uClinux-dist/linux-2.4.x/lib/lib.a arch/m68knommu/lib/lib.a /usr/local/bin/../lib/gcc/m68k-uclinux/4.2.0//m5307/libgcc.a \ --end-group \ -o linux /usr/local/bin/m68k-elf-ld.real: error: no memory region specified for loadable section `.eh_frame' make[1]: *** [linux] Error 1 make[1]: Leaving directory `/uClinux/uClinux-dist/linux-2.4.x' make: *** [linux] Error 1 Any idea? Regards, -- Daniel Alomar i Claramonte Research & Development Electronic Dept. SERRA SOLDADURA, S.A. WEB Site: http://www.serrasold.com Knowledge Site: http://serratron.serrasold.com From dalomar at serrasold.com Thu Jun 28 12:42:38 2007 From: dalomar at serrasold.com (Daniel Alomar) Date: Thu, 28 Jun 2007 14:42:38 +0200 Subject: binutils Patch Message-ID: <4683ACBE.5040601@serrasold.com> Hi, For the error I mentioned before, I found a binutils patch: http://wiki.linuxfromscratch.org/patches/browser/trunk/binutils/binutils-2.17-branch_update-2.patch Maybe is the solution? Regards, -- Daniel Alomar i Claramonte Research & Development Electronic Dept. SERRA SOLDADURA, S.A. WEB Site: http://www.serrasold.com Knowledge Site: http://serratron.serrasold.com From dalomar at serrasold.com Fri Jun 29 07:07:02 2007 From: dalomar at serrasold.com (Daniel Alomar) Date: Fri, 29 Jun 2007 09:07:02 +0200 Subject: Compile m68k toolchain from the source code Message-ID: <4684AF96.1000305@serrasold.com> Hi, I'm trying to compile the source code from the m68k-toolchain because I applied a binutil-2.17-patch to fix some errors http://www.linuxfromscratch.org/patches/hlfs/svn/binutils-2.17-branch_update-2.patch But when I run the script, it complains about some folders (/home/nathan/..) I put my home folder but it doesn't work. I notice the script use 3 variables ($1 as source $2 as dest and $3 as exclude) but if I run $sudo sh freescale.....sh . /home/dani it doesn't work either Does anybody has a howto to use this script? -- Daniel Alomar i Claramonte Research & Development Electronic Dept. SERRA SOLDADURA, S.A. WEB Site: http://www.serrasold.com Knowledge Site: http://serratron.serrasold.com From nathan at codesourcery.com Fri Jun 29 12:36:45 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Fri, 29 Jun 2007 13:36:45 +0100 Subject: [coldfire-gnu-discuss] "no memory region specified for loadable section" error In-Reply-To: <4683A9D6.1040300@serrasold.com> References: <4683A9D6.1040300@serrasold.com> Message-ID: <4684FCDD.8000706@codesourcery.com> Daniel Alomar wrote: > m68k-elf-ld -T arch/m68knommu/platform/5282/SERRA/ram.ld ... > /usr/local/bin/m68k-elf-ld.real: error: no memory region specified for > loadable section `.eh_frame' You need to fix the linker script to include .eh_frame. Look at the linker-provided scripts for details of how they are treated. 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 Jun 29 13:00:41 2007 From: nathan at codesourcery.com (Nathan Sidwell) Date: Fri, 29 Jun 2007 14:00:41 +0100 Subject: [coldfire-gnu-discuss] Compile m68k toolchain from the source code In-Reply-To: <4684AF96.1000305@serrasold.com> References: <4684AF96.1000305@serrasold.com> Message-ID: <46850279.9060303@codesourcery.com> Daniel Alomar wrote: > Hi, > > I'm trying to compile the source code from the m68k-toolchain because I > applied a binutil-2.17-patch to fix some errors > > http://www.linuxfromscratch.org/patches/hlfs/svn/binutils-2.17-branch_update-2.patch > > > But when I run the script, it complains about some folders > (/home/nathan/..) I put my home folder but it doesn't work. The script is an exact record of how we built the toolchain, and may be used as a _guide_ only. We don't recommend you patch and rebuild the toolchain. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From carlos at codesourcery.com Fri Jun 29 15:42:27 2007 From: carlos at codesourcery.com (Carlos O'Donell) Date: Fri, 29 Jun 2007 11:42:27 -0400 Subject: [coldfire-gnu-discuss] binutils Patch In-Reply-To: <4683ACBE.5040601@serrasold.com> References: <4683ACBE.5040601@serrasold.com> Message-ID: <20070629154227.GL4712@lios> On Thu, Jun 28, 2007 at 02:42:38PM +0200, Daniel Alomar wrote: > Hi, > For the error I mentioned before, I found a binutils patch: > http://wiki.linuxfromscratch.org/patches/browser/trunk/binutils/binutils-2.17-branch_update-2.patch > Maybe is the solution? > Regards, Do you have a testcase for the error you mentioned? If you can provide a testcase I would be happy to look at the error. Nathan has already recommended that you examine the default linker script (ld -verbose) and handle the extra section in a similar fashion. Have you tried fixing the linker script? Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716