[Efi332] Building newlib/libgloss for MPC555

[Gunter Magin]

Hi,

On Sun, Jul 24, 2005 at 07:54:00PM -0700, David Eicher wrote:
> >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...
> 
> My GNU tools (Macraigor) are at usr/local/bin (gcc, as, ld). I want to make
> sure I correctly interpret your comments. My newlib-1.13.0 under
> usr/local/powerpc-elf/newlib-1.13.0 because of the way I interpreted the
> instructions in their readme file. 

Your newlib SOURCE tree can be anywhere. I find it a little strange
(though not false) to put it where normally executables and libraries
live. Maybe a misunderstanding on your part. Anyway, it is only important
where you install the libraries, so the linker can find it in the end.
And this has to do with which --prefix= binutils have been compiled. 

It seems Macraiger used --target=powerpc-elf for configuring,
and you should adhere to that for configuring newlib, instead
of powerpc-eabi. This is the reason why configure didn't find the
cross compiler. Also make sure the Macraigor cross tools are in your
search-$PATH for executables.

> So, would you say that is the correct
> prefix then? Another concern I have then, I'm not sure what the target spec
> is for my cross tools, I just took what Macraigor had on their website. One
> of my linker flags is -melf32ppc, which I believe I saw in a Macraigor demo
> makefile. I'm not sure it this is a useful hint of what the target spec
> might be or not.

Don't worry for that at the moment. However, once you have newlib and
start building actual target code, this might become an issue. But less
an issue, if you build on the naked HW. I use a "-mcpu=505 -msoft-float"
in my MPC5xx projects, but you might try "-mcpu=555 -msoft-float" as
well.

> >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.
> 
> I see..., okay. I've got tested routines for SCI, routines built on the
> eabi. So.., it looks like I can just go into the inbyte and outbyte routines
> and replace with code with mine. No..., at least one of the inbyte.c files
> under libgloss has a read( ) call in it. So there must be a read and write I
> need to modify. Well, I'll just try running the configure. Maybe during the
> build somewhere the linker will tell me what it needs (like you suggested
> earlier).

Have look at the mbx target in libgloss/rs6000: this is a MPC860/MPC823
evaluation board with a monitor. If you lift the mbx-files and substitute
the inbyte/outbyte functions with your SCI driver functions, I guess
this would be the easiest path. Just have a look for "mbx" and
duplicate/modify/adjust.

> So..., it looks like I have to find the right place in the directory
> structure. Problems include:
> 
> 1) Configure decided I don't have a cross compiler, but I do.

Give powerpc-eabi -> powerpc-elf a try. Not sure if configure treats it
the same anyway....

> 2) Configure found the tools to build GNU on the host (i686), not the tools
> to build a powerpc program..., hmmm.

Probably the same cuase.

> 3) make assumed the compiler is powerpc-eabi-gcc, but mine is
> powerpc-elf-gcc, could this be a result of using target=powerpc-eabi?

Exactly.

> Man oh man, this thing is complicated! A 256k makefile! I'm a beginner at
> makefile language, this could take a while.....

Don't waste your time understanding that Makefile in full extent. I
don't either and still have a working cross tool chain...

> Dave at Dell8400 /usr/local/powerpc-elf/newlib-ppc-aout
                                       ^^^^^^^^^^^^^^^
Any reason for choosing that particular name for the wrk subdirectory?
I guess these are historical reasons, and only the chosen name reflects
an obsolete wish to generate an ppc-aout cross tool chain....

> $ ../newlib-1.13.0/configure --target=powerpc-eabi
> creating cache ./config.cache
> checking host system type... i686-pc-cygwin
                               ^^^^^^^^^^^^^^
Configure isn't that bad in guessing the host system, is it??

> checking target system type... powerpc-unknown-eabi
                                 ^^^^^^^^^^^^^^^^^^^^
Configure's expansion of your given shortcut "powerpc-eabi"

> checking build system type... i686-pc-cygwin
....
> checking for powerpc-eabi-ar... no

So configure looks for $(TARGET)-ar and doesn't find it. That's ok,
because you have powerpc-elf-ar and friends instead. Adjust --target,
and you will be in the position to compile newlib. Only then start to
modify libgloss with your SCI driver.

And another hint: Once you have installed a libgloss for your system,
test it by calling inbyte/outbyte directly from the application. Avoid
the detour over printf(), read()/write() until you are sure that
inbyte()/outbyte() does what you want. You should also pull the relevant
source files for inbyte()/outbyte() into your working directory, and
let the linker not pull it from /usr/local/powerpc-elf/lib/libxxx.a,
so you can debug them. 

This makes sense even before you fire up the big newlib make: when you
let the linker pull in functions from a library, you might have a hard
time to explain the debugger where the source code for that library
function is. This is especially troublesome for libgloss functions, as
there is a set of source files all implementing the same function, just
for a different target board.  Usually a debugger picks the first one...

gm