embedded gcc linker issue--trying to build for m68000 cpu [Embedded]

Prev: LPC2888 Flash programming using DFU.
Next: servo motor controller using dspic

From: Chris Burrows on 5 Nov 2009 07:34

"Jim" <adirondackmtn(a)yahoo.com> wrote in message
news:14e64133-7221-449b-8240-6459f8325397(a)o13g2000vbl.googlegroups.com...
> - The target cpu is truly a 68000 core (the old Dragonball EZ328).

> - I'm using my own OS on the embedded system (no Linux).

> I want to do my
> development work in MS Windows

> - I'm coding mostly from scratch.

> - The only two languages I'll consider using for embedded projects are
> C and C++ (plus the little bit of necessary assembly). It's what I'm
> really familiar with.

> - I don't really care if the object code is COFF or ELF. The
> executable has to be straight binary though.

> First, I'll look for other precompiled
> binaries for MS Windows.
>

If you hit a brick wall with gcc check out the Manx Aztec C68K MS-DOS
cross-compiler. AFAIR Aztec C had a great reputation in the 1980's.

The software rebundled for Windows XP is here:

http://www.aztecmuseum.ca/compilers.htm#aztec68K

The manual is here:

http://www.bitsavers.org/pdf/manx/

--
Chris Burrows
CFB Software
http://www.cfbsoftware.com

From: ChrisQ on 5 Nov 2009 08:05

From: David Brown on 5 Nov 2009 08:28

Jim wrote:
> First, I'd like to thank everyone for their input! Second, I'd like
> to answer some of the questions so no one feels left out:
>
> - The target cpu is truly a 68000 core (the old Dragonball EZ328).
> Now, to avoid the "why": it's a Palm pda which has a display and
> formfactor that I need and it's cheap.
> - I'm using my own OS on the embedded system (no Linux).
> - Now that I think about it, I upgraded my Linux box to 2.4, so I'm
> not that "ancient" :). I have a 2.6 one at work. I want to do my
> development work in MS Windows, but I could build libgcc on Linux, if
> I have to).

These days, gcc and related tools can all be built happily on windows
with mingw and msys. Building on Linux can be much faster and easier,
especially if you want to do the optional parts like building the man
pages or using the autoconf stuff, but for the compiler and libraries
there should be no real problem - if you still want to do that. The
source download from CodeSourcery should give you what you need, in
addition to mingw and msys. You may need to get a few of the extra
mingw/msys packages.

