This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Building for custom 68k or ColdFire board without OS?



Toralf Lund wrote:


Mark Powell wrote:

We use the development environment you are proposing and it works extremely well.

Sounds good.


Do you use the assembler at all? How well does it work?

Yes, but only for simple very low-level stuff.



The thing is, I actually tried to set up a gcc cross compiler once before, but it didn't quite work out right, and one of the problems was that the assembler (gas) had somewhat limited functionality. I think I followed the wrong track back then, though, as I tried to create a setup that would read and write OS-9 format objects and libs, so that I might use the existing clib etc., and also support some legacy OS-9 software. Because of that, I started off with a distribution with partial OS-9 support that was based on a fairly old (2.6 or so) gcc version. The fact that the gcc was so old may have contributed to the problems, and I think now that building new libs and updating the loader for a new exec format is probably easier than tweaking gcc to work with the old environment (and I don't really care about the OS-9 apps; they are more or less obsolete anyway.)


I built a cross tool-chain that supports the m68k family and ColdFire (I built it on Intel/Linux, Sparc/Solaris and HPUX hosts) and used that to compile newlib (http://sources.redhat.com/newlib/). Newlib has separate C and math libs.


So newlib, not glibc or similar, is the thing to use for embedded systems?

Yes, newlib has a much smaller footprint. There are other alternatives (uClibc for example) but I have found newlib perfectly adequate and simple enough to be mangeable.



I wrote some low-level routines (in C) that newlib calls to do serial port i/o to the UART


Would that be routines to read or write one character? I have those allready...

Actually I implemented it like a driver and provided open(), read(), write() and close() to call serio_open() etc in my UART code. Newlib has a library called libgloss which has these implemented for a few platforms. I used those as a starting point.



and voila we had printf, getchar, scanf etc on a TTY console.


How about "cstart"?

Is that the application start up code that calls main()? If so I adapted one from libgloss.



I then extended the serial i/o driver to use interupts and buffer characters and this provides a sort of background i/o capability for diagnostic menus on the TTY console.

The only thing is, it's not packaged up with an idiots guide that requires no previous knowledge. You should expect to understand the workings of the toolset and how to generate ROMs etc.


I am at least quite familiar with gcc, and I know how to load the code onto the current hardware (although I may have to research the new output format a bit.)

You can configure the tools to produce COFF or ELF. I use COFF with m68k toolset, mainly for historical reasons; but have switched to ELF for a new generation of h/w using PPC. Neither are particularly hard to deal with.



- Toralf


--
Mark Powell, Senior Software Engineer, Primagraphics Limited
New Cambridge House, Litlington, nr.Royston, Herts, SG8 0SS, UK
Tel. +44 1763 852222, Fax. 853324, http://www.primagraphics.co.uk



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]