From sailors3 at comcast.net Sun Aug 7 11:11:34 2005 From: sailors3 at comcast.net (David Eicher) Date: Sun, 7 Aug 2005 09:11:34 -0700 Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) In-Reply-To: <20050724182725.GA2207@mailhub.intra> Message-ID: I'm trying to build my target code using newlib now. I'm getting a linker error. I'm wondering a few things: 1) After install of libgloss, should there be a libgloss.a in the libs directory for building target code? 2) Do I need a -lgloss switch for my linker to link using libgloss, or does it get picked up automatically? Thanks, Dave There errors I'm getting look like this: Dave at Dell8400 /usr/local/zfi555FBMonitor $ make powerpc-elf-gcc -L/usr/local/powerpc-elf/lib /usr/local/zfi555FBMonitor/bin/LED.o /usr/local/zfi555FBMonitor/bin/BIT.o /usr/local/zfi555FBMonitor/bin/sci_io.o /usr/local/zfi555FBMonitor/bin/__me m.o /usr/local/zfi555FBMonitor/bin/__ppc_eabi_init.o /usr/local/zfi555FBMonitor/bin/5xx_board_init.o /usr/local/zfi555FBMonitor/bin/startup.o /usr/local/zfi555FBMonitor/bin/bbc.o /usr/local/zfi5 55FBMonitor/bin/dptram.o /usr/local/zfi555FBMonitor/bin/l2u.o /usr/local/zfi555FBMonitor/bin/mios1.o /usr/local/zfi555FBMonitor/bin/qadc.o /usr/local/zfi555FBMonitor/bin/qsmcm.o /usr/local/zfi55 5FBMonitor/bin/tcan.o /usr/local/zfi555FBMonitor/bin/tpu3.o /usr/local/zfi555FBMonitor/bin/uimb.o /usr/local/zfi555FBMonitor/bin/usiuclk.o /usr/local/zfi555FBMonitor/bin/usiugpio.o /usr/local/zf i555FBMonitor/bin/usiumem.o /usr/local/zfi555FBMonitor/bin/usiusys.o /usr/local/zfi555FBMonitor/bin/usiutmr.o /usr/local/zfi555FBMonitor/bin/exctable.o /usr/local/zfi555FBMonitor/bin/excfuncs.o /usr/local/zfi555FBMonitor/bin/appconfig.o /usr/local/zfi555FBMonitor/bin/arch.o /usr/local/zfi555FBMonitor/bin/pcmaster.o /usr/local/zfi555FBMonitor/bin/main.o -o .x -melf32ppc -Wl -Tdebug.dld -Wl,-Map=main.map -nostartfiles -lc -lm /usr/local/powerpc-elf/lib/libc.a(makebuf.o)(.text+0x130): In function `__smakebuf': ../../../../../newlib-1.13.0/newlib/libc/stdio/makebuf.c:96: undefined reference to `isatty' /usr/local/powerpc-elf/lib/libc.a(sbrkr.o)(.text+0x40): In function `_sbrk_r': ../../../../../newlib-1.13.0/newlib/libc/reent/sbrkr.c:60: undefined reference to `sbrk' /usr/local/powerpc-elf/lib/libc.a(writer.o)(.text+0x48): In function `_write_r': ../../../../../newlib-1.13.0/newlib/libc/reent/writer.c:58: undefined reference to `write' /usr/local/powerpc-elf/lib/libc.a(closer.o)(.text+0x40): In function `_close_r': ../../../../../newlib-1.13.0/newlib/libc/reent/closer.c:53: undefined reference to `close' /usr/local/powerpc-elf/lib/libc.a(fstatr.o)(.text+0x44): In function `_fstat_r': ../../../../../newlib-1.13.0/newlib/libc/reent/fstatr.c:62: undefined reference to `fstat' /usr/local/powerpc-elf/lib/libc.a(lseekr.o)(.text+0x48): In function `_lseek_r': ../../../../../newlib-1.13.0/newlib/libc/reent/lseekr.c:58: undefined reference to `lseek' /usr/local/powerpc-elf/lib/libc.a(readr.o)(.text+0x48): In function `_read_r': ../../../../../newlib-1.13.0/newlib/libc/reent/readr.c:58: undefined reference to `read' collect2: ld returned 1 exit status make: *** [main.elf] Error 1 Dave at Dell8400 /usr/local/zfi555FBMonitor From sailors3 at comcast.net Sun Aug 7 22:16:00 2005 From: sailors3 at comcast.net (David Eicher) Date: Sun, 7 Aug 2005 20:16:00 -0700 Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) Message-ID: Well, I think I've partially answered my own questions. 1) Apparently there is no libgloss.a, rather five libs: Libmbx.a Libyk.a Libmvme.a Libnosys.a Libsim.a It appears the Make install I did in the libgloss directory put these libs in my usr/local/powerpc-elf/lib directory, neat! When I tried to build my target code I got unresolved references. So I added a -lyk to my command to link and all the unresolved references disappeared except for one: __errno I found an example of an errno routine in rs6000, so added the code to one of the routines I modified for libgloss. But now I try to "make" libgloss again....., it says "no make file found", and "nothing to do". It appears that after I built it the first time, it renamed the makefile to makefile.in and now will no longer build. Can anyone suggest what is the correct way to make a change to libgloss? Can anyone explain the differences between the five libs and suggest which one I'm suppose to be using? Thanks for any help you might be able to offer, Dave -----Original Message----- From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of David Eicher Sent: Sunday, August 07, 2005 8:12 AM To: efi332 at diy-efi.org Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) I'm trying to build my target code using newlib now. I'm getting a linker error. I'm wondering a few things: 1) After install of libgloss, should there be a libgloss.a in the libs directory for building target code? 2) Do I need a -lgloss switch for my linker to link using libgloss, or does it get picked up automatically? Thanks, Dave There errors I'm getting look like this: Dave at Dell8400 /usr/local/zfi555FBMonitor $ make powerpc-elf-gcc -L/usr/local/powerpc-elf/lib /usr/local/zfi555FBMonitor/bin/LED.o /usr/local/zfi555FBMonitor/bin/BIT.o /usr/local/zfi555FBMonitor/bin/sci_io.o /usr/local/zfi555FBMonitor/bin/__me m.o /usr/local/zfi555FBMonitor/bin/__ppc_eabi_init.o /usr/local/zfi555FBMonitor/bin/5xx_board_init.o /usr/local/zfi555FBMonitor/bin/startup.o /usr/local/zfi555FBMonitor/bin/bbc.o /usr/local/zfi5 55FBMonitor/bin/dptram.o /usr/local/zfi555FBMonitor/bin/l2u.o /usr/local/zfi555FBMonitor/bin/mios1.o /usr/local/zfi555FBMonitor/bin/qadc.o /usr/local/zfi555FBMonitor/bin/qsmcm.o /usr/local/zfi55 5FBMonitor/bin/tcan.o /usr/local/zfi555FBMonitor/bin/tpu3.o /usr/local/zfi555FBMonitor/bin/uimb.o /usr/local/zfi555FBMonitor/bin/usiuclk.o /usr/local/zfi555FBMonitor/bin/usiugpio.o /usr/local/zf i555FBMonitor/bin/usiumem.o /usr/local/zfi555FBMonitor/bin/usiusys.o /usr/local/zfi555FBMonitor/bin/usiutmr.o /usr/local/zfi555FBMonitor/bin/exctable.o /usr/local/zfi555FBMonitor/bin/excfuncs.o /usr/local/zfi555FBMonitor/bin/appconfig.o /usr/local/zfi555FBMonitor/bin/arch.o /usr/local/zfi555FBMonitor/bin/pcmaster.o /usr/local/zfi555FBMonitor/bin/main.o -o .x -melf32ppc -Wl -Tdebug.dld -Wl,-Map=main.map -nostartfiles -lc -lm /usr/local/powerpc-elf/lib/libc.a(makebuf.o)(.text+0x130): In function `__smakebuf': ../../../../../newlib-1.13.0/newlib/libc/stdio/makebuf.c:96: undefined reference to `isatty' /usr/local/powerpc-elf/lib/libc.a(sbrkr.o)(.text+0x40): In function `_sbrk_r': ../../../../../newlib-1.13.0/newlib/libc/reent/sbrkr.c:60: undefined reference to `sbrk' /usr/local/powerpc-elf/lib/libc.a(writer.o)(.text+0x48): In function `_write_r': ../../../../../newlib-1.13.0/newlib/libc/reent/writer.c:58: undefined reference to `write' /usr/local/powerpc-elf/lib/libc.a(closer.o)(.text+0x40): In function `_close_r': ../../../../../newlib-1.13.0/newlib/libc/reent/closer.c:53: undefined reference to `close' /usr/local/powerpc-elf/lib/libc.a(fstatr.o)(.text+0x44): In function `_fstat_r': ../../../../../newlib-1.13.0/newlib/libc/reent/fstatr.c:62: undefined reference to `fstat' /usr/local/powerpc-elf/lib/libc.a(lseekr.o)(.text+0x48): In function `_lseek_r': ../../../../../newlib-1.13.0/newlib/libc/reent/lseekr.c:58: undefined reference to `lseek' /usr/local/powerpc-elf/lib/libc.a(readr.o)(.text+0x48): In function `_read_r': ../../../../../newlib-1.13.0/newlib/libc/reent/readr.c:58: undefined reference to `read' collect2: ld returned 1 exit status make: *** [main.elf] Error 1 Dave at Dell8400 /usr/local/zfi555FBMonitor _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 From gm at ib-magin.de Mon Aug 8 04:34:46 2005 From: gm at ib-magin.de (Gunter Magin) Date: Mon, 8 Aug 2005 11:34:46 +0200 Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) In-Reply-To: <200508080321.j783LjeH021987@shirkhan.intra> References: <200508080321.j783LjeH021987@shirkhan.intra> Message-ID: <20050808093446.GA27761@mailhub.intra> Hello On Sun, Aug 07, 2005 at 08:16:00PM -0700, David Eicher wrote: > 1) Apparently there is no libgloss.a, rather five libs: > > Libmbx.a > Libyk.a > Libmvme.a > Libnosys.a > Libsim.a libgloss is a library especially crafted for a particular target board, like the MBX family (libmbx.a) or the MVME family of VME boards (libmvme.a). The common part of libgloss (read(), write()) is generic, and is duplicated in each lib. They rely on the outbyte()/inbyte() functions, which are special parts to glue between the generic libgloss functions and the available board ressources (monitor functions, HW ressources, whatever). These special parts are different for each particular libgloss library. > It appears the Make install I did in the libgloss directory put these libs > in my usr/local/powerpc-elf/lib directory, neat! "make" actually built all variants, and "make install" put it into the lib path. make also created all multilib variants (nof, le, and friends) of the library, and installed it in the relevant subdirectory of the library install tree. > When I tried to build my target code I got unresolved references. So I added > a -lyk to my command to link and all the unresolved references disappeared Is libyk.a the libgloss for your particular target board? > except for one: > > __errno > > I found an example of an errno routine in rs6000, so added the code to one > of the routines I modified for libgloss. But now I try to "make" libgloss > again....., it says "no make file found", and "nothing to do". It appears > that after I built it the first time, it renamed the makefile to makefile.in > and now will no longer build. Hmmm. makefile.in is the input for the autoconf tool, which is called with the configure call. If you haven't deleted the Makefile, chances are, you are not in the right directory. Make sure you call make somehwere in your build tree, not in your source tree. For building libgloss, go to /powerpc-elf/libgloss and check for your makefile. Hint: If you have modified Makefile to add new files for building a (new) libgloss for your particular target, in the addition to the stock versions of libgloss, you better do these mods in the corresponding makefile.in in the source tree, because the Makefile is considered as a derived file, and subject to being clobbered by the build system. That effectively destroys your modifications, and they are lost without traces... > Can anyone suggest what is the correct way to make a change to libgloss? check the makefile.in and the sources in the __source__ tree for a particular available target, like the mbx board, duplicate these files, if they are not common, and modify the makefile.in to make use of the changes. (I think you did this step already if I am right with the assumption with libyk) The next step is to rerun configure. The most safe option (recommended) is to run configure from the newlib build top directory. You may try to run configure in some subdirectory of the newlib build tree, but you have to supply a myriad of options. Check the config.status files in every directory. Then either rebuild all newlib (safe, but dumb), or go into the libgloss subdir, and rebuild only libgloss (smart, and more time effective, though a little trickier, as you might miss something - just check if the relevant .o files got rebuilt). And finally do a make install in the libgloss dir. If you have any doubt or there are errors in the linking phase of your app build process, play safe and do the whole build/install process. But I guess you got it right, it's just that you fetch the wrong libs for app build. > Can anyone explain the differences between the five libs and suggest which > one I'm suppose to be using? Actually, I fear you should modify makefile.in in a way to create a 6th library especially for your HW. Give gcc a -l for linking, like it would be -lmbx if you wanted the mbx variant of libgloss. > There errors I'm getting look like this: > > Dave at Dell8400 /usr/local/zfi555FBMonitor > $ make > powerpc-elf-gcc -L/usr/local/powerpc-elf/lib ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ You shouldn't need to explicitly state the lib path, if your installation is sound. If the linker doesn't find the libs, something is wrong with your installation. Use gcc's -v option to see what parameters the gcc frontend gives to the ld call, and check the map file generated by the linker. > /usr/local/zfi555FBMonitor/bin/pcmaster.o > /usr/local/zfi555FBMonitor/bin/main.o -o .x ^^^ A funny (unusual) target file name.... > -melf32ppc -Wl -Tdebug.dld ^^^^^^^^^^ Are you sure what this option means? I'd suggest to try -mcpu=555 or -mcpu=505. > -Wl,-Map=main.map ^^^^^^^^^^^^^ This is the map file I have been talking about above. > -nostartfiles -lc -lm ^^^^^^^^^^^^^ Good. You supply your own startup code, and it is included in the list of files to be linked... The rest are errors to be expected if a library is missing.... > /usr/local/powerpc-elf/lib/libc.a(makebuf.o)(.text+0x130): In function > `__smakebuf': ... > `_read_r': > ../../../../../newlib-1.13.0/newlib/libc/reent/readr.c:58: undefined > reference to `read' > collect2: ld returned 1 exit status > make: *** [main.elf] Error 1 From sailors3 at comcast.net Mon Aug 8 07:46:17 2005 From: sailors3 at comcast.net (David Eicher) Date: Mon, 8 Aug 2005 05:46:17 -0700 Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) In-Reply-To: <20050808093446.GA27761@mailhub.intra> Message-ID: Man, I'm making stupid mistakes, thanks much Gunter. I was trying to make from the source directory rather than the build tree. Stupid. I don't know why that isn't intuitive to me.., gotta work on that. I ran make from the build tree, it built fine, then I ran install, it went fine, then I built my target code, no errors! Thanks again for your kind response, I'll investigate the other points you make later this week. It makes sense what you suggest about the install being incorrect. My target link gave me link errors for all the library calls the first time I tried without the -L so something is messed up. Also, I'm asking what lib to use....., when it was the mbx-inbyte routine I modified for my target...., stupid, sorry to waste your time with that. Of course, in my defense, it was a month ago that I modified it, and I can't remember things from last week. Best regards, 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 1:35 AM To: efi332 at diy-efi.org Subject: Re: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) Hello On Sun, Aug 07, 2005 at 08:16:00PM -0700, David Eicher wrote: > 1) Apparently there is no libgloss.a, rather five libs: > > Libmbx.a > Libyk.a > Libmvme.a > Libnosys.a > Libsim.a libgloss is a library especially crafted for a particular target board, like the MBX family (libmbx.a) or the MVME family of VME boards (libmvme.a). The common part of libgloss (read(), write()) is generic, and is duplicated in each lib. They rely on the outbyte()/inbyte() functions, which are special parts to glue between the generic libgloss functions and the available board ressources (monitor functions, HW ressources, whatever). These special parts are different for each particular libgloss library. > It appears the Make install I did in the libgloss directory put these libs > in my usr/local/powerpc-elf/lib directory, neat! "make" actually built all variants, and "make install" put it into the lib path. make also created all multilib variants (nof, le, and friends) of the library, and installed it in the relevant subdirectory of the library install tree. > When I tried to build my target code I got unresolved references. So I added > a -lyk to my command to link and all the unresolved references disappeared Is libyk.a the libgloss for your particular target board? > except for one: > > __errno > > I found an example of an errno routine in rs6000, so added the code to one > of the routines I modified for libgloss. But now I try to "make" libgloss > again....., it says "no make file found", and "nothing to do". It appears > that after I built it the first time, it renamed the makefile to makefile.in > and now will no longer build. Hmmm. makefile.in is the input for the autoconf tool, which is called with the configure call. If you haven't deleted the Makefile, chances are, you are not in the right directory. Make sure you call make somehwere in your build tree, not in your source tree. For building libgloss, go to /powerpc-elf/libgloss and check for your makefile. Hint: If you have modified Makefile to add new files for building a (new) libgloss for your particular target, in the addition to the stock versions of libgloss, you better do these mods in the corresponding makefile.in in the source tree, because the Makefile is considered as a derived file, and subject to being clobbered by the build system. That effectively destroys your modifications, and they are lost without traces... > Can anyone suggest what is the correct way to make a change to libgloss? check the makefile.in and the sources in the __source__ tree for a particular available target, like the mbx board, duplicate these files, if they are not common, and modify the makefile.in to make use of the changes. (I think you did this step already if I am right with the assumption with libyk) The next step is to rerun configure. The most safe option (recommended) is to run configure from the newlib build top directory. You may try to run configure in some subdirectory of the newlib build tree, but you have to supply a myriad of options. Check the config.status files in every directory. Then either rebuild all newlib (safe, but dumb), or go into the libgloss subdir, and rebuild only libgloss (smart, and more time effective, though a little trickier, as you might miss something - just check if the relevant .o files got rebuilt). And finally do a make install in the libgloss dir. If you have any doubt or there are errors in the linking phase of your app build process, play safe and do the whole build/install process. But I guess you got it right, it's just that you fetch the wrong libs for app build. > Can anyone explain the differences between the five libs and suggest which > one I'm suppose to be using? Actually, I fear you should modify makefile.in in a way to create a 6th library especially for your HW. Give gcc a -l for linking, like it would be -lmbx if you wanted the mbx variant of libgloss. > There errors I'm getting look like this: > > Dave at Dell8400 /usr/local/zfi555FBMonitor > $ make > powerpc-elf-gcc -L/usr/local/powerpc-elf/lib ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ You shouldn't need to explicitly state the lib path, if your installation is sound. If the linker doesn't find the libs, something is wrong with your installation. Use gcc's -v option to see what parameters the gcc frontend gives to the ld call, and check the map file generated by the linker. > /usr/local/zfi555FBMonitor/bin/pcmaster.o > /usr/local/zfi555FBMonitor/bin/main.o -o .x ^^^ A funny (unusual) target file name.... > -melf32ppc -Wl -Tdebug.dld ^^^^^^^^^^ Are you sure what this option means? I'd suggest to try -mcpu=555 or -mcpu=505. > -Wl,-Map=main.map ^^^^^^^^^^^^^ This is the map file I have been talking about above. > -nostartfiles -lc -lm ^^^^^^^^^^^^^ Good. You supply your own startup code, and it is included in the list of files to be linked... The rest are errors to be expected if a library is missing.... > /usr/local/powerpc-elf/lib/libc.a(makebuf.o)(.text+0x130): In function > `__smakebuf': ... > `_read_r': > ../../../../../newlib-1.13.0/newlib/libc/reent/readr.c:58: undefined > reference to `read' > collect2: ld returned 1 exit status > make: *** [main.elf] Error 1 _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 From sailors3 at comcast.net Mon Aug 8 21:54:45 2005 From: sailors3 at comcast.net (David Eicher) Date: Mon, 8 Aug 2005 19:54:45 -0700 Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) In-Reply-To: <20050808093446.GA27761@mailhub.intra> Message-ID: 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( ). 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. 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. 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. I tried changing the linker switch from -melf32ppc to -mcpu=555, linking went fine, but no change in printf behavior. 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. I suppose I need to start the project of getting gdb/insight to work, probably will need it later anyway. Any insight anyone can offer would be appreciated. Thanks much, Dave ---------------------------------------------- Dave at Dell8400 /usr/local/zfi555FBMonitor $ make powerpc-elf-gcc -L/usr/local/powerpc-elf/lib /usr/local/zfi555FBMonitor/bin/LED.o /usr/local/zfi555FBMonitor/bin/BIT.o /usr/local/zfi555FBMonitor/bin/sci_io.o /usr/local/zfi555FBMonitor/bin/__me m.o /usr/local/zfi555FBMonitor/bin/__ppc_eabi_init.o /usr/local/zfi555FBMonitor/bin/5xx_board_init.o /usr/local/zfi555FBMonitor/bin/startup.o /usr/local/zfi555FBMonitor/bin/bbc.o /usr/local/zfi5 55FBMonitor/bin/dptram.o /usr/local/zfi555FBMonitor/bin/l2u.o /usr/local/zfi555FBMonitor/bin/mios1.o /usr/local/zfi555FBMonitor/bin/qadc.o /usr/local/zfi555FBMonitor/bin/qsmcm.o /usr/local/zfi55 5FBMonitor/bin/tcan.o /usr/local/zfi555FBMonitor/bin/tpu3.o /usr/local/zfi555FBMonitor/bin/uimb.o /usr/local/zfi555FBMonitor/bin/usiuclk.o /usr/local/zfi555FBMonitor/bin/usiugpio.o /usr/local/zf i555FBMonitor/bin/usiumem.o /usr/local/zfi555FBMonitor/bin/usiusys.o /usr/local/zfi555FBMonitor/bin/usiutmr.o /usr/local/zfi555FBMonitor/bin/exctable.o /usr/local/zfi555FBMonitor/bin/excfuncs.o /usr/local/zfi555FBMonitor/bin/appconfig.o /usr/local/zfi555FBMonitor/bin/arch.o /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 Reading specs from /usr/local/lib/gcc/powerpc-elf/3.4.0-macraigor1/specs Configured with: /rel/share/gnu/src/gcc-3.4.0-macraigor1/configure --host=i686-pc-cygwin --target=powerpc-elf --disable-nls --with-stabs --disable-install-libiberty --disable-install-libbfd --di sable-dependency-tracking --enable-languages=c,c++ --with-gnu-as --with-gnu-ld Thread model: single gcc version 3.4.0-macraigor1 /usr/local/libexec/gcc/powerpc-elf/3.4.0-macraigor1/collect2.exe -V -Qy -dn -Bstatic -o main.elf -L/usr/local/powerpc-elf/lib -L/usr/local/lib/gcc/powerpc-elf/3.4.0-macraigor1 -L/usr/local/lib/ gcc/powerpc-elf/3.4.0-macraigor1/../../../../powerpc-elf/lib /usr/local/zfi555FBMonitor/bin/LED.o /usr/local/zfi555FBMonitor/bin/BIT.o /usr/local/zfi555FBMonitor/bin/sci_io.o /usr/local/zfi555FB Monitor/bin/__mem.o /usr/local/zfi555FBMonitor/bin/__ppc_eabi_init.o /usr/local/zfi555FBMonitor/bin/5xx_board_init.o /usr/local/zfi555FBMonitor/bin/startup.o /usr/local/zfi555FBMonitor/bin/bbc.o /usr/local/zfi555FBMonitor/bin/dptram.o /usr/local/zfi555FBMonitor/bin/l2u.o /usr/local/zfi555FBMonitor/bin/mios1.o /usr/local/zfi555FBMonitor/bin/qadc.o /usr/local/zfi555FBMonitor/bin/qsmcm.o /usr/local/zfi555FBMonitor/bin/tcan.o /usr/local/zfi555FBMonitor/bin/tpu3.o /usr/local/zfi555FBMonitor/bin/uimb.o /usr/local/zfi555FBMonitor/bin/usiuclk.o /usr/local/zfi555FBMonitor/bin/usiugpio .o /usr/local/zfi555FBMonitor/bin/usiumem.o /usr/local/zfi555FBMonitor/bin/usiusys.o /usr/local/zfi555FBMonitor/bin/usiutmr.o /usr/local/zfi555FBMonitor/bin/exctable.o /usr/local/zfi555FBMonitor /bin/excfuncs.o /usr/local/zfi555FBMonitor/bin/appconfig.o /usr/local/zfi555FBMonitor/bin/arch.o /usr/local/zfi555FBMonitor/bin/pcmaster.o /usr/local/zfi555FBMonitor/bin/main.o -Map=main.map -lc -lm -lmbx -lgcc -lgcc -Tdebug.dld GNU ld version 2.15 Supported emulations: elf32ppc elf32ppclinux elf32ppcsim Dave at Dell8400 /usr/local/zfi555FBMonitor $ From gm at ib-magin.de Tue Aug 9 02:27:21 2005 From: gm at ib-magin.de (Gunter Magin) Date: Tue, 9 Aug 2005 09:27:21 +0200 Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) In-Reply-To: <200508090300.j7930Bg6022514@shirkhan.intra> References: <20050808093446.GA27761@mailhub.intra> <200508090300.j7930Bg6022514@shirkhan.intra> Message-ID: <20050809072721.GA26678@mailhub.intra> 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 From sailors3 at comcast.net Tue Aug 9 07:59:52 2005 From: sailors3 at comcast.net (David Eicher) Date: Tue, 9 Aug 2005 05:59:52 -0700 Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) In-Reply-To: <20050809072721.GA26678@mailhub.intra> Message-ID: 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 From gm at ib-magin.de Tue Aug 9 08:35:32 2005 From: gm at ib-magin.de (Gunter Magin) Date: Tue, 9 Aug 2005 15:35:32 +0200 Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) In-Reply-To: <200508091303.j79D3NR9011579@shirkhan.intra> References: <20050809072721.GA26678@mailhub.intra> <200508091303.j79D3NR9011579@shirkhan.intra> Message-ID: <20050809133531.GA12711@mailhub.intra> Hi, > 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. Table 3-21 on the MPC555UM says 0x1000 is "Implementation dependent SW emulation", that is, an illegal opcode. Chances are the linker has picked the wrong library. Double check the map file. > Yes, I modified the mbx routines. Bad idea? For long term, yes, as it leads people (including yourself - been there, done that) on false tracks and assumptions. For a short-term hack, it is ok. Just take a chissel and carve on the rim of your CRT: "Don't forget to fix the mbx hack, once it's running...." :) > It sounds like you're saying I should make a complete new one (called > 555pcc, for example), correct? Yes. But not necessarily now. That's the clean way. > I figured that would be more complicated, I'd > have to modify makefiles to do that. If it's necessary though, I'm willing. Not the makefiles, but the the makefile.in. And it is only one or two files. No big deal. > 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. No, not printf. newlib is known to be reasonable bug free, and the remaining bugs will not bother you at this state. Start at the place where the processor comes out of the libc black box, that is the open() and write() function. write() calls outbyte(). Emphasize on all conditioinal branches, changes in variables, leftover states of variables, side effects, and don't let you bother what the programmer intended, but presume to be the stupid processor doing exactly what's written down. Build hypotheses about what might cause your observations, and if you don't have enough information, make additional tests. Once the LED debugger is working, I would experiment a little more with the LED debugger to get a better feeling what's happening. But it looks like you don't reach write() at all. This would be my very first test. > I'll try the objdump to get listings and put some debug code in there and > see what I can learn tonight. You can also disassemble the whole app elf file and find out if there are some strange opcodes in printf() code. But what looks strange? Only the processor knows... You can also give the debugger another try and analyze the stack once you reach the illegal opcode exception. I think setting a breakpoint at 0x1000 and analyzing the processor registers might give valuable information. That's at least worth a try. Then use the map file to locate the offending opcode, and the function. gm From bowtievette at aol.com Tue Aug 9 20:43:44 2005 From: bowtievette at aol.com (bowtievette at aol.com) Date: Tue, 09 Aug 2005 21:43:44 -0400 Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) In-Reply-To: <20050809133531.GA12711@mailhub.intra> References: <20050809072721.GA26678@mailhub.intra> <200508091303.j79D3NR9011579@shirkhan.intra> <20050809133531.GA12711@mailhub.intra> Message-ID: <8C76B6414095BC5-152C-1DCD@MBLK-M33.sysops.aol.com> -----Original Message----- From: Gunter Magin To: efi332 at diy-efi.org Sent: Tue, 9 Aug 2005 15:35:32 +0200 Subject: Re: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) Hi, > 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. Table 3-21 on the MPC555UM says 0x1000 is "Implementation dependent SW emulation", that is, an illegal opcode. Chances are the linker has picked the wrong library. Double check the map file. You have to be careful with that exception. It may be only the last exception that occurred. Dave, if you have not populated your exception table, or if the table is stale with respect to your application in RAM (I presume you are running from RAM), then almost any exception will find some illegal opcodes and trigger the software emulation exception (0x1000). To unravel the source, you must have your table populated so that you can determine when the various exceptions are called. Counters, setting discretes, etc are useful here. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050809/c2c442f1/attachment.html From sailors3 at comcast.net Tue Aug 9 22:05:21 2005 From: sailors3 at comcast.net (David Eicher) Date: Tue, 9 Aug 2005 20:05:21 -0700 Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) In-Reply-To: <8C76B6414095BC5-152C-1DCD@MBLK-M33.sysops.aol.com> Message-ID: Hi Jeff, Thanks for the thoughts! You?re correct, I?m running in RAM and there is no exception table loaded in Flash, so it is all 0xFFFFFFFFs. It looks like it went to 0x1000 and tried to execute the instruction there, the debugger printed ?illegal opcode ? 0xFFFFFFFF?. I decided to try single stepping through printf to see what it does. It executed the following routines: Printf Vfprintf Localeconv (libc ? locale.o) Vfprintf (returned to vfprintf from localeconv) Strlen Vfprintf Sfvwrite In sfvwrite the program lost it?s mind. One instruction before the crash the debugger displayed the instruction that would be executed next as BCCTRL r20, r0 0x4E800421 When I hit step again, CRASH! The debugger displayed: PC: FFFFFFFF CR: 5DFF3FF9 MSR: 00003402 LR: 00C0C118 XER: E000FC7F : UNKNOWN OPCODE The PC just before this crash was: 0x00C0C114 which contained the opcode 0x4E800421. I looked this instruction up in the UM and it appears to be okay to me, BO is set to ?always branch?, BI is set to ?LT? (less than ? the condition to branch on), the LK = 1 and the LR register was modified to 0x00C0C118 which seems like the right value (CIA + 4). So, what is up with this! I don?t know if my processor is broke or if this is a illegal form of the instruction, or what. I?m not sure where the code was headed next but was anxious to find out. It took about 1 ? hours of single stepping to get to that point. Any thoughts you might have on this would be appreciated. Thanks, Dave _____ From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of bowtievette at aol.com Sent: Tuesday, August 09, 2005 5:44 PM To: efi332 at diy-efi.org Subject: Re: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) -----Original Message----- From: Gunter Magin To: efi332 at diy-efi.org Sent: Tue, 9 Aug 2005 15:35:32 +0200 Subject: Re: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) Hi, > 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. Table 3-21 on the MPC555UM says 0x1000 is "Implementation dependent SW emulation", that is, an illegal opcode. Chances are the linker has picked the wrong library. Double check the map file. You have to be careful with that exception. It may be only the last exception that occurred. Dave, if you have not populated your exception table, or if the table is stale with respect to your application in RAM (I presume you are running from RAM), then almost any exception will find some illegal opcodes and trigger the software emulation exception (0x1000). To unravel the source, you must have your table populated so that you can determine when the various exceptions are called. Counters, setting discretes, etc are useful here. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050809/6d173f49/attachment.html From gm at ib-magin.de Wed Aug 10 03:49:58 2005 From: gm at ib-magin.de (Gunter Magin) Date: Wed, 10 Aug 2005 10:49:58 +0200 Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) In-Reply-To: <200508100309.j7A39hLK007526@shirkhan.intra> References: <8C76B6414095BC5-152C-1DCD@MBLK-M33.sysops.aol.com> <200508100309.j7A39hLK007526@shirkhan.intra> Message-ID: <20050810084958.GA12942@mailhub.intra> Hi, On Tue, Aug 09, 2005 at 08:05:21PM -0700, David Eicher wrote: > Thanks for the thoughts! You?re correct, I?m running in RAM and there is no > exception table loaded in Flash, so it is all 0xFFFFFFFFs. It looks like it > went to 0x1000 and tried to execute the instruction there, the debugger > printed ?illegal opcode ? 0xFFFFFFFF?. Under normal conditions, it's ok for the time being (yet another hack to be fixed later) there is no exception table, when there are no exceptions. However, there could be some cause for exceptions in the (buggy - due to insufficient development environment) code, and therefore you can get the type of crash Jeff described. In these cases it makes sense to at least implement some kind of attraction gathering, nonreturning stub as an exception handler, for example let the LED blink nervously. I presume your particular libgloss implementation for serial out does not use interrupts... > I decided to try single stepping through printf to see what it does. It > executed the following routines: > > > > Printf > > Vfprintf > > Localeconv (libc ? locale.o) > > Vfprintf (returned to vfprintf from localeconv) > > Strlen > > Vfprintf > > Sfvwrite > > > > In sfvwrite the program lost its mind. One instruction before the crash the > debugger displayed the instruction that would be executed next as > > BCCTRL r20, r0 0x4E800421 > > When I hit step again, CRASH! The debugger displayed: > > PC: FFFFFFFF CR: 5DFF3FF9 MSR: 00003402 > LR: 00C0C118 XER: E000FC7F > : UNKNOWN OPCODE > The PC just before this crash was: 0x00C0C114 which contained the opcode > 0x4E800421. The main question is, why did the CTR register contain 0xffffffff? This is the value that was pushed into the program counter by this lethal BCCTR instruction. Only the disassembled instructions before 0xc0c114 can tell... > So, what is up with this! I don?t know if my processor is broke In my experience this is almost never the case, once it got that far after reset... > or if this > is a illegal form of the instruction, or what. I?m not sure where the code > was headed next but was anxious to find out. svfwrite() in newlib-1.13/newlib/libc/stdtio/fvwrite.c is a myriad of if () clauses for some different conditions, and I guess the CTR register was used to implement jumps around some blocks... > It took about 1 ? hours of > single stepping to get to that point. You should give the breakpoint mechanism another try, now that you know where the crash happens. Breakpoints didn't work the other day for a valid reason: the code has never been reached. So no reason to believe the debugger doesn't work. gm From sailors3 at comcast.net Wed Aug 10 08:03:54 2005 From: sailors3 at comcast.net (David Eicher) Date: Wed, 10 Aug 2005 06:03:54 -0700 Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) In-Reply-To: <20050810084958.GA12942@mailhub.intra> Message-ID: Hi Gunter, This target code has an exception table in it, as soon as I get it working I plan to burn into flash and will then have the table set up for future debug, this is just the first awkward step.... Correct, no interrupts in libgloss. CTR got loaded with a 0xFFFFFFFF from register r9. r9 got loaded with that value from an instruction as follows: LWZ r9, 36(r27) OR r4, r26, r26 MTCTR r9 BCCTRL r20, r0 CRASH! It IS consistent, I used a breakpoint to get there quickly this time and it did the same thing again. Yep, I'm sure the processor is not broke, but I wonder if this instruction is properly formed, it appears to me it should execute the instruction after BCCTRL because the LK bit is set. BTW, r27 = 0xFFFFFFFF so that is why CTR gets a bad value. I'll look and see why r27 gets the bad value. Thanks a jillion for the help here, Dave -----Original Message----- From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of Gunter Magin Sent: Wednesday, August 10, 2005 12:50 AM To: efi332 at diy-efi.org Subject: Re: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) Hi, On Tue, Aug 09, 2005 at 08:05:21PM -0700, David Eicher wrote: > Thanks for the thoughts! You?re correct, I?m running in RAM and there is no > exception table loaded in Flash, so it is all 0xFFFFFFFFs. It looks like it > went to 0x1000 and tried to execute the instruction there, the debugger > printed ?illegal opcode ? 0xFFFFFFFF?. Under normal conditions, it's ok for the time being (yet another hack to be fixed later) there is no exception table, when there are no exceptions. However, there could be some cause for exceptions in the (buggy - due to insufficient development environment) code, and therefore you can get the type of crash Jeff described. In these cases it makes sense to at least implement some kind of attraction gathering, nonreturning stub as an exception handler, for example let the LED blink nervously. I presume your particular libgloss implementation for serial out does not use interrupts... The main question is, why did the CTR register contain 0xffffffff? This is the value that was pushed into the program counter by this lethal BCCTR instruction. Only the disassembled instructions before 0xc0c114 can tell... > So, what is up with this! I don?t know if my processor is broke In my experience this is almost never the case, once it got that far after reset... > or if this > is a illegal form of the instruction, or what. I?m not sure where the code > was headed next but was anxious to find out. svfwrite() in newlib-1.13/newlib/libc/stdtio/fvwrite.c is a myriad of if () clauses for some different conditions, and I guess the CTR register was used to implement jumps around some blocks... > It took about 1 ? hours of > single stepping to get to that point. You should give the breakpoint mechanism another try, now that you know where the crash happens. Breakpoints didn't work the other day for a valid reason: the code has never been reached. So no reason to believe the debugger doesn't work. gm _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 From sailors3 at comcast.net Mon Aug 15 22:13:59 2005 From: sailors3 at comcast.net (David Eicher) Date: Mon, 15 Aug 2005 20:13:59 -0700 Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) Message-ID: Making some progress. I've discovered that the __sfvwrite ( ) function accepts as input two parameters (fp and uio) as shown in this code snippet. _DEFUN(__sfvwrite, (fp, uio), register FILE *fp _AND register struct __suio *uio) It appears in the code that one of the parameters is passed to the function in register r3, which gets copied to r27. I put a breakpoint at the beginning of __sfvwrite (which is in file fvwrite.c) and discovered that r3 is 0xFFFFFFFF at the beginning of execution. So..., that is more background on why __sfvwrite is crashing. I have not been able to tell which parameter is passed in r3 yet (working on it). Does anyone have any idea which one of these parameters might be sensitive to my configuration and build of newlib? Like gm pointed out earlier, this is tested code so it must be something I've done wrong that is causing the problem. Thanks, Dave -----Original Message----- From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of David Eicher Sent: Wednesday, August 10, 2005 5:04 AM To: efi332 at diy-efi.org Subject: RE: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) Hello, This target code has an exception table in it, as soon as I get it working I plan to burn into flash and will then have the table set up for future debug, this is just the first awkward step.... Correct, no interrupts in libgloss. CTR got loaded with a 0xFFFFFFFF from register r9. r9 got loaded with that value from an instruction as follows: LWZ r9, 36(r27) OR r4, r26, r26 MTCTR r9 BCCTRL r20, r0 CRASH! It IS consistent, I used a breakpoint to get there quickly this time and it did the same thing again. Yep, I'm sure the processor is not broke, but I wonder if this instruction is properly formed, it appears to me it should execute the instruction after BCCTRL because the LK bit is set. BTW, r27 = 0xFFFFFFFF so that is why CTR gets a bad value. I'll look and see why r27 gets the bad value. Thanks a jillion for the help here, Dave -----Original Message----- From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of Gunter Magin Sent: Wednesday, August 10, 2005 12:50 AM To: efi332 at diy-efi.org Subject: Re: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) Hi, On Tue, Aug 09, 2005 at 08:05:21PM -0700, David Eicher wrote: > Thanks for the thoughts! You?re correct, I?m running in RAM and there is no > exception table loaded in Flash, so it is all 0xFFFFFFFFs. It looks like it > went to 0x1000 and tried to execute the instruction there, the debugger > printed ?illegal opcode ? 0xFFFFFFFF?. Under normal conditions, it's ok for the time being (yet another hack to be fixed later) there is no exception table, when there are no exceptions. However, there could be some cause for exceptions in the (buggy - due to insufficient development environment) code, and therefore you can get the type of crash Jeff described. In these cases it makes sense to at least implement some kind of attraction gathering, nonreturning stub as an exception handler, for example let the LED blink nervously. I presume your particular libgloss implementation for serial out does not use interrupts... The main question is, why did the CTR register contain 0xffffffff? This is the value that was pushed into the program counter by this lethal BCCTR instruction. Only the disassembled instructions before 0xc0c114 can tell... > So, what is up with this! I don?t know if my processor is broke In my experience this is almost never the case, once it got that far after reset... > or if this > is a illegal form of the instruction, or what. I?m not sure where the code > was headed next but was anxious to find out. svfwrite() in newlib-1.13/newlib/libc/stdtio/fvwrite.c is a myriad of if () clauses for some different conditions, and I guess the CTR register was used to implement jumps around some blocks... > It took about 1 ? hours of > single stepping to get to that point. You should give the breakpoint mechanism another try, now that you know where the crash happens. Breakpoints didn't work the other day for a valid reason: the code has never been reached. So no reason to believe the debugger doesn't work. gm _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 From gm at ib-magin.de Tue Aug 16 14:47:38 2005 From: gm at ib-magin.de (Gunter Magin) Date: Tue, 16 Aug 2005 21:47:38 +0200 Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) In-Reply-To: <200508160314.j7G3Eff8018860@shirkhan.intra> References: <200508160314.j7G3Eff8018860@shirkhan.intra> Message-ID: <20050816194738.GA4006@mailhub.intra> Hi David, (have been out all day...) On Mon, Aug 15, 2005 at 08:13:59PM -0700, David Eicher wrote: > Making some progress. I've discovered that the __sfvwrite ( ) function > accepts as input two parameters (fp and uio) as shown in this code snippet. > > _DEFUN(__sfvwrite, (fp, uio), > register FILE *fp _AND > register struct __suio *uio) > > It appears in the code that one of the parameters is passed to the function > in register r3, which gets copied to r27. I put a breakpoint at the > beginning of __sfvwrite (which is in file fvwrite.c) and discovered that r3 > is 0xFFFFFFFF at the beginning of execution. It is fp which has the wrong value. Did you initialize in any way stdin/stdout? No, I don't know precisely how to do that, but plain printf() expands the call to vfprintf (_stdout_r (_REENT), fmt, ap); So it has to do with _stdout_r, which actually is a macro defined in newlib-1.13.0/newlib/libc/include/stdio.h It uses a parameter _REENT, but I haven't found out where this is defined, and where and how it is initialized. I strongly guess this is the key for getting further. It can be as easy, as the implicit fopen() call for stdout is missing, but it also can be more. I have to bail out here. > So..., that is more background on why __sfvwrite is crashing. I have not > been able to tell which parameter is passed in r3 yet (working on it). See above. Parameter passing is part of the PowerPC-EABI specification. I think I have that in form of a .pdf from some IBM website, I forgot. But it is not essential at this point. gm From sailors3 at comcast.net Tue Aug 16 22:32:59 2005 From: sailors3 at comcast.net (David Eicher) Date: Tue, 16 Aug 2005 20:32:59 -0700 Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) In-Reply-To: <20050816194738.GA4006@mailhub.intra> Message-ID: Hi Gunter, Thanks for the insight here. I've discovered so far that _reent is defined in reent.h in: Newlib/libc/include/sys/ directory. I agree with you wholeheartedly, I need to figure out how to initialize stdout and stdin. I am getting the feeling that is my problem as I dig into this further. New info: it appears a function called _sinit( ) must run to initialize all stuff for stdio, including stdout stdin, and stderr. CHECK_INIT( ) is a macro that calls _sinit( ). Printf calls: _REENT_SMALL_CHECK_INIT (_stdout_r (ptr)); Rather than calling CHECK_INIT, it appears this call is failing somehow. My next task is to single step through this code and see if I can figure out why, and more importantly, what to do about it. More later, Thanks, Dave -----Original Message----- From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of Gunter Magin Sent: Tuesday, August 16, 2005 11:48 AM To: efi332 at diy-efi.org Subject: Re: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) Hi David, (have been out all day...) On Mon, Aug 15, 2005 at 08:13:59PM -0700, David Eicher wrote: > Making some progress. I've discovered that the __sfvwrite ( ) function > accepts as input two parameters (fp and uio) as shown in this code snippet. > > _DEFUN(__sfvwrite, (fp, uio), > register FILE *fp _AND > register struct __suio *uio) > > It appears in the code that one of the parameters is passed to the function > in register r3, which gets copied to r27. I put a breakpoint at the > beginning of __sfvwrite (which is in file fvwrite.c) and discovered that r3 > is 0xFFFFFFFF at the beginning of execution. It is fp which has the wrong value. Did you initialize in any way stdin/stdout? No, I don't know precisely how to do that, but plain printf() expands the call to vfprintf (_stdout_r (_REENT), fmt, ap); So it has to do with _stdout_r, which actually is a macro defined in newlib-1.13.0/newlib/libc/include/stdio.h It uses a parameter _REENT, but I haven't found out where this is defined, and where and how it is initialized. I strongly guess this is the key for getting further. It can be as easy, as the implicit fopen() call for stdout is missing, but it also can be more. I have to bail out here. > So..., that is more background on why __sfvwrite is crashing. I have not > been able to tell which parameter is passed in r3 yet (working on it). See above. Parameter passing is part of the PowerPC-EABI specification. I think I have that in form of a .pdf from some IBM website, I forgot. But it is not essential at this point. gm _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 From sailors3 at comcast.net Wed Aug 17 09:09:25 2005 From: sailors3 at comcast.net (David Eicher) Date: Wed, 17 Aug 2005 07:09:25 -0700 Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) Message-ID: New info: In newlib/libc/include/sys/config.h we have: #define _REENT_SMALL Which makes the code down below in newlib/libc/include/sys/reent.h set the macro _REENT_SMALL_CHECK_INIT(fp) = CHECK_INIT(fp), but I confirmed that there is no code in printf that calls _sinit(). Printf calls this macro just before calling vfprintf( ) where the work is done. We need CHECK_INIT(fp) to run because it calls _sinit( ) which initializes the entire stdio environment. It appears the macro is not getting expanded or something, not sure why there is no call to _sinit( ). CHECK_INIT() looks like this: #define CHECK_INIT(fp) \ do \ { \ if (_REENT && !_REENT->__sdidinit) \ __sinit (_REENT); \ } \ while (0) Maybe this if statement is failing to call _sinit( )? Thanks, Dave #ifdef _REENT_SMALL /* * struct __sFILE_fake is the start of a struct __sFILE, with only the * minimal fields allocated. In __sinit() we really allocate the 3 * standard streams, etc., and point away from this fake. */ struct __sFILE_fake { unsigned char *_p; /* current position in (some) buffer */ int _r; /* read space left for getc() */ int _w; /* write space left for putc() */ short _flags; /* flags, below; this FILE is free if 0 */ short _file; /* fileno, if Unix descriptor, else -1 */ struct __sbuf _bf; /* the buffer (at least 1 byte, if !NULL) */ int _lbfsize; /* 0 or -_bf._size, for inline putc */ struct _reent *_data; }; /* CHECK_INIT() comes from stdio/local.h; be sure to include that. */ # define _REENT_SMALL_CHECK_INIT(fp) CHECK_INIT(fp) #else # define _REENT_SMALL_CHECK_INIT(fp) /* nothing */ #endif -----Original Message----- From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of David Eicher Sent: Tuesday, August 16, 2005 7:33 PM To: efi332 at diy-efi.org Subject: RE: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) Hi Gunter, Thanks for the insight here. I've discovered so far that _reent is defined in reent.h in: Newlib/libc/include/sys/ directory. I agree with you wholeheartedly, I need to figure out how to initialize stdout and stdin. I am getting the feeling that is my problem as I dig into this further. New info: it appears a function called _sinit( ) must run to initialize all stuff for stdio, including stdout stdin, and stderr. CHECK_INIT( ) is a macro that calls _sinit( ). Printf calls: _REENT_SMALL_CHECK_INIT (_stdout_r (ptr)); Rather than calling CHECK_INIT, it appears this call is failing somehow. My next task is to single step through this code and see if I can figure out why, and more importantly, what to do about it. More later, Thanks, Dave -----Original Message----- From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of Gunter Magin Sent: Tuesday, August 16, 2005 11:48 AM To: efi332 at diy-efi.org Subject: Re: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) Hi David, (have been out all day...) On Mon, Aug 15, 2005 at 08:13:59PM -0700, David Eicher wrote: > Making some progress. I've discovered that the __sfvwrite ( ) function > accepts as input two parameters (fp and uio) as shown in this code snippet. > > _DEFUN(__sfvwrite, (fp, uio), > register FILE *fp _AND > register struct __suio *uio) > > It appears in the code that one of the parameters is passed to the function > in register r3, which gets copied to r27. I put a breakpoint at the > beginning of __sfvwrite (which is in file fvwrite.c) and discovered that r3 > is 0xFFFFFFFF at the beginning of execution. It is fp which has the wrong value. Did you initialize in any way stdin/stdout? No, I don't know precisely how to do that, but plain printf() expands the call to vfprintf (_stdout_r (_REENT), fmt, ap); So it has to do with _stdout_r, which actually is a macro defined in newlib-1.13.0/newlib/libc/include/stdio.h It uses a parameter _REENT, but I haven't found out where this is defined, and where and how it is initialized. I strongly guess this is the key for getting further. It can be as easy, as the implicit fopen() call for stdout is missing, but it also can be more. I have to bail out here. > So..., that is more background on why __sfvwrite is crashing. I have not > been able to tell which parameter is passed in r3 yet (working on it). See above. Parameter passing is part of the PowerPC-EABI specification. I think I have that in form of a .pdf from some IBM website, I forgot. But it is not essential at this point. gm _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 From sailors3 at comcast.net Wed Aug 17 09:28:22 2005 From: sailors3 at comcast.net (David Eicher) Date: Wed, 17 Aug 2005 07:28:22 -0700 Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) Message-ID: Here is what the disassembly of printf looks like, does anyone see code for the macro expansion of CHECK_INIT()? Thanks, Dave 00000090 : #ifndef _REENT_ONLY #ifdef _HAVE_STDC int printf(_CONST char *fmt, ...) #else int printf(fmt, va_alist) char *fmt; va_dcl #endif { 90: 94 21 ff 70 stwu r1,-144(r1) 94: 7c 08 02 a6 mflr r0 98: 42 9f 00 05 bcl- 20,4*cr7+so,9c 9c: 93 c1 00 88 stw r30,136(r1) a0: 7f c8 02 a6 mflr r30 a4: 90 81 00 0c stw r4,12(r1) a8: 90 01 00 94 stw r0,148(r1) int ret; va_list ap; _REENT_SMALL_CHECK_INIT (_stdout_r (_REENT)); #ifdef _HAVE_STDC va_start (ap, fmt); #else va_start (ap); #endif ret = vfprintf (_stdout_r (_REENT), fmt, ap); ac: 7c 64 1b 78 mr r4,r3 b0: 90 a1 00 10 stw r5,16(r1) b4: 38 a1 00 70 addi r5,r1,112 b8: 80 1e ff f0 lwz r0,-16(r30) bc: 90 c1 00 14 stw r6,20(r1) c0: 7f c0 f2 14 add r30,r0,r30 c4: 90 e1 00 18 stw r7,24(r1) c8: 81 7e 80 00 lwz r11,-32768(r30) cc: 91 01 00 1c stw r8,28(r1) d0: 81 6b 00 00 lwz r11,0(r11) d4: 91 21 00 20 stw r9,32(r1) d8: 91 41 00 24 stw r10,36(r1) dc: 40 86 00 24 bne- cr1,100 e0: d8 21 00 28 stfd f1,40(r1) e4: d8 41 00 30 stfd f2,48(r1) e8: d8 61 00 38 stfd f3,56(r1) ec: d8 81 00 40 stfd f4,64(r1) f0: d8 a1 00 48 stfd f5,72(r1) f4: d8 c1 00 50 stfd f6,80(r1) f8: d8 e1 00 58 stfd f7,88(r1) fc: d9 01 00 60 stfd f8,96(r1) 100: 38 00 00 01 li r0,1 104: 39 20 00 00 li r9,0 108: 98 01 00 70 stb r0,112(r1) 10c: 38 01 00 98 addi r0,r1,152 110: 99 21 00 71 stb r9,113(r1) 114: 39 21 00 08 addi r9,r1,8 118: 80 6b 00 08 lwz r3,8(r11) 11c: 90 01 00 74 stw r0,116(r1) 120: 91 21 00 78 stw r9,120(r1) 124: 48 00 00 01 bl 124 va_end (ap); return ret; } 128: 80 01 00 94 lwz r0,148(r1) 12c: 83 c1 00 88 lwz r30,136(r1) 130: 38 21 00 90 addi r1,r1,144 134: 7c 08 03 a6 mtlr r0 138: 4e 80 00 20 blr From sailors3 at comcast.net Wed Aug 17 22:48:31 2005 From: sailors3 at comcast.net (David Eicher) Date: Wed, 17 Aug 2005 20:48:31 -0700 Subject: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) In-Reply-To: <20050816194738.GA4006@mailhub.intra> Message-ID: Hi Gunter, New info, I discovered that CHECK_INIT(fp) is called in vfprintf_r so it is getting executed a different way than I thought. The bad news, running it did NOT result in executing __sinit( ). I believe it is because it got a bad pointer or argument from localeconv( ). So., my current theory is that the problem with with the locale setup/configure. For whatever reason, localeconv is not return a valid argument, I'll have to check on why tomorrow night. Thanks, Dave -----Original Message----- From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of Gunter Magin Sent: Tuesday, August 16, 2005 11:48 AM To: efi332 at diy-efi.org Subject: Re: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) Hi David, (have been out all day...) On Mon, Aug 15, 2005 at 08:13:59PM -0700, David Eicher wrote: > Making some progress. I've discovered that the __sfvwrite ( ) function > accepts as input two parameters (fp and uio) as shown in this code snippet. > > _DEFUN(__sfvwrite, (fp, uio), > register FILE *fp _AND > register struct __suio *uio) > > It appears in the code that one of the parameters is passed to the function > in register r3, which gets copied to r27. I put a breakpoint at the > beginning of __sfvwrite (which is in file fvwrite.c) and discovered that r3 > is 0xFFFFFFFF at the beginning of execution. It is fp which has the wrong value. Did you initialize in any way stdin/stdout? No, I don't know precisely how to do that, but plain printf() expands the call to vfprintf (_stdout_r (_REENT), fmt, ap); So it has to do with _stdout_r, which actually is a macro defined in newlib-1.13.0/newlib/libc/include/stdio.h It uses a parameter _REENT, but I haven't found out where this is defined, and where and how it is initialized. I strongly guess this is the key for getting further. It can be as easy, as the implicit fopen() call for stdout is missing, but it also can be more. I have to bail out here. > So..., that is more background on why __sfvwrite is crashing. I have not > been able to tell which parameter is passed in r3 yet (working on it). See above. Parameter passing is part of the PowerPC-EABI specification. I think I have that in form of a .pdf from some IBM website, I forgot. But it is not essential at this point. gm _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 From sailors3 at comcast.net Thu Aug 18 09:12:43 2005 From: sailors3 at comcast.net (David Eicher) Date: Thu, 18 Aug 2005 07:12:43 -0700 Subject: [Efi332] newlib stack size requirement? In-Reply-To: <20050816194738.GA4006@mailhub.intra> Message-ID: Does anyone know how large a stack is required for newlib libc, libmbx, and libgloss? Thanks, Dave From BowTieVette at aol.com Thu Aug 18 11:46:17 2005 From: BowTieVette at aol.com (BowTieVette at aol.com) Date: Thu, 18 Aug 2005 12:46:17 EDT Subject: [Efi332] newlib stack size requirement? Message-ID: <20.4b0c88ab.30361559@aol.com> In a message dated 8/18/2005 10:14:04 AM Eastern Standard Time, sailors3 at comcast.net writes: Does anyone know how large a stack is required for newlib libc, libmbx, and libgloss? Not exactly sure what you mean by that Dave. Stack usage is a runtime dependent thing that depends on what functions you are currently running from those libraries. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050818/f5ab3a69/attachment.html From sailors3 at comcast.net Thu Aug 18 20:20:34 2005 From: sailors3 at comcast.net (David Eicher) Date: Thu, 18 Aug 2005 18:20:34 -0700 Subject: [Efi332] newlib stack size requirement? In-Reply-To: <20.4b0c88ab.30361559@aol.com> Message-ID: Hi Jeff, I'm just wondering how much deeper libc will take me into the stack (worst case) to make sure my stack is sized correctly. Vfprintf looks like this: int _DEFUN(_VFPRINTF_R, (data, fp, fmt0, ap), struct _reent *data _AND FILE * fp _AND _CONST char *fmt0 _AND va_list ap) { 70: 94 21 f8 d0 stwu r1,-1840(r1) So it is using just 1840 bytes, I was afraid it was bigger than that. Code like this is executing in the locale.c file: struct lconv * _DEFUN_VOID(localeconv) { 170: 94 21 ff e0 stwu r1,-32(r1) 174: 7c 08 02 a6 mflr r0 178: 42 9f 00 05 bcl- 20,4*cr7+so,17c 17c: 93 c1 00 18 stw r30,24(r1) 180: 7f c8 02 a6 mflr r30 184: 90 01 00 24 stw r0,36(r1) 188: 80 1e ff f0 lwz r0,-16(r30) 18c: 7f c0 f2 14 add r30,r0,r30 return _localeconv_r (_REENT); } 190: 80 01 00 24 lwz r0,36(r1) 194: 81 3e 80 10 lwz r9,-32752(r30) 198: 7c 08 03 a6 mtlr r0 19c: 83 c1 00 18 lwz r30,24(r1) 1a0: 80 69 00 00 lwz r3,0(r9) 1a4: 3 Look at that instruction at address 194: What is that??? A 32k offset on some access. I guess that is the one I thought at first might have been a stack access. It must be something else but haven't checked to see where it goes. It looks like I'm probably okay on stack at 4k unless some of the other lib calls are nested and big stack users. Regards, Dave _____ From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of BowTieVette at aol.com Sent: Thursday, August 18, 2005 8:46 AM To: efi332 at diy-efi.org Subject: Re: [Efi332] newlib stack size requirement? In a message dated 8/18/2005 10:14:04 AM Eastern Standard Time, sailors3 at comcast.net writes: Does anyone know how large a stack is required for newlib libc, libmbx, and libgloss? Not exactly sure what you mean by that Dave. Stack usage is a runtime dependent thing that depends on what functions you are currently running from those libraries. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050818/75f69728/attachment.html From bowtievette at aol.com Thu Aug 18 20:55:04 2005 From: bowtievette at aol.com (bowtievette at aol.com) Date: Thu, 18 Aug 2005 21:55:04 -0400 Subject: [Efi332] newlib stack size requirement? In-Reply-To: <200508182121.62f4305342589@rly-xn02.mx.aol.com> Message-ID: <8C77278273B50C4-990-1378@FWM-R25.sysops.aol.com> Yeah, 32k for a stack for printf is rediculous. If it needs that much something is wrong. Testing if thats the case is easy though. Just allocate a huge stack, fill it with 0xFFFF's and see how much it uses. To me it seems unlikely that this is the problem though. Does sprintf work? Probably not since it probably relies on the same low level code. -----Original Message----- From: David Eicher To: efi332 at diy-efi.org Sent: Thu, 18 Aug 2005 18:20:34 -0700 Subject: RE: [Efi332] newlib stack size requirement? Hi Jeff, I?m just wondering how much deeper libc will take me into the stack (worst case) to make sure my stack is sized correctly. Vfprintf looks like this: int _DEFUN(_VFPRINTF_R, (data, fp, fmt0, ap), struct _reent *data _AND FILE * fp _AND _CONST char *fmt0 _AND va_list ap) { 70: 94 21 f8 d0 stwu r1,-1840(r1) So it is using just 1840 bytes, I was afraid it was bigger than that. Code like this is executing in the locale.c file: struct lconv * _DEFUN_VOID(localeconv) { 170: 94 21 ff e0 stwu r1,-32(r1) 174: 7c 08 02 a6 mflr r0 178: 42 9f 00 05 bcl- 20,4*cr7+so,17c 17c: 93 c1 00 18 stw r30,24(r1) 180: 7f c8 02 a6 mflr r30 184: 90 01 00 24 stw r0,36(r1) 188: 80 1e ff f0 lwz r0,-16(r30) 18c: 7f c0 f2 14 add r30,r0,r30 return _localeconv_r (_REENT); } 190: 80 01 00 24 lwz r0,36(r1) 194: 81 3e 80 10 lwz r9,-32752(r30) 198: 7c 08 03 a6 mtlr r0 19c: 83 c1 00 18 lwz r30,24(r1) 1a0: 80 69 00 00 lwz r3,0(r9) 1a4: 3 Look at that instruction at address 194: What is that??? A 32k offset on some access. I guess that is the one I thought at first might have been a stack access. It must be something else but haven?t checked to see where it goes. It looks like I?m probably okay on stack at 4k unless some of the other lib calls are nested and big stack users. Regards, Dave From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of BowTieVette at aol.com Sent: Thursday, August 18, 2005 8:46 AM To: efi332 at diy-efi.org Subject: Re: [Efi332] newlib stack size requirement? In a message dated 8/18/2005 10:14:04 AM Eastern Standard Time, sailors3 at comcast.net writes: Does anyone know how large a stack is required for newlib libc, libmbx, and libgloss? Not exactly sure what you mean by that Dave. Stack usage is a runtime dependent thing that depends on what functions you are currently running from those libraries. _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050818/9575db52/attachment.html From sailors3 at comcast.net Thu Aug 18 21:01:53 2005 From: sailors3 at comcast.net (David Eicher) Date: Thu, 18 Aug 2005 19:01:53 -0700 Subject: [Efi332] newlib stack size requirement? In-Reply-To: <8C77278273B50C4-990-1378@FWM-R25.sysops.aol.com> Message-ID: Yep, printf uses 144 bytes on the stack, it appears vfprintf uses 1840 bytes. That 32k offset was on a pointer in r30 and I don't know where it's pointing I suppose I should step through and see. Regards, Dave _____ From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of bowtievette at aol.com Sent: Thursday, August 18, 2005 5:55 PM To: efi332 at diy-efi.org Subject: Re: [Efi332] newlib stack size requirement? Yeah, 32k for a stack for printf is rediculous. If it needs that much something is wrong. Testing if thats the case is easy though. Just allocate a huge stack, fill it with 0xFFFF's and see how much it uses. To me it seems unlikely that this is the problem though. Does sprintf work? Probably not since it probably relies on the same low level code. -----Original Message----- From: David Eicher To: efi332 at diy-efi.org Sent: Thu, 18 Aug 2005 18:20:34 -0700 Subject: RE: [Efi332] newlib stack size requirement? Hi Jeff, I?m just wondering how much deeper libc will take me into the stack (worst case) to make sure my stack is sized correctly. Vfprintf looks like this: int _DEFUN(_VFPRINTF_R, (data, fp, fmt0, ap), struct _reent *data _AND FILE * fp _AND _CONST char *fmt0 _AND va_list ap) { 70: 94 21 f8 d0 stwu r1,-1840(r1) So it is using just 1840 bytes, I was afraid it was bigger than that. Code like this is executing in the locale.c file: struct lconv * _DEFUN_VOID(localeconv) { 170: 94 21 ff e0 stwu r1,-32(r1) 174: 7c 08 02 a6 mflr r0 178: 42 9f 00 05 bcl- 20,4*cr7+so,17c 17c: 93 c1 00 18 stw r30,24(r1) 180: 7f c8 02 a6 mflr r30 184: 90 01 00 24 stw r0,36(r1) 188: 80 1e ff f0 lwz r0,-16(r30) 18c: 7f c0 f2 14 add r30,r0,r30 return _localeconv_r (_REENT); } 190: 80 01 00 24 lwz r0,36(r1) 194: 81 3e 80 10 lwz r9,-32752(r30) 198: 7c 08 03 a6 mtlr r0 19c: 83 c1 00 18 lwz r30,24(r1) 1a0: 80 69 00 00 lwz r3,0(r9) 1a4: 3 Look at that instruction at address 194: What is that??? A 32k offset on some access. I guess that is the one I thought at first might have been a stack access. It must be something else but haven?t checked to see where it goes. It looks like I?m probably okay on stack at 4k unless some of the other lib calls are nested and big stack users. Regards, Dave _____ From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of BowTieVette at aol.com Sent: Thursday, August 18, 2005 8:46 AM To: efi332 at diy-efi.org Subject: Re: [Efi332] newlib stack size requirement? In a message dated 8/18/2005 10:14:04 AM Eastern Standard Time, sailors3 at comcast.net writes: Does anyone know how large a stack is required for newlib libc, libmbx, and libgloss? Not exactly sure what you mean by that Dave. Stack usage is a runtime dependent thing that depends on what functions you are currently running from those libraries. _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050818/59f53c93/attachment.html From sailors3 at comcast.net Thu Aug 18 23:16:11 2005 From: sailors3 at comcast.net (David Eicher) Date: Thu, 18 Aug 2005 21:16:11 -0700 Subject: [Efi332] RE: Using newlib Message-ID: I think _sinit may run if we can get the _RENT structure set up right. Apparently there is suppose to be a pointer called _impure_ptr which is suppose to point to a _reent structure which is used to make all these library routines reentrant. When I run printf the _impure_ptr is accessed (actually right after printf calls vfprintf), the pointer value is read and used by vfprintf. The pointer value is 0x40. So the code soon tries to read a field of the _reent structure at location 0x40 which is flash memory and all FFFFFFFs. So the _REENT data is invalid. It isn't long before vfprintf crashes as a result of this. I'm not sure how the _impure_ptr gets initialized. Does anyone know? If I can figure that out (next task), I can probably figure out what to change to fix it. Thanks, Dave -----Original Message----- From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of David Eicher Sent: Wednesday, August 17, 2005 7:49 PM To: efi332 at diy-efi.org Subject: RE: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) Hi Gunter, New info, I discovered that CHECK_INIT(fp) is called in vfprintf_r so it is getting executed a different way than I thought. The bad news, running it did NOT result in executing __sinit( ). I believe it is because it got a bad pointer or argument from localeconv( ). So., my current theory is that the problem with with the locale setup/configure. For whatever reason, localeconv is not return a valid argument, I'll have to check on why tomorrow night. Thanks, Dave -----Original Message----- From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of Gunter Magin Sent: Tuesday, August 16, 2005 11:48 AM To: efi332 at diy-efi.org Subject: Re: Using newlib (was: [Efi332] Building newlib/libgloss for MPC555) Hi David, (have been out all day...) On Mon, Aug 15, 2005 at 08:13:59PM -0700, David Eicher wrote: > Making some progress. I've discovered that the __sfvwrite ( ) function > accepts as input two parameters (fp and uio) as shown in this code snippet. > > _DEFUN(__sfvwrite, (fp, uio), > register FILE *fp _AND > register struct __suio *uio) > > It appears in the code that one of the parameters is passed to the function > in register r3, which gets copied to r27. I put a breakpoint at the > beginning of __sfvwrite (which is in file fvwrite.c) and discovered that r3 > is 0xFFFFFFFF at the beginning of execution. It is fp which has the wrong value. Did you initialize in any way stdin/stdout? No, I don't know precisely how to do that, but plain printf() expands the call to vfprintf (_stdout_r (_REENT), fmt, ap); So it has to do with _stdout_r, which actually is a macro defined in newlib-1.13.0/newlib/libc/include/stdio.h It uses a parameter _REENT, but I haven't found out where this is defined, and where and how it is initialized. I strongly guess this is the key for getting further. It can be as easy, as the implicit fopen() call for stdout is missing, but it also can be more. I have to bail out here. > So..., that is more background on why __sfvwrite is crashing. I have not > been able to tell which parameter is passed in r3 yet (working on it). See above. Parameter passing is part of the PowerPC-EABI specification. I think I have that in form of a .pdf from some IBM website, I forgot. But it is not essential at this point. gm _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 From PaulHelmuth at SprintMail.com Sun Aug 28 23:30:15 2005 From: PaulHelmuth at SprintMail.com (Paul Helmuth) Date: Sun, 28 Aug 2005 23:30:15 -0500 Subject: [Efi332] Quick project update to the list... Message-ID: <000d01c5ac52$5bf9cb00$6b7ba8c0@p2450> All, Well, I finally got everything in order to trigger the ignition system with my MPC555 based ECU - and the ignition portion seems to be working beautifully. I had some machine work done a few weeks ago to provide the mounting of the crank trigger wheel to the crank pulley. That turned out very nice. I fabricated a simple mount for the sensor last weekend, but initial testing showed a problem maintaining crank-synch below 1200 RPM. Apparently there was enough engine vibration/movement to cause the gap between the sensor and the trigger wheel to vary in way that resulted in the PMMX function loosing synch. All I had to do to make a short-term fix was to tighten up a loose motor mount, but after seeing the problem I am also going to add a bracket to the sensor mount to eliminate (at least in practical terms) any "swaying" motion of the sensor. After tightening up one motor mount, synch was being maintained at all RPM so I flipped the switch to have the ECU trigger the ignition box and the engine never skipped a beat. It did pick up some RPM due to the fact that the ECU was giving it about 10 more degrees advance at idle. The next test was to see if the ECU would be able to synch at cranking speed and thus start. Somewhat to my surprise, it did! So, now it's on to the more interesting part - actually controlling fuel flow. Since my initial target platform is an 1800B (from an MGB) there is going to be a lot work just sorting out the EFI pieces and parts and getting them attached to the MGB, but it should be great fun. Dave - how goes the interrupt-driven serial I/O library stuff? -Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050828/eb069743/attachment.html From sailors3 at comcast.net Mon Aug 29 07:20:03 2005 From: sailors3 at comcast.net (David Eicher) Date: Mon, 29 Aug 2005 05:20:03 -0700 Subject: [Efi332] Quick project update to the list... In-Reply-To: <000d01c5ac52$5bf9cb00$6b7ba8c0@p2450> Message-ID: Hi Paul, Impressive accomplishments! Wow! I?ll be watching with interest for future updates on your progress with the fuel control. Thanks for sharing your progress with the list. I?m not sure if I?m the Dave you address, but I?ll give you a status anyway: Accomplishments: 1) GNU tools in place, but no GDB/Insight yet, need better debug capability (working on getting CodeWarrior also, might hear this week on that). 2) Ported newlib for use on my MPC555 platform so now have a library. 3) Have a BIT (built-in-test) monitor program running (from Jeff Clarke) on my target to be used for testing the hardware, making sure the stepper motor, injector drivers, sensor inputs, etc., are all connected properly and working. Next steps: 1) Complete some of the test code in the monitor program. 2) Burn this monitor program and it's associated exception vector table into flash with vectors to trampoline (vectored out to a table in RAM so I can test interrupt based routines for many functions. 3) Port uC/OS-II RTOS to my target, get it configured. Probably at this point I will figure out interrupts, need them for many things, including interrupt based QSCI for instrumenting data, my own custom PMMX, etc. 4) Port efi332 fuel management to uC/OS-II environment. 5) Add ignition control (my engine is LS1 - no distributor, coil-near-plug for each cylinder). As part of this I will need to either figure out the LS1 crank position sensor pattern (new and different from 60-2, etc.) and write TPU microcode for it, or mount a crank trigger wheel on the pulley like you did. You have confirmed what I suspected that this must be precision mounted, I can't drill three holes with a hand drill and bolt it on, or I'd have serious run-out problems. 6) Test engine management thoroughly with simulator (simulated inputs). 7) Move it to engine, test and tune. 8) Drive the car 8-) Best regards, Dave ________________________________________ From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of Paul Helmuth Sent: Sunday, August 28, 2005 8:30 PM To: efi332 at diy-efi.org Subject: [Efi332] Quick project update to the list... All, ? Well, I finally got everything in order to trigger the ignition system with my MPC555 based ECU - and the ignition portion seems to be working beautifully. ? I had some machine work done a few weeks ago to provide the mounting of the crank trigger wheel to the crank pulley. That turned out very nice. I fabricated a simple mount for the sensor last weekend, but initial testing showed a problem maintaining crank-synch below 1200 RPM. Apparently there was enough engine vibration/movement to cause the gap between the sensor and the trigger wheel to vary in way that resulted in the PMMX function loosing synch. ? All I had to do to make a short-term fix was to tighten up a loose motor mount, but after seeing the problem I am also going to add a bracket to the sensor mount to eliminate (at least in practical terms) any "swaying" motion of the sensor. ? After tightening up one motor mount, synch was being maintained at all RPM so I flipped the switch to have the ECU trigger the ignition box and the engine never skipped a beat. It did pick up some RPM due to the fact that the ECU was giving it about 10 more degrees advance at idle. ? The next test was to see if the ECU would be able to synch at cranking speed and thus start. Somewhat to my surprise, it did! ? So, now it's on to the more interesting part - actually controlling fuel flow. Since my initial target platform is an 1800B (from an MGB) there is going to be a lot work just sorting out the EFI pieces and parts and getting them attached to the MGB, but it should be great fun. ? Dave - how goes the interrupt-driven serial I/O library stuff? ? -Paul