[Efi332] Building newlib/libgloss for MPC555

Gunter Magin gm
Sun Jul 24 18:27:25 UTC 2005


Hi,

just a few notes:

On Sun, Jul 24, 2005 at 09:30:10AM -0700, David Eicher wrote:
> Okay, I'm starting to get oriented here a bit. I'm trying to figure out what
> configure does, and what to use for host and target (what configure does
> with these arguments). 
> 
> My host is WindowsXP (win32?), but config.sub doesn't recognize that as a
> valid alias for anything, not sure if configure will accept that.

Irrelevant. Let configure find out what your host system is, by NOT
specifying the host system. In 99.9% configure's guess is correct.

> My target is MPC555, but in this context is that just powerpc? Not sure what
> configure does with the target info I give it. Maybe it uses that to select
> the appropriate libgloss?

<path_to_newlib_top_level_source_directory>/configure --target=powerpc-eabi 

newlib configure system usually builds a libgloss library for each
supported system. Just looked at an old 68k installation. There is a
libmvme162, libidp, libdbug, libbcc libgloss available, all variants
of the libgloss for a certain architecture. This would be the "golden"
way to configure your system: add a libgloss for your particular target
system, and adjust the configure.in files in that tree. It is a little
guess work, but doable.

> I'm trying to understand which libgloss to use, don't know if it is more
> appropriate to use m68k or rs6000. What actually is rs6000, when I do a
> google search on it I just get IBM RS6000 server (a complete computer, not a
> processor chip).

The POWER architecture (POWER = Performance Optimization With Enhanced
Risc) was invented and defined 20 years ago by a industry cooperation
consisting of Apple, IBM and Motorola (AIM-consortium). IBM was the
first who came out with a workstation series called RS6000 with a
multi-chip processor chipset. Soon after that, GNU got ported to that
architecture. This is the reason why we have a rs6000 subdirectory with
PowerPC usable code. At that time Apple made the transition from the 68k
MAC to the Power MAC. And Motorola used the freedom of the architecture
specification and defined the PowerPC architecture, tailored towards deep
embedded usage, by simplifying the architecture.  On of the first Motorola
chips was the MPC60x. This is the Grandfather of the MPC555's core.

As newlib uses assembler parts, you cannot use a libc made for 68k
architecture when compiling for a non-68k architecture. Furthermore, if
you configure newlib for 68k, you end up with a library which contains
(binary) code for that architecture. You cannot run 68k binary code on
a PPC core.

What I meant in a previous post regarding glancing at the 68k subtree
was to lift source code from that part of the tree (for example an SCI
driver for the 68332) into the rs6000 subtree of libgloss. You then
have to compile that lifted code with a powerpc-eabi compiler to get
something usable. The configure system for newlib enforces that. Don't
work against the configure system.

So use "--target=powerpc-eabi" as the target architecture and don't
worry about the host/build architecture. You might get tempted to use
powerpc-linux, or other powerpc target specs, but that requires an
underlying operating system, which you don't have.

BTW: Seems you have a cross compiler. Make sure you configure newlib
with the same target spec as the other cross tools, and install them
at the same prefix (normally /usr/local, unless you have specified
--prefix=...) You might fall into subtile troubles during compilation if
you don't adhere to this. Rather reconfigure and recompile binutils, gcc
with powerpc-eabi...

Bottom line: powerpc-eabi for the naked HW, and write your device drivers
bottom up. 

> Little by little I'm unraveling the mystery here, building this library will
> probably take 5 minutes, when I have all the info I need. 

5 minutes, if you have a fast host machine, and have limited the multilib
scope. In the past I have compiled newlibs for more that 4 hours only
to find I have run out of disk space...

gm




More information about the Efi332 mailing list