> - I read the GettingStarted guide and I looked at all the libgcc.a
> files: all seem to be ColdFire based :(.

Yes, it looks very much like that's the only libraries they have
pre-built. But the compiler certainly supports it the 68000 devices.

An alternative idea is just to find some older binaries from around the
net. CodeSourcery always has the latest versions with the newest
features, since they are the maintainers, but there are plenty of other
builds around. Development tool resellers and debugger vendors often
have packages to download - try some and see if you get the right
libraries there, saving you some effort. For example,

<http://www.macraigor.com/full_gnu.htm>

> - I'm coding mostly from scratch. However, I'm using a modified GDB
> stub from David Williams.
> - The only two languages I'll consider using for embedded projects are
> C and C++ (plus the little bit of necessary assembly). It's what I'm
> really familiar with.
> - I don't really care if the object code is COFF or ELF. The
> executable has to be straight binary though.
> - I use gcc for linking. But I still need to explicitly say -lgcc
> because of the -nodefaultlibs linker flag (I think). For the sake of
> completeness, my compile and link lines are:
>
> m68k-elf-gcc -o bin/main.o -m68000 -I. -I../shared -fno-exceptions -
> Wall -Wa,-m68000 -ggdb -c main.c
>
> m68k-elf-gcc -Wl,-T,RadioTest.ldi bin/MyStartup.o bin/main.o bin/
> Timer.o -o bin/RadioTest.elf -m68000 -I. -I../shared -fno-exceptions -
> Wall -Wa,-m68000 -ggdb -Wl,-Map,bin/RadioTest.map,--cref -nostdlib -
> nostartfiles -nodefaultlibs -lgcc
>
>
> So, I think the general consensus is I only get ColdFire micro support
> with CodeSourcery and I agree with this. I can understand why
> CodeSourcery may want to ignore older cores. However, don't they
> still make micros with that (68000 based) core? I might email them,
> but since I'm using the free version, I feel funny bothering them with
> this (they do need to earn a living). Purchasing it would be a real
> gamble since they do say it's a ColdFire compiler on their website
> (and for home use, it's kinda a pricey gamble).
>

The support for the free version is a mailing list. You don't get any
guarantees of an answer, and it might be from another user rather than a
CodeSourcery developer, but my experience is that they are helpful
regardless of whether or not the poster is a customer. You should feel
entirely free to post to these lists. They will also be able to tell
you whether the commercial versions of their tools have the right
pre-built libraries (you can also download a 30-day trial version of
those tools).

Another mailing list of possible interest is coldfire(a)wildrice.com.

> I'm gonna try two things. First, I'll look for other precompiled
> binaries for MS Windows. Maybe I'll luck out. I came across one the
> other day, but now can't remember for the life of me who made it--I'm
> sure it'll turn up in a search.
>
> Second, I'll see if I can build libgcc. I assume I'll get the source
> to this when I download the source to gcc. David suggested I use
> MinGW. I'm pretty sure I'll need "configure" and maybe autoconf &
> automake. I'm not familiar with MinGW: does that package have them?
>

I can't remember off-hand if you get autoconf and automake with the
standard mingw/msys packages - it's a while since I installed a new
version of these tools, and the packaging has changed a little since
then. But you can certainly find out about them on the mingw and msys
websites.

> I just got an idea. PrcTools was a MS Windows compiler for that very
> micro. I remember trying it, but it was a limited 16b compiler trying
> to be compatible with the Palm OS. However, I might be able to use
> its libgcc. The only issue is that compiler is so old it's probably
> COFF based (and of course CodeSourcery is ELF). Nothing's ever
> easy. :)
>

You probably don't want to mix libgcc from a different version than the
gcc compiler. libgcc is a support library for the compiler, and is
closely tied to it - it's not like the standard C library that can be
replaced.

> Well, thanks again for your help everyone. I'll post what I finally
> end up with (in case anyone else needs the info).
>
>
> Jim

From: Jim on 16 Nov 2009 19:16

On Nov 4, 6:58 pm, Jim <adirondack...(a)yahoo.com> wrote:
> First, I'd like to thank everyone for their input! Second, I'd like
> to answer some of the questions so no one feels left out:
>
> - The target cpu is truly a 68000 core (the old Dragonball EZ328).
> Now, to avoid the "why": it's a Palm pda which has a display and
> formfactor that I need and it's cheap.
> - I'm using my own OS on the embedded system (no Linux).
>
> ...text deleted for brevity...
>
> So, I think the general consensus is I only get ColdFire micro support
> with CodeSourcery and I agree with this. I can understand why
> CodeSourcery may want to ignore older cores. However, don't they
> still make micros with that (68000 based) core? I might email them,
> but since I'm using the free version, I feel funny bothering them with
> this (they do need to earn a living). Purchasing it would be a real
> gamble since they do say it's a ColdFire compiler on their website
> (and for home use, it's kinda a pricey gamble).
>
> I'm gonna try two things. First, I'll look for other precompiled
> binaries for MS Windows. Maybe I'll luck out. I came across one the
> other day, but now can't remember for the life of me who made it--I'm
> sure it'll turn up in a search.
>
> Second, I'll see if I can buildlibgcc. I assume I'll get the source
> to this when I download the source to gcc. David suggested I use
> MinGW. I'm pretty sure I'll need "configure" and maybe autoconf &
> automake. I'm not familiar with MinGW: does that package have them?
>
> I just got an idea. PrcTools was a MS Windows compiler for that very
> micro. I remember trying it, but it was a limited 16b compiler trying
> to be compatible with the Palm OS. However, I might be able to use
> itslibgcc. The only issue is that compiler is so old it's probably
> COFF based (and of course CodeSourcery is ELF). Nothing's ever
> easy. :)
>
> Well, thanks again for your help everyone. I'll post what I finally
> end up with (in case anyone else needs the info).
>
> Jim

Problem solved. I looked at the libc files and they were pretty
simple. I think there was only one macro definition I had to figure
out. But, then I realized my next step would be to build newlib and
that wasn't gonna be that simple.

I looked at a bunch of pre-built stuff (thanks again everyone for the
links--I may compare the Aztec C output to gcc someday). I decided I
really wanted GNU because I know the debugger works with Eclipse.
By the way, the other pre-built gcc I was thinking of was www.ronetix.it.
It had everything I needed, but, unfortunately, there was a flaw with
it (either the binary wasn't produced correctly or gdb didn't load it
correctly--I didn't look into it further). One other by ASH WARE was
too old (2.95 and coff based--I wasn't sure an elf type gdb would
handle it). The Macgregor (sp?) didn't run (I need a cygwin dll).

So, I ended up building gcc and newlib using mingw/msys like David
suggested. I was intrigued by the idea. I'm still gonna use
CodeSourcery's gcc though (I figure they ran some of the gcc tests).
I'll just link to the libc, libgcc, etc. produced by me (so far tests
show it's ok). It wasn't TOO bad building the libs. There were some
tricks to get things to build right--I spent some time doing
searches. I think the biggest thing to remember is that many tools
want you to do these three things:
(1) create a folder outside of the source tree to hold intermediate
files.
(2) run configure and build from the folder created in (1)
(3) Use a RELATIVE path when running configure in (2). You can get
weird compile errors otherwise. Unfortunately many docs have scripts
that use the full path (including the one at mingw). Maybe this used
to work for older gcc.

One last thing: gcc needs to build mpfr and gmp. It turns out for
the 4.2.1 and 4.4.2 releases I did, all you have to do it place the
source in the gcc folder (omit the -version part of the folder name).
I'm sure there's other ways to do it as well.

Well, thanks again everyone for all of your input! It was fun (for me
anyways)!!

Jim

From: 42Bastian Schick on 17 Nov 2009 01:58

On Mon, 16 Nov 2009 16:16:15 -0800 (PST), Jim
<adirondackmtn(a)yahoo.com> wrote:

>Well, thanks again everyone for all of your input! It was fun (for me
>anyways)!!

Thanks for follow-up Jim.

--
42Bastian
Do not email to bastian42(a)yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !

First | Prev | Next | Last
Pages: 1 2 3 4 5
Prev: LPC2888 Flash programming using DFU.
Next: servo motor controller using dspic