From david at westcontrol.com Wed Nov 1 12:02:13 2006 From: david at westcontrol.com (David Brown) Date: Wed, 01 Nov 2006 13:02:13 +0100 Subject: Linker files and startup code Message-ID: <45488CC5.5030703@westcontrol.com> Hi, I'm trying to establish exactly what happens in the startup C files and loader scripts that come with the CodeSourcery gcc package. Normally, I've used my own loader scripts and my own startup code, but for the project I'm starting work on at the moment, I thought I'd look at the scripts that came with the pre-packaged setup. I'm using a MCF5213 (256K flash, 32K Ram) here, on my own board and with no other software but my own code. This post is a few comments on what I have seen so far, which may be of interest to the CodeSourcery guys (many thanks for your work, by the way!) or other users. First off, it's a tough job finding the source code for the startup files. I tracked down the appropriate crt0.S, though it would be *very* useful to have had that in the binary build distributions as well as the source distribution. But I can't trace the sources for crtbegin.o or crtend.o anywhere. Since they are small, an objdump disassembly listing is not bad, but I'd like to know where they came from... The linker scripts and the crt0.S seem to be based entirely on the idea that the code is running from ram. On many ColdFire's, that is the case - you have a bootloader of some sort which copies the code from slow flash into fast ram for execution. But on the more integrated devices like the 5213, you need to run the code from flash. This means that the loader scripts should support the separate memory areas, with code going in flash, bss going in ram, and data going in flash but with logical addresses in ram, and the crt0 startup should copy the initial values into ram. A minor point about the crt0.S code is that it clears the bss section byte by byte. On the ColdFire, writing 32-bit words will clear the section about four times as fast. mvh., David From nathan at codesourcery.com Wed Nov 1 16:23:35 2006 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 01 Nov 2006 16:23:35 +0000 Subject: [coldfire-gnu-discuss] Linker files and startup code In-Reply-To: <45488CC5.5030703@westcontrol.com> References: <45488CC5.5030703@westcontrol.com> Message-ID: <4548CA07.1010406@codesourcery.com> David Brown wrote: > but my own code. This post is a few comments on what I have seen so > far, which may be of interest to the CodeSourcery guys (many thanks for > your work, by the way!) or other users. thanks for taking the time to comment. > First off, it's a tough job finding the source code for the startup > files. I tracked down the appropriate crt0.S, though it would be *very* > useful to have had that in the binary build distributions as well as the > source distribution. But I can't trace the sources for crtbegin.o or > crtend.o anywhere. Since they are small, an objdump disassembly listing > is not bad, but I'd like to know where they came from... we realized that too :) The next releases will include the crt source code in the binaries too (placed alongside their compiled versions). crtbegin.o and crtend.o are a different matter and we hadn't thought about them. They are part of the compiler and are in gcc/crtstuff.c -- it is compiled twice with #define telling it whether it'll be crtbegin or crtend. That source file is not compilable outside of gcc, so I'm not sure how useful or misleading it might be to include it along with crt0.S etc. > The linker scripts and the crt0.S seem to be based entirely on the idea > that the code is running from ram. On many ColdFire's, that is the case > - you have a bootloader of some sort which copies the code from slow > flash into fast ram for execution. But on the more integrated devices > like the 5213, you need to run the code from flash. This means that the > loader scripts should support the separate memory areas, with code going > in flash, bss going in ram, and data going in flash but with logical > addresses in ram, and the crt0 startup should copy the initial values > into ram. Correct. We've been adding flash programming support, but it is not ready yet. We've also added ram and rom variants of the linker scripts along with hosted and unhosted versions. > A minor point about the crt0.S code is that it clears the bss section > byte by byte. On the ColdFire, writing 32-bit words will clear the > section about four times as fast. yeah, that's fixed too :) the crt0.S code had a long history, but we've reengineered a coldfire specific version now. It seems we've addressed all your issues in our internal development. New public releases are planned for the end of this month containing these updates. Of course, if you had a subscription (either Personal or Professional), you wouldn't have had to wait so long for some of the features you mentioned. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From techie.embedded at gmail.com Thu Nov 9 17:14:46 2006 From: techie.embedded at gmail.com (techie embedded) Date: Thu, 9 Nov 2006 22:44:46 +0530 Subject: Re; gcc Compiler , Debugger for Windows Message-ID: <30f3d1370611090914ge6c3b1chbb322ec814ab9d47@mail.gmail.com> Hello members Well, I'm starting off with ColdFire ( MCF5282 ) as i need to be involved with some development on it... Will apprecite if you can give me some links that can kickstart my work on MCF5282. First and foremost, where do i start off from??? I have got the ColdFire -- GCC libraries from codesourcery.com. So is this along with a Cygwin environment enough or is there something that is opensource & comes as a plugin to Eclipse that i can use??? regards Krish -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at codesourcery.com Thu Nov 9 17:31:14 2006 From: nathan at codesourcery.com (Nathan Sidwell) Date: Thu, 09 Nov 2006 17:31:14 +0000 Subject: [coldfire-gnu-discuss] Re; gcc Compiler , Debugger for Windows In-Reply-To: <30f3d1370611090914ge6c3b1chbb322ec814ab9d47@mail.gmail.com> References: <30f3d1370611090914ge6c3b1chbb322ec814ab9d47@mail.gmail.com> Message-ID: <455365E2.4080207@codesourcery.com> techie embedded wrote: > First and foremost, where do i start off from??? > > I have got the ColdFire -- GCC libraries from codesourcery.com > . So is this along with a Cygwin environment > enough or is there something that is opensource & comes as a plugin to > Eclipse that i can use??? the toolchain will work in a cygwin environment. If you want to use it from eclipse, you can purchase SourceryG++, which includes eclipse, debugger plugins, updates (and support for the Professional edition). nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From david at westcontrol.com Fri Nov 10 08:16:28 2006 From: david at westcontrol.com (David Brown) Date: Fri, 10 Nov 2006 09:16:28 +0100 Subject: [coldfire-gnu-discuss] Re; gcc Compiler , Debugger for Windows In-Reply-To: <30f3d1370611090914ge6c3b1chbb322ec814ab9d47@mail.gmail.com> References: <30f3d1370611090914ge6c3b1chbb322ec814ab9d47@mail.gmail.com> Message-ID: <4554355C.4060106@westcontrol.com> techie embedded wrote: > Hello members > > > Well, I'm starting off with ColdFire ( MCF5282 ) as i need to be > involved with some development on it... > > Will apprecite if you can give me some links that can kickstart my work > on MCF5282. > > First and foremost, where do i start off from??? > > I have got the ColdFire -- GCC libraries from codesourcery.com > . So is this along with a Cygwin environment > enough or is there something that is opensource & comes as a plugin to > Eclipse that i can use??? > > regards > > Krish You don't need Cygwin if you have the windows binaries from CodeSourcery, as they are stand-alone exe files. You might want a cygwin environment if you want something close to a *nix environment on your PC, but you don't need it. If you just want a few more *nix utilities (cat, less, grep, rm, etc.), you are probably better off getting mingw and msys - they provide a much lighter, faster and more "native" setup than Cygwin. If you want good integration with Eclipse, then I expect the best method is to buy a subscription from CodeSourcery, as that is one of the benefits of their commercial packages. That way you can be sure it will work, and it is quite likely that they have examples to help you get started. If you bought a development board of some sort, then there are probably some example programs available from the supplier as a start point. mvh., David From david at westcontrol.com Tue Nov 14 09:32:07 2006 From: david at westcontrol.com (David Brown) Date: Tue, 14 Nov 2006 10:32:07 +0100 Subject: Multiplying by a constant Message-ID: <45598D17.9050306@westcontrol.com> This is just an idea for an improvement in the ColdFire backend. When multiplying by a constant, the compiler generates a series of shifts and adds (or subs) instead of using the appropriate "mul" instruction. While this is optimal when the shift and add combination is small, it is sub-optimal if more than 3 instructions are needed (multiplies take 4 clocks on a v2 Coldfire). This is a hang-over from the pre-Coldfire m68k cores which had very slow multiplies. Test code: extern unsigned int x, y; void foo(void) { x = y * 11; } Generated code (-O2 -Wa,-ahlsd -m528x): 92 foo: 93 008e 4E56 0000 link.w %fp,#0 94 0092 2079 0000 move.l y,%a0 | y, y.6 94 0000 95 0098 2008 move.l %a0,%d0 | y.6, y.6 96 009a 2200 move.l %d0,%d1 | y.6, tmp33 97 009c E589 lsl.l #2,%d1 |, tmp33 98 009e 2001 move.l %d1,%d0 | tmp33, tmp34 99 00a0 E588 lsl.l #2,%d0 |, tmp34 100 00a2 9081 sub.l %d1,%d0 | tmp33, tmp34 101 00a4 9088 sub.l %a0,%d0 | y.6, D.1159 102 00a6 23C0 0000 move.l %d0,x | D.1159, x 102 0000 103 00ac 4E5E unlk %fp 104 00ae 4E75 rts mvh., David From mark at codesourcery.com Tue Nov 14 23:04:33 2006 From: mark at codesourcery.com (Mark Mitchell) Date: Tue, 14 Nov 2006 15:04:33 -0800 Subject: [coldfire-gnu-discuss] Multiplying by a constant In-Reply-To: <45598D17.9050306@westcontrol.com> References: <45598D17.9050306@westcontrol.com> Message-ID: <455A4B81.4090900@codesourcery.com> David Brown wrote: > When multiplying by a constant, the compiler generates a series of > shifts and adds (or subs) instead of using the appropriate "mul" > instruction. Thanks for the idea; we've recorded the idea in our issue tracker, and will implement it in a future release, time permitting. -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From david at westcontrol.com Wed Nov 15 12:51:07 2006 From: david at westcontrol.com (David Brown) Date: Wed, 15 Nov 2006 13:51:07 +0100 Subject: Using m68k-elf-cfpe-stub with our own board Message-ID: <455B0D3B.1040109@westcontrol.com> Can anyone give me some pointers to getting board setup to work correctly using CodeSourcery's gdb and stub? I have two problems - I can't see how to set (or view) cpu space registers, and I can't get the stub to use my own board configuration file. I'm used to using a older version of gdb, patched with bdm support (from bdm.sourceforge.net). My board setup is done with commands in a .gdbinit file such as: bdm-write-creg 0xc05 0x10000001 I can't find any way to do something similar with the CodeSourcery tools. The cfpe-stub program appears to do a certain amount of board setup, based on the "-t" parameter. For example, when called with "m68k-elf-cfpe-stub -t m5213evb", creg 0xc05 (aka RAMBAR) is apparently set to 0x20000001. I'd like to use my own target setup, but I can't find any information on the configuration file syntax (the CodeSourcery documentation refers to the Code Worrier documentation, but I've no plans to download hundreds of megabytes of Code Worrier if I can avoid it). I tried using a cfg file from FreeScale's flash programmer, but that does not seem to work. If anyone has an example configuration file, I expect I can figure out what changes I'd need for my own use. mvh., David From david at westcontrol.com Wed Nov 15 13:17:07 2006 From: david at westcontrol.com (David Brown) Date: Wed, 15 Nov 2006 14:17:07 +0100 Subject: [coldfire-gnu-discuss] Using m68k-elf-cfpe-stub with our own board In-Reply-To: <455B0D3B.1040109@westcontrol.com> References: <455B0D3B.1040109@westcontrol.com> Message-ID: <455B1353.30306@westcontrol.com> David Brown wrote: > Can anyone give me some pointers to getting board setup to work > correctly using CodeSourcery's gdb and stub? I have two problems - I > can't see how to set (or view) cpu space registers, and I can't get the > stub to use my own board configuration file. > > I'm used to using a older version of gdb, patched with bdm support (from > bdm.sourceforge.net). My board setup is done with commands in a > .gdbinit file such as: > > bdm-write-creg 0xc05 0x10000001 > > I can't find any way to do something similar with the CodeSourcery tools. > > The cfpe-stub program appears to do a certain amount of board setup, > based on the "-t" parameter. For example, when called with > "m68k-elf-cfpe-stub -t m5213evb", creg 0xc05 (aka RAMBAR) is apparently > set to 0x20000001. I'd like to use my own target setup, but I can't > find any information on the configuration file syntax (the CodeSourcery > documentation refers to the Code Worrier documentation, but I've no > plans to download hundreds of megabytes of Code Worrier if I can avoid > it). I tried using a cfg file from FreeScale's flash programmer, but > that does not seem to work. If anyone has an example configuration > file, I expect I can figure out what changes I'd need for my own use. > > mvh., > > David > > It turns out that you can get the Code Worrier user's guide from without downloading the whole lot, from: http://www.freescale.com/files/soft_dev_tools/doc/user_guide/COLDFIREUG.pdf As an example (in case it is of use to others), my "board.cfg" file is: ; Set RAMBAR for ram access writecontrolreg 0xc05 0x10000221 writemem.l 0x40000008 0x10000200 ; Set SYNCR for x8 clock writemem.w 0x40120000 0x2007 I'd still like to know how to change cpu-space registers from with gdb, if anyone has any ideas - for some processors, it is important to be able to do things like turn caching on and off while debugging. mvh., David From nathan at codesourcery.com Wed Nov 15 13:22:42 2006 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 15 Nov 2006 13:22:42 +0000 Subject: [coldfire-gnu-discuss] Using m68k-elf-cfpe-stub with our own board In-Reply-To: <455B1353.30306@westcontrol.com> References: <455B0D3B.1040109@westcontrol.com> <455B1353.30306@westcontrol.com> Message-ID: <455B14A2.1070100@codesourcery.com> > It turns out that you can get the Code Worrier user's guide from without > downloading the whole lot, from: > > http://www.freescale.com/files/soft_dev_tools/doc/user_guide/COLDFIREUG.pdf Glad you found that. We were unable to get permission to distribute those config files. Our upcoming update to the tools has implemented a much better xml based initialization scheme, which we have fully documented. It specifies both board initialization and board memory maps. > I'd still like to know how to change cpu-space registers from with gdb, > if anyone has any ideas - for some processors, it is important to be > able to do things like turn caching on and off while debugging. This is not possible with the current gdb -- the bdm.sourceforge.net patches have not been contributed to FSF gdb. That said, control register access from gdb is on our todo list, but won't be available in the near term. In the meantime you could include a function of the form void set_cache_debug (unsigned v) { __asm__ __volatile__ ("movec.l %0,%/cacr" :: "r" (v) : "memory"); } in your application and use it from gdb with (gdb) call set_cache_debug(0xWHATEVER) 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 Nov 15 13:40:35 2006 From: paul.mcconkey at cambridgeimaging.co.uk (Paul McConkey) Date: Wed, 15 Nov 2006 13:40:35 -0000 Subject: trapf opcode Message-ID: <59789F6B85725F4CAD78243CDDBA4C6627364F@SERVA.grange.local> I am using the -mcpu=528x switch to assemble my source for the MCF5282, but as in the 4.1-14 build doesn't appear to support the syntax for tpf that is in my copy of the CF Programmer's Reference Manual. I have poked the correct data (.word 0x51fc) into my source and while debugging, I noticed that gdb was happy to disassemble this as trapf. So the assembler supports trapf, which is fine, but are you likely to support the CF syntax below in future? If so, will you deprecate or remove the support for trapf? CFPRM rev.3 p 4-83 Assembler syntax: TPF PC + 2 -> PC TPF.W PC + 4 -> PC TPF.L PC + 6 -> PC Thanks, Paul. From nathan at codesourcery.com Wed Nov 15 14:20:32 2006 From: nathan at codesourcery.com (Nathan Sidwell) Date: Wed, 15 Nov 2006 14:20:32 +0000 Subject: [coldfire-gnu-discuss] trapf opcode In-Reply-To: <59789F6B85725F4CAD78243CDDBA4C6627364F@SERVA.grange.local> References: <59789F6B85725F4CAD78243CDDBA4C6627364F@SERVA.grange.local> Message-ID: <455B2230.10604@codesourcery.com> Paul McConkey wrote: > So the assembler supports trapf, which is fine, but are you likely to > support the CF syntax below in future? If so, will you deprecate or > remove the support for trapf? > > CFPRM rev.3 p 4-83 > > Assembler syntax: TPF PC + 2 -> PC > TPF.W PC + 4 -> PC > TPF.L PC + 6 -> PC oh joy. trapf is the cpu32 instruction name, coldfire appears to have selected a different name for the same encoding. We won't remove trapf, but will probably accept 'tpf' as an alternative. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From david at westcontrol.com Wed Nov 15 14:57:22 2006 From: david at westcontrol.com (David Brown) Date: Wed, 15 Nov 2006 15:57:22 +0100 Subject: [coldfire-gnu-discuss] Using m68k-elf-cfpe-stub with our own board In-Reply-To: <455B14A2.1070100@codesourcery.com> References: <455B0D3B.1040109@westcontrol.com> <455B1353.30306@westcontrol.com> <455B14A2.1070100@codesourcery.com> Message-ID: <455B2AD2.2060100@westcontrol.com> Nathan Sidwell wrote: > >> It turns out that you can get the Code Worrier user's guide from >> without downloading the whole lot, from: >> >> http://www.freescale.com/files/soft_dev_tools/doc/user_guide/COLDFIREUG.pdf >> > > Glad you found that. We were unable to get permission to distribute > those config files. > You have my permission to distribute my posted example cfg file, if that is of any use! Of course, with your new version just round the corner, I suppose it would not affect many people. > Our upcoming update to the tools has implemented a much better xml based > initialization scheme, which we have fully documented. It specifies > both board initialization and board memory maps. > I guess you need that for your support for flash programming as well, so that makes sense. I hope your flash programming utilities support command-line access, rather than forcing the use of a gui (as Freescale's flash program does, as far as I can see) - I like to have a "burn" make target during development. >> I'd still like to know how to change cpu-space registers from with >> gdb, if anyone has any ideas - for some processors, it is important to >> be able to do things like turn caching on and off while debugging. > > This is not possible with the current gdb -- the bdm.sourceforge.net > patches have not been contributed to FSF gdb. That said, control > register access from gdb is on our todo list, but won't be available in > the near term. > I suppose the trouble with using the bdm.sourceforge.net patches is that the copyright has not been transferred to the FSF, so that it could never become an official part of the gdb tree? On other gdb + proxy setups I have used, the "monitor" command is used to pass commands directly to the proxy program, and as far as I know this is done without changes to gdb. The msp430 proxy program, for example, handles commands like "monitor erase" to erase the microcontroller's flash. That would perhaps be an easier route to add functionality than implementing bdm specific commands in gdb. > In the meantime you could include a function of the form > > void set_cache_debug (unsigned v) { > __asm__ __volatile__ ("movec.l %0,%/cacr" :: "r" (v) : "memory"); > } > > in your application and use it from gdb with > > (gdb) call set_cache_debug(0xWHATEVER) > Yes, that's what I had planned to do (although I had thought of setting up such functions from within my .gdbinit file rather than in the program being debugged). At the moment, the card I am working on has a MCF5213, and I don't need to write to any cpu space registers after the initial setup. I'll need it later for further work on an MCF5234 card, but that will be some time in the future. > > nathan > From dan at codesourcery.com Wed Nov 15 14:56:58 2006 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Wed, 15 Nov 2006 09:56:58 -0500 Subject: [coldfire-gnu-discuss] Using m68k-elf-cfpe-stub with our own board In-Reply-To: <455B2AD2.2060100@westcontrol.com> References: <455B0D3B.1040109@westcontrol.com> <455B1353.30306@westcontrol.com> <455B14A2.1070100@codesourcery.com> <455B2AD2.2060100@westcontrol.com> Message-ID: <20061115145657.GR26643@caradoc.them.org> On Wed, Nov 15, 2006 at 03:57:22PM +0100, David Brown wrote: > >Our upcoming update to the tools has implemented a much better xml based > >initialization scheme, which we have fully documented. It specifies > >both board initialization and board memory maps. > > > > I guess you need that for your support for flash programming as well, so > that makes sense. I hope your flash programming utilities support > command-line access, rather than forcing the use of a gui (as > Freescale's flash program does, as far as I can see) - I like to have a > "burn" make target during development. Yes indeed. Our flash programming is based on GDB; it works either from Eclipse or from the GDB command line, and on the command line you can use GDB command scripts and -batch to automate it. > On other gdb + proxy setups I have used, the "monitor" command is used > to pass commands directly to the proxy program, and as far as I know > this is done without changes to gdb. The msp430 proxy program, for > example, handles commands like "monitor erase" to erase the > microcontroller's flash. That would perhaps be an easier route to add > functionality than implementing bdm specific commands in gdb. Yes, but it's somewhat limited, and doesn't scale well e.g. to IDEs; it's our goal to support both command line and IDE development well. Unlike a lot of people developing board support, CodeSourcery has the ability and motivation to improve GDB instead of short-circuiting around it - and in this specific case we have a thorough plan for access to board specific registers. Implementation is still in progress, though! > >In the meantime you could include a function of the form > > > >void set_cache_debug (unsigned v) { > > __asm__ __volatile__ ("movec.l %0,%/cacr" :: "r" (v) : "memory"); > >} > > > >in your application and use it from gdb with > > > >(gdb) call set_cache_debug(0xWHATEVER) > > > > Yes, that's what I had planned to do (although I had thought of setting > up such functions from within my .gdbinit file rather than in the > program being debugged). If nothing else, you can probably combine these two plans. This is not a general or elegant solution, mind you, just a temporary hack, but the GDB trick may be useful if you need it. This is the same principle many JTAG interfaces use, though they have better ways to do it than the stack, and this only works once the stack and memory are set up... # Untested define set_cacr set $sp = $sp - 16 set {short}$sp = 0x1111 # movec.l... set {short}($sp+2) = 0x2222 # ...%d0, %cacr set {short}($sp+4) = 0x4444 # ret set $p = (void (*) (int)) $sp call $p($arg1) set $sp = $sp + 16 end -- Daniel Jacobowitz CodeSourcery From david at westcontrol.com Wed Nov 15 15:41:45 2006 From: david at westcontrol.com (David Brown) Date: Wed, 15 Nov 2006 16:41:45 +0100 Subject: [coldfire-gnu-discuss] trapf opcode In-Reply-To: <455B2230.10604@codesourcery.com> References: <59789F6B85725F4CAD78243CDDBA4C6627364F@SERVA.grange.local> <455B2230.10604@codesourcery.com> Message-ID: <455B3539.2060609@westcontrol.com> Nathan Sidwell wrote: > Paul McConkey wrote: > >> So the assembler supports trapf, which is fine, but are you likely to >> support the CF syntax below in future? If so, will you deprecate or >> remove the support for trapf? >> >> CFPRM rev.3 p 4-83 >> >> Assembler syntax: TPF PC + 2 -> PC >> TPF.W PC + 4 -> PC >> TPF.L PC + 6 -> PC > > oh joy. trapf is the cpu32 instruction name, coldfire appears to have > selected a different name for the same encoding. > > We won't remove trapf, but will probably accept 'tpf' as an alternative. > > nathan > The TRAPcc instruction in the cpu32 was a bit more general, and could trap to vector 7 on a given condition code (the same as for branches). The Coldfire does not really implement these instructions (vector 7 is "reserved"). However, TRAPF, which never actually traps, is still there as it is useful as a sort of "skip next instruction" instruction. I guess they renamed it to stop people expecting TRAPZ and all the other TRAPcc instructions. The ColdFire manual gives an idea of how the TPF.W and TPF.L instructions can be as "bra.b +2" and "bra.b +4" alternatives, taking 1 clock cycle instead of 2. This could perhaps be implemented as a peephole optimisation after initial code generation. Of course, it would work better if gcc generated better code for something like: extern unsigned long int a, b, z; void test(void) { if (a == b) { z = 3; } else { z = 1; }; } Today it generates: 37 test: 38 0000 4E56 0000 link.w %fp,#0 39 0004 2039 0000 move.l b,%d0 | b, 39 0000 40 000a B0B9 0000 cmp.l a.l,%d0 | a, 40 0000 41 0010 670A jbeq .L7 | 42 0012 7001 moveq #1,%d0 |, 43 0014 23C0 0000 move.l %d0,z |, z 43 0000 44 001a 6008 jbra .L5 | 45 .L7: 46 001c 7003 moveq #3,%d0 |, 47 001e 23C0 0000 move.l %d0,z |, z 47 0000 48 .L5: 49 0024 4E5E unlk %fp 50 0026 4E75 rts If that were optimised to shorter code with the duplicate "move.l %d, z" moved to after .L5: test: link.w %fp, #0 move.l b, %d0 cmp.l a.l, %d0 jbeq .L7 moveq #1, %d0 jbra .L5 .L7: moveq #3, %d0 .L5: move.l %d0, z unlk %fp rts Then the TPF.W instruction could be used instead of the jbra instruction, saving a clock cycle. On the more advanced Coldfire cores with more pipelining, the TPF instruction may save even more than a branch. mvh., David From david at westcontrol.com Wed Nov 15 15:52:32 2006 From: david at westcontrol.com (David Brown) Date: Wed, 15 Nov 2006 16:52:32 +0100 Subject: [coldfire-gnu-discuss] Using m68k-elf-cfpe-stub with our own board In-Reply-To: <20061115145657.GR26643@caradoc.them.org> References: <455B0D3B.1040109@westcontrol.com> <455B1353.30306@westcontrol.com> <455B14A2.1070100@codesourcery.com> <455B2AD2.2060100@westcontrol.com> <20061115145657.GR26643@caradoc.them.org> Message-ID: <455B37C0.4020307@westcontrol.com> Daniel Jacobowitz wrote: > On Wed, Nov 15, 2006 at 03:57:22PM +0100, David Brown wrote: >>> Our upcoming update to the tools has implemented a much better xml based >>> initialization scheme, which we have fully documented. It specifies >>> both board initialization and board memory maps. >>> >> I guess you need that for your support for flash programming as well, so >> that makes sense. I hope your flash programming utilities support >> command-line access, rather than forcing the use of a gui (as >> Freescale's flash program does, as far as I can see) - I like to have a >> "burn" make target during development. > > Yes indeed. Our flash programming is based on GDB; it works either > from Eclipse or from the GDB command line, and on the command line you > can use GDB command scripts and -batch to automate it. > That would be fine for me. I use gdb scripts and batch programming on other cards - it's easy to combine card test and programming setups for production use with gdb scripts. >> On other gdb + proxy setups I have used, the "monitor" command is used >> to pass commands directly to the proxy program, and as far as I know >> this is done without changes to gdb. The msp430 proxy program, for >> example, handles commands like "monitor erase" to erase the >> microcontroller's flash. That would perhaps be an easier route to add >> functionality than implementing bdm specific commands in gdb. > > Yes, but it's somewhat limited, and doesn't scale well e.g. to IDEs; > it's our goal to support both command line and IDE development well. > > Unlike a lot of people developing board support, CodeSourcery has the > ability and motivation to improve GDB instead of short-circuiting > around it - and in this specific case we have a thorough plan for > access to board specific registers. Implementation is still in > progress, though! > Sometimes short-cuts are easiest, and sometimes it is best to spend the time and effort doing a full job to make life easier later. I use gcc toolchains on a range of targets, and it is often annoying that embedded target features like interrupts or debugging peculiarities are different for every target instead of having a common solution. Since there is a perfectly workable hack for this issue (putting the code on the stack is a nice idea), I have no problems with waiting for you guys to implement a more complete solution. mvh., David >>> In the meantime you could include a function of the form >>> >>> void set_cache_debug (unsigned v) { >>> __asm__ __volatile__ ("movec.l %0,%/cacr" :: "r" (v) : "memory"); >>> } >>> >>> in your application and use it from gdb with >>> >>> (gdb) call set_cache_debug(0xWHATEVER) >>> >> Yes, that's what I had planned to do (although I had thought of setting >> up such functions from within my .gdbinit file rather than in the >> program being debugged). > > If nothing else, you can probably combine these two plans. This is not > a general or elegant solution, mind you, just a temporary hack, but the > GDB trick may be useful if you need it. This is the same principle > many JTAG interfaces use, though they have better ways to do it than > the stack, and this only works once the stack and memory are set up... > > # Untested > define set_cacr > set $sp = $sp - 16 > set {short}$sp = 0x1111 # movec.l... > set {short}($sp+2) = 0x2222 # ...%d0, %cacr > set {short}($sp+4) = 0x4444 # ret > set $p = (void (*) (int)) $sp > call $p($arg1) > set $sp = $sp + 16 > end > From dan at codesourcery.com Wed Nov 15 16:18:52 2006 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Wed, 15 Nov 2006 11:18:52 -0500 Subject: [coldfire-gnu-discuss] Using m68k-elf-cfpe-stub with our own board In-Reply-To: <455B37C0.4020307@westcontrol.com> References: <455B0D3B.1040109@westcontrol.com> <455B1353.30306@westcontrol.com> <455B14A2.1070100@codesourcery.com> <455B2AD2.2060100@westcontrol.com> <20061115145657.GR26643@caradoc.them.org> <455B37C0.4020307@westcontrol.com> Message-ID: <20061115161851.GW26643@caradoc.them.org> On Wed, Nov 15, 2006 at 04:52:32PM +0100, David Brown wrote: > Sometimes short-cuts are easiest, and sometimes it is best to spend the > time and effort doing a full job to make life easier later. I use gcc > toolchains on a range of targets, and it is often annoying that embedded > target features like interrupts or debugging peculiarities are different > for every target instead of having a common solution. Yes indeed. We can only control our own debug agents and toolchains of course - but within that sphere, I hope we can keep these things consistent within the wide range of platforms we support. -- Daniel Jacobowitz CodeSourcery From pedro.nicolas at cticontrol.com Mon Nov 20 17:37:47 2006 From: pedro.nicolas at cticontrol.com (=?ISO-8859-1?Q?Pedro_Nicol=E1s?=) Date: Mon, 20 Nov 2006 18:37:47 +0100 Subject: M5213 with P&E micro BDM Message-ID: <4561E7EB.2050900@cticontrol.com> I'm trying to used the m68k-elf-gdb with my mcf5213's board and pemicro USBMultilink. I used a pemicro code from their winide startet edition, the code compile fine with m68k-elf-gcc and done and .s19 / .elf. I programed the s19 in my micro and it worked fine (I hope). When I tried to debugging the code I done this steps: $ m68k-elf-gdb example.elf (gdb) target remote | m68k-elf-cfpe-stub -d USBMultilink -t m5213evb -s 10 Remote debugging using | m68k-elf-cfpe-stub -d USBMultilink -t m5213evb -s 10 m68k-elf-cfpe-stub:Opening USBMultilink port 1 (USB1 : USB-ML-CF Rev C (PE6012359)) 0x2a008dfc in ?? () (gdb) load Loading section .pevector, size 0x400 lma 0x0 Memory access error while loading section .pevector. I dont know the mean of this error :S. Somebody help me? some source of example for the 5213? with de .elf and .s19? Thanks. From nathan at codesourcery.com Mon Nov 20 18:14:56 2006 From: nathan at codesourcery.com (Nathan Sidwell) Date: Mon, 20 Nov 2006 18:14:56 +0000 Subject: [coldfire-gnu-discuss] M5213 with P&E micro BDM In-Reply-To: <4561E7EB.2050900@cticontrol.com> References: <4561E7EB.2050900@cticontrol.com> Message-ID: <4561F0A0.3000508@codesourcery.com> Pedro Nicol?s wrote: > load > Loading section .pevector, size 0x400 lma > 0x0 > Memory access error while loading section .pevector. The 5213 memory map has ROM at address zero, which is why this doesn't work. Flash programming has yet to be added. 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 Nov 20 18:27:30 2006 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Mon, 20 Nov 2006 13:27:30 -0500 Subject: [coldfire-gnu-discuss] M5213 with P&E micro BDM In-Reply-To: <4561F0A0.3000508@codesourcery.com> References: <4561E7EB.2050900@cticontrol.com> <4561F0A0.3000508@codesourcery.com> Message-ID: <20061120182728.GM21931@caradoc.them.org> On Mon, Nov 20, 2006 at 06:14:56PM +0000, Nathan Sidwell wrote: > Pedro Nicol?s wrote: > > >load > >Loading section .pevector, size 0x400 lma > >0x0 > >Memory access error while loading section .pevector. > > The 5213 memory map has ROM at address zero, which is why this doesn't work. > > Flash programming has yet to be added. If you've already programmed the flash using a separate tool, you can probably skip "load". I believe the device will automatically have the correct PC value after connecting; if it doesn't, you may need to use "jump *_start" to start the program. -- Daniel Jacobowitz CodeSourcery From david at westcontrol.com Thu Nov 23 10:20:53 2006 From: david at westcontrol.com (David Brown) Date: Thu, 23 Nov 2006 11:20:53 +0100 Subject: Newlib reentrancy structure overhead Message-ID: <45657605.80607@westcontrol.com> Hi, Does anyone know if there is a way to get access to the newlib c library functions without the overhead of the re-entrancy support? When working on a small system, it can be very significant - any standard library function that uses "errno" gets a 1024 byte impure_data structure, and all access to c library global data pass through an extra layer of indirection (reading or setting errno requires a function call). mvh., David From nathan at codesourcery.com Thu Nov 23 10:46:58 2006 From: nathan at codesourcery.com (Nathan Sidwell) Date: Thu, 23 Nov 2006 10:46:58 +0000 Subject: [coldfire-gnu-discuss] Newlib reentrancy structure overhead In-Reply-To: <45657605.80607@westcontrol.com> References: <45657605.80607@westcontrol.com> Message-ID: <45657C22.4000701@codesourcery.com> David Brown wrote: > Hi, > > Does anyone know if there is a way to get access to the newlib c library > functions without the overhead of the re-entrancy support? When working > on a small system, it can be very significant - any standard library > function that uses "errno" gets a 1024 byte impure_data structure, and > all access to c library global data pass through an extra layer of > indirection (reading or setting errno requires a function call). unfortunately not. newlib is designed as a reentrant library and has no configure option to make it not so. Of course, such capability could be added, but it would be significant work and we have no current plans to do so. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From matsblide at hotmail.com Thu Nov 23 11:19:16 2006 From: matsblide at hotmail.com (Mats Blide) Date: Thu, 23 Nov 2006 11:19:16 +0000 Subject: Using GDB with Coldfire M52233DEMO ev-board.. Message-ID: Hi, I'am trying to get started with coldfire and have a ev-boad M52233DEMO. I have loaded a program into flash using CF-flasher. And connected to GDB through m68k-elf-cfpe-stub.exe. Whitout realy knowing what I'am doing, I'am a complet novis on GDB, I have be able to get some basic controll over the execution of my program. But I am not able make breakpoints to work. If I set a breakpoint and then try to free run the program to that breakpoint I get: " (gdb) b GoAexit Breakpoint 3 at 0x46a: file MyFile.S, line 106. (gdb) continue Continuing. Warning: Cannot insert breakpoint 3. Error accessing memory address 0x46a: (undocumented errno -1). " If I try to single step I get the same problem untill I remove the breakpoint. Is this du to something I'am doing wrong or simply because the stub/gdb is not able to handle this board? Rgds, Mats _________________________________________________________________ Byt jobb efter f?r?ldraledigheten http://monster.msn.se/ From nathan at codesourcery.com Thu Nov 23 11:26:11 2006 From: nathan at codesourcery.com (Nathan Sidwell) Date: Thu, 23 Nov 2006 11:26:11 +0000 Subject: [coldfire-gnu-discuss] Using GDB with Coldfire M52233DEMO ev-board.. In-Reply-To: References: Message-ID: <45658553.204@codesourcery.com> Mats Blide wrote: > > Hi, > > I'am trying to get started with coldfire and have a ev-boad M52233DEMO. > I have loaded a program into flash using CF-flasher. And connected to > GDB through m68k-elf-cfpe-stub.exe. Whitout realy knowing what I'am > doing, I'am a complet novis on GDB, I have be able to get some basic > controll over the execution of my program. But I am not able make > breakpoints to work. If I set a breakpoint and then try to free run the > program to that breakpoint I get: You need to tell gdb to use hardware breakpoints (hbreak GoAexit). Also, you'll find that next and step won't work well with ROM, because they still insist on using patched breakpoints. Both these issues are fixed in our upcoming update. Because you're running a program from rom, without using 'load', you'll need to set $pc to the entry point of your program. This can be done by set $pc *_start continue or more simply jump *_start (replace _start with whatever the right entry point is) 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 Thu Nov 23 11:24:47 2006 From: paul.mcconkey at cambridgeimaging.co.uk (Paul McConkey) Date: Thu, 23 Nov 2006 11:24:47 -0000 Subject: [coldfire-gnu-discuss] Using GDB with Coldfire M52233DEMO ev-board.. In-Reply-To: Message-ID: <59789F6B85725F4CAD78243CDDBA4C662BAD34@SERVA.grange.local> [Quote] I'am trying to get started with coldfire and have a ev-boad M52233DEMO. I have loaded a program into flash using CF-flasher. And connected to GDB through m68k-elf-cfpe-stub.exe. Whitout realy knowing what I'am doing, I'am a complet novis on GDB, I have be able to get some basic controll over the execution of my program. But I am not able make breakpoints to work. If I set a breakpoint and then try to free run the program to that breakpoint I get: " (gdb) b GoAexit Breakpoint 3 at 0x46a: file MyFile.S, line 106. (gdb) continue Continuing. Warning: Cannot insert breakpoint 3. Error accessing memory address 0x46a: (undocumented errno -1). " If I try to single step I get the same problem untill I remove the breakpoint. Is this du to something I'am doing wrong or simply because the stub/gdb is not able to handle this board? [/Quote] It sounds like you are trying to set a software breakpoint on code in flash. The debugger needs to insert code at the break point so this will only work if your code is executing in writable RAM. Try setting a hardware assisted break point instead (I think that your CPU should support one hw breakpoint). The gdb commands are the same as for software breakpoints, but with an h in front: (gdb) hb GoAexit Cheers, Paul. From matsblide at hotmail.com Thu Nov 23 12:04:37 2006 From: matsblide at hotmail.com (Mats Blide) Date: Thu, 23 Nov 2006 12:04:37 +0000 Subject: [coldfire-gnu-discuss] Using GDB with Coldfire M52233DEMO ev-board.. In-Reply-To: <45658553.204@codesourcery.com> Message-ID: Thank you guys that's realy what I wanted to know :-). If I want to have a GUI to GDB, is there any that would work. I have tried Zylin CDT plugin to Eclips but it didn't work or rather gives me the same problem as I explaind earlier. And after this discussion I realise that it my not be able to handle the board I'am using. Rgds, Mats >From: Nathan Sidwell >To: Mats Blide >CC: coldfire-gnu-discuss at codesourcery.com >Subject: Re: [coldfire-gnu-discuss] Using GDB with Coldfire M52233DEMO >ev-board.. >Date: Thu, 23 Nov 2006 11:26:11 +0000 > >Mats Blide wrote: >> >>Hi, >> >>I'am trying to get started with coldfire and have a ev-boad M52233DEMO. I >>have loaded a program into flash using CF-flasher. And connected to GDB >>through m68k-elf-cfpe-stub.exe. Whitout realy knowing what I'am doing, >>I'am a complet novis on GDB, I have be able to get some basic controll >>over the execution of my program. But I am not able make breakpoints to >>work. If I set a breakpoint and then try to free run the program to that >>breakpoint I get: > >You need to tell gdb to use hardware breakpoints (hbreak GoAexit). Also, >you'll find that next and step won't work well with ROM, because they still >insist on using patched breakpoints. > >Both these issues are fixed in our upcoming update. > >Because you're running a program from rom, without using 'load', you'll >need to set $pc to the entry point of your program. This can be done by > set $pc *_start > continue >or more simply > jump *_start > >(replace _start with whatever the right entry point is) > >nathan >-- >Nathan Sidwell :: http://www.codesourcery.com :: >CodeSourcery >nathan at codesourcery.com :: >http://www.planetfall.pwp.blueyonder.co.uk > _________________________________________________________________ Kom i balans http://www.msn.se/halsa/ From nathan at codesourcery.com Thu Nov 23 12:29:11 2006 From: nathan at codesourcery.com (Nathan Sidwell) Date: Thu, 23 Nov 2006 12:29:11 +0000 Subject: [coldfire-gnu-discuss] Using GDB with Coldfire M52233DEMO ev-board.. In-Reply-To: References: Message-ID: <45659417.10702@codesourcery.com> Mats Blide wrote: > > Thank you guys that's realy what I wanted to know :-). > > If I want to have a GUI to GDB, is there any that would work. I have > tried Zylin CDT plugin to Eclips but it didn't work or rather gives me > the same problem as I explaind earlier. And after this discussion I > realise that it my not be able to handle the board I'am using. SourceryG++ contains eclipse with plugins tailored to the coldfire toolchain. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk From julian at codesourcery.com Thu Nov 23 13:20:32 2006 From: julian at codesourcery.com (Julian Brown) Date: Thu, 23 Nov 2006 13:20:32 +0000 Subject: [coldfire-gnu-discuss] Newlib reentrancy structure overhead In-Reply-To: <45657C22.4000701@codesourcery.com> References: <45657605.80607@westcontrol.com> <45657C22.4000701@codesourcery.com> Message-ID: <4565A020.70904@codesourcery.com> Nathan Sidwell wrote: > > unfortunately not. newlib is designed as a reentrant library and has no > configure option to make it not so. > > Of course, such capability could be added, but it would be significant > work and we have no current plans to do so. (Internal only) What does REENTRANT_SYSCALLS_PROVIDED do, then? I was vaguely under the impression it was possible to configure a non-reentrant Newlib, though it's been a long time since I played with that bit... of course, things will probably break if you do so anyway :-) Cheers, Julian From julian at codesourcery.com Thu Nov 23 13:25:48 2006 From: julian at codesourcery.com (Julian Brown) Date: Thu, 23 Nov 2006 13:25:48 +0000 Subject: [coldfire-gnu-discuss] Newlib reentrancy structure overhead In-Reply-To: <4565A020.70904@codesourcery.com> References: <45657605.80607@westcontrol.com> <45657C22.4000701@codesourcery.com> <4565A020.70904@codesourcery.com> Message-ID: <4565A15C.8060909@codesourcery.com> Julian Brown wrote: > Nathan Sidwell wrote: >> >> unfortunately not. newlib is designed as a reentrant library and has >> no configure option to make it not so. >> >> Of course, such capability could be added, but it would be significant >> work and we have no current plans to do so. > > (Internal only) > > What does REENTRANT_SYSCALLS_PROVIDED do, then? I was vaguely under the > impression it was possible to configure a non-reentrant Newlib, though > it's been a long time since I played with that bit... of course, things > will probably break if you do so anyway :-) Sorry, apparently this wasn't internal only, and actually looking at the code, I appear to be totally wrong anyway. Ignore me... :-) Cheers, Julian From matsblide at hotmail.com Fri Nov 24 13:48:17 2006 From: matsblide at hotmail.com (Mats Blide) Date: Fri, 24 Nov 2006 13:48:17 +0000 Subject: MCF52233 Message-ID: What compiler switch to use for coldfire MCF52233. Tried ?m5200 but when trying the code in GDB I get: ? (gdb) set $pc=start Current language: auto; currently asm (gdb) cont Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x4408271c in ?? () ? The switch I used ?m528x made runnable code, but the code I now try to assemble contains reference to RAMBAR1 giving me compilation error with switch ?m528x but not with ?m5200. I?m a complete beginner with GNU tools and coldfire. So this might be a stupid question, but any help is appreciated. Rgds Mats _________________________________________________________________ Hitta snyggingar i ditt l?n http://match.se.msn.com From david at westcontrol.com Fri Nov 24 14:22:45 2006 From: david at westcontrol.com (David Brown) Date: Fri, 24 Nov 2006 15:22:45 +0100 Subject: [coldfire-gnu-discuss] MCF52233 In-Reply-To: References: Message-ID: <45670035.2020208@westcontrol.com> Mats Blide wrote: > What compiler switch to use for coldfire MCF52233. Tried ?m5200 but when > trying the code in GDB I get: > > ? > (gdb) set $pc=start > Current language: auto; currently asm > (gdb) cont > Continuing. > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x4408271c in ?? () > ? > > The switch I used ?m528x made runnable code, but the code I now try to > assemble contains reference to RAMBAR1 giving me compilation error with > switch ?m528x but not with ?m5200. I?m a complete beginner with GNU > tools and coldfire. So this might be a stupid question, but any help is > appreciated. > > Rgds > Mats > Try the -mcpu=52233 switch instead of the -m52xx - that way you can be sure you are getting the write options. From paul.mcconkey at cambridgeimaging.co.uk Fri Nov 24 14:14:19 2006 From: paul.mcconkey at cambridgeimaging.co.uk (Paul McConkey) Date: Fri, 24 Nov 2006 14:14:19 -0000 Subject: [coldfire-gnu-discuss] MCF52233 In-Reply-To: Message-ID: <59789F6B85725F4CAD78243CDDBA4C662BADAE@SERVA.grange.local> > The switch I used -m528x made runnable code, but the code I now try to assemble contains reference to RAMBAR1 > giving me compilation error with switch -m528x but not with -m5200. I'm a complete beginner with GNU tools and > coldfire. So this might be a stupid question, but any help is appreciated. With some cpu switches gcc appears to use RAMBAR and RAMBAR1 as synonyms as they are the same thing in CF V2 cores, if you still have problems with the -mcpu=52233 switch, try changing the source to refer to RAMBAR instead of RAMBAR1. Cheers, Paul. From matsblide at hotmail.com Fri Nov 24 14:25:49 2006 From: matsblide at hotmail.com (Mats Blide) Date: Fri, 24 Nov 2006 14:25:49 +0000 Subject: [coldfire-gnu-discuss] MCF52233 In-Reply-To: <59789F6B85725F4CAD78243CDDBA4C662BADAE@SERVA.grange.local> Message-ID: Thanks for your answerer. What about RAMBAR0 :-). I must say I am a bit surprised to finde these built into the compiler. I expected to find such things defined in some header file. I?ll try your suggestions. Rgds Mats >From: "Paul McConkey" >To: "Mats Blide" >, >Subject: RE: [coldfire-gnu-discuss] MCF52233 >Date: Fri, 24 Nov 2006 14:14:19 -0000 > > > The switch I used -m528x made runnable code, but the code I now try to >assemble contains reference to RAMBAR1 > > giving me compilation error with switch -m528x but not with -m5200. >I'm a complete beginner with GNU tools and > > coldfire. So this might be a stupid question, but any help is >appreciated. > >With some cpu switches gcc appears to use RAMBAR and RAMBAR1 as synonyms >as they are the same thing in CF V2 cores, if you still have problems >with the -mcpu=52233 switch, try changing the source to refer to RAMBAR >instead of RAMBAR1. > > >Cheers, > >Paul. _________________________________________________________________ Premi?r 17/11 f?r Casino Royale! http://www.msn.se/noje/casinoroyale/ From matsblide at hotmail.com Fri Nov 24 14:36:21 2006 From: matsblide at hotmail.com (Mats Blide) Date: Fri, 24 Nov 2006 14:36:21 +0000 Subject: [coldfire-gnu-discuss] MCF52233 In-Reply-To: <45670035.2020208@westcontrol.com> Message-ID: error: bad value (52233) for -mcpu= switch :-) /Mats >From: David Brown >To: Mats Blide >CC: coldfire-gnu-discuss at codesourcery.com >Subject: Re: [coldfire-gnu-discuss] MCF52233 >Date: Fri, 24 Nov 2006 15:22:45 +0100 > >Mats Blide wrote: >>What compiler switch to use for coldfire MCF52233. Tried ?m5200 but when >>trying the code in GDB I get: >> >>? >>(gdb) set $pc=start >>Current language: auto; currently asm >>(gdb) cont >>Continuing. >> >>Program received signal SIGTRAP, Trace/breakpoint trap. >>0x4408271c in ?? () >>? >> >>The switch I used ?m528x made runnable code, but the code I now try to >>assemble contains reference to RAMBAR1 giving me compilation error with >>switch ?m528x but not with ?m5200. I?m a complete beginner with GNU tools >>and coldfire. So this might be a stupid question, but any help is >>appreciated. >> >>Rgds >>Mats >> > >Try the -mcpu=52233 switch instead of the -m52xx - that way you can be sure >you are getting the write options. > > _________________________________________________________________ Hitta snyggingar i ditt l?n http://match.se.msn.com From paul.mcconkey at cambridgeimaging.co.uk Fri Nov 24 14:52:45 2006 From: paul.mcconkey at cambridgeimaging.co.uk (Paul McConkey) Date: Fri, 24 Nov 2006 14:52:45 -0000 Subject: [coldfire-gnu-discuss] MCF52233 In-Reply-To: Message-ID: <59789F6B85725F4CAD78243CDDBA4C662BADB5@SERVA.grange.local> It's actually the assembler that deals with the CPU registers. This is from CODESOURCERY\SOURCE\BINUTILS-2.17\GAS\config\tc-m68k.c(3029): case FLASHBAR: case RAMBAR0: tmpreg = 0xC04; break; case RAMBAR: case RAMBAR1: tmpreg = 0xC05; break; So you can see that RAMBAR0 is also known as FLASHBAR (at least in this version of the source) :) Paul. -----Original Message----- From: Mats Blide [mailto:matsblide at hotmail.com] Sent: 24 November 2006 14:26 To: Paul McConkey; coldfire-gnu-discuss at codesourcery.com Subject: RE: [coldfire-gnu-discuss] MCF52233 Thanks for your answerer. What about RAMBAR0 :-). I must say I am a bit surprised to finde these built into the compiler. I expected to find such things defined in some header file. I'll try your suggestions. Rgds Mats >From: "Paul McConkey" >To: "Mats Blide" >, >Subject: RE: [coldfire-gnu-discuss] MCF52233 >Date: Fri, 24 Nov 2006 14:14:19 -0000 > > > The switch I used -m528x made runnable code, but the code I now try > > to >assemble contains reference to RAMBAR1 > > giving me compilation error with switch -m528x but not with -m5200. >I'm a complete beginner with GNU tools and > > coldfire. So this might be a stupid question, but any help is >appreciated. > >With some cpu switches gcc appears to use RAMBAR and RAMBAR1 as >synonyms as they are the same thing in CF V2 cores, if you still have >problems with the -mcpu=52233 switch, try changing the source to refer >to RAMBAR instead of RAMBAR1. > > >Cheers, > >Paul. _________________________________________________________________ Premi?r 17/11 f?r Casino Royale! http://www.msn.se/noje/casinoroyale/ From nathan at codesourcery.com Fri Nov 24 15:41:59 2006 From: nathan at codesourcery.com (Nathan Sidwell) Date: Fri, 24 Nov 2006 15:41:59 +0000 Subject: [coldfire-gnu-discuss] MCF52233 In-Reply-To: References: Message-ID: <456712C7.902@codesourcery.com> Mats Blide wrote: > What compiler switch to use for coldfire MCF52233. Tried ?m5200 but when > trying the code in GDB I get: m52233 support has not been released yet. It'll be in this month's update :) To target it with the current public toolchain you can select a different cpu that happens to have the same instruction set and the set of control registers you want. The assembler is responsible for knowing about various control registers like RAMBAR. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan at codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk