Using newlib (was: [Efi332] Building newlib/libgloss for MPC555)

Tue Aug 9 12:59:52 UTC 2005

Hi Gunter,

It's hard to tell what happened when I run the code because I don't trust
this debugger. I did set a software breakpoint at mbx-outbyte, it never got
there. The debugger says the machine is still running (not in BDM debug
mode), but nothing is happening. So I click on "halt" and check the PC reg
and find I'm at 0x1000 with an illegal opcode. The exception vectors go
0x100 through 0xE00, I don't find one for 0x1000 so I'm not sure why it goes
there.

Good Idea, I'll use an LED on command to check and see if I get to
mbx-outbyte rather than the breakpoint (replace opcode with 0x0000000). I
don't trust this OCDCommander.

Yes, I modified the mbx routines. Bad idea? I couldn't tell what outbyte
file was associated with yk (oh....., is that Yellowknife?) I do see a
linker script for yk (Yellowknife.ld) but no outbyte/inbyte/etc. I have (in
rs6000) only the mbx/sim/mvme versions of inbyte/outbyte. Actually sim has
only inbyte, no outbyte. So it appeared to me my option was to use either
mbx or mvme.

It sounds like you're saying I should make a complete new one (called
555pcc, for example), correct? I figured that would be more complicated, I'd
have to modify makefiles to do that. If it's necessary though, I'm willing.

Let me make sure I understand, you recommend a code walk-through of printf(
)? Okay, made a quick walk through.., printf calls vfprintf, it appears.
Vfprintf calls print, and print calls outbyte.

I'll try the objdump to get listings and put some debug code in there and
see what I can learn tonight.

Thanks much for your help!

Dave

-----Original Message-----
From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of Gunter Magin
Sent: Monday, August 08, 2005 11:27 PM
To: efi332 at diy-efi.org
Subject: Re: Using newlib (was: [Efi332] Building newlib/libgloss for
MPC555)

Hi David

On Mon, Aug 08, 2005 at 07:54:45PM -0700, David Eicher wrote:
> Well, I tried executing my freshly built target code that has newlib and
> libgloss in it. The code ran perfect until it hit the first call into
newlib
> (libc), the call was to printf( ). 

What exactly happened? Hangup? Crash with Reboot? It could very well
be that the linking system is perfectly ok, but there is a bug in the
serial driver, e.g. you are hanging in a busy loop checking for a change
in a status bit which never happens. For example because the volatile
keyword has been missing on the status register...

So did printf reach your outbyte function? You can use a "LED debugger"
to make sure this happens (that is, set a GPIO when you enter outbyte(),
and put it off again on leaving). If the LED doesn't go on, and you are
unsure if it's the LED control calls or not reaching outbyte(), use the
LED debugger in main. Have some measurement equipment handy (e.g. scope,
logic probe, even a $40000 logic analyzer will do it... :-) ) to monitor
the LED output, because you can expect pretty short pulses for such a
fast processor... 

> Below is a output from linking my target
> with -v option on linker. Not sure if that will tell anyone anything
useful,
> it doesn't help me with my limited experience.

We need the contents of the map file...

> I'm a bit confused about what tells make to use the rs6000 version of
> libgloss? Not sure how that is being picked up. When I go through my
> main.map file I do indeed find encouraging stuff there, my modified
> mbx-outbyte.o and mbx-inbyte.o are there, so I can't be too far off. 

Ok, that's the relevant info. 

> Gunter, I'm trying to understand what to change if I go back and configure
> again. I haven't modified any makefiles for newlib or libgloss. 

> /usr/local/zfi555FBMonitor/bin/pcmaster.o
> /usr/local/zfi555FBMonitor/bin/main.o -o main.elf -mcpu=555 -Wl -Tdebug
> .dld -Wl,-Map=main.map -nostartfiles -lc -lm -lmbx -v
                                               ^^^^^
What's this? Have you cheated and modified the stock mbx libgloss to support
your home brewed HW? What about the yklib.a? Scrapped? 

> I tried changing the linker switch from -melf32ppc to -mcpu=555, linking
> went fine, but no change in printf behavior.

So did it pick another outbyte.o? Check the map file if there are
differences. Emphasize on the path from which libmbx.a is picked.

> I don't have a source level debugger running yet. I suppose it is time. I
> can't troubleshoot printf using the OCDComander from Macraigor, it is
> assembly code level, and I don't have list files for the libraries (like
> mbx-outbyte.lis). And, I don't know how to create them.

powerpc-elf-objdump -d xxx.o >xxx.dis

or 

powerpc-elf-objdump -D xxx.o >xxx.dis

might deliver a substitute. (check the manual for xxx-yyy-objdump) At
least you get a connection between C-function and assembler. Use the
map file to find out which function is linked to which address, or,
vice-versa, which function is sitting at a particular target memory
address. But debugging C code on assembler level is VERY tedious and
probably a waste of time, if you are doing it for the first time.

> I suppose I need to start the project of getting gdb/insight to work,
> probably will need it later anyway.

I'd rather use the "sharp-eyed-protein-debugger", (which by the way
is free to use, and already available, though might have some not yet
implemented debugging features) by carefully sifting through your device
driver. Make a kind of a simulated dry run-thru, and check for conditions,
branches... Some people call this a code walk-thru.

If you sidetrack now to set up the debugger, you might forget half
the wisdom how you came to that particular dev env state, before it
is stable...

gm
_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332