RTEMS 4.7.99.2 Available -- PowerPC/virtex feedback

[Robert S. Grimes]

gregory.menke at gsfc.nasa.gov wrote:
> I don't have any machines up with the RTEMS ppc build, so I am going
> from memory.  I looked at the printf suite since that stuff comes with
> newlib and is independent of whatever flags RTEMS and user software are
> compiled with and issues due to newlib will arise no matter what you do
> with your makefiles.
>   
Understood - thanks!
> I use "powerpc-rtems-objdump -dst xxxxx > tmpfile" (where xxxx is the
> rtems library that contains the newlib stuff) then search tempfile for
> the printf library code & examine it.  The problem is not necessarily
> floating point opcodes but the use of floating point registers (FPR0 and
> similar) in any of the general cpu instructions.
>   
I just did a case-insensitive search for fpr[0-9], and found no matches,
so I think those issues (floating-point registers or floating-point
instructions) are not the problem.
> OTOH your toolchain results suggest it is likely not a fpu related
> problem; newlib comes from the gcc build, not RTEMS so this could be a
> bsp related issue.  When we were running into startup problems because
> of the use of FPU registers, we couldn't even finish the executive
> startup before being caught in an infinite exception loop.
>   
Seems I'm there now, except there are no FPU registers or instructions
to be found.  Seems I'm left with "illegal instructions" or a BSP
interrupt enabling problem.  No idea where to look for that...

On the positive, because 4.7.99.2 fails much more predictably (as far as
I can tell so far, in exactly the same place), I have both a good place
to start looking, and (I guess) I'm helping with the 4.8 release
candidate testing! ;)

Thanks!
-Bob
> Regards,
>
> Greg
>
>
>
>
> Robert S. Grimes writes:
>  > Chris and Greg, you seem to be right - see below.
>  > gregory.menke at gsfc.nasa.gov wrote:
>  > > I ended up using the newlib printf suite as the test- if fp registers
>  > > are shown in the instructions, then it meant I had a build problem w/
>  > > newlib.  The assembly is dramatically different when the fp registers
>  > > are excluded.
>  > >   
>  > Don't know what you are talking about ("newlib printf suite"), so I
>  > checked my own code.
>  > > Chris Caudle writes:
>  > >  > Doesn't that imply that the tools for PPC405 should already be using soft
>  > >  > float?
>  > >  > Everyone is scurrying around figuring out how to rebuild tools with soft
>  > >  > float, but it looks like that should be the default already, and so far no
>  > >  > one has presented any code which confirms that the exception was actually
>  > >  > caused by using a floating point register.
>  > >  > 
>  > >  > Shouldn't looking at the instructions to see if that is a feasible
>  > >  > explanation be the first step?
>  > >
>  > >   
>  > I did this instruction:
>  > 
>  >     $ powerpc-rtems-objdump -d --architecture=powerpc:403 myprog.exe >
>  > myprog.exe.disasm.txt
>  > 
>  > and examined the results.  Now, I'm not 100% sure what I'm looking for,
>  > but I figured the floating point store instructions (e.g.stfd, stfx,
>  > etc.) were good candidates.  In fact, searching for "stf" turned up
>  > nothing.  I also couldn't find any floating point load, nor any of the
>  > operations that I looked for.  So I think, Chris, your comment from your
>  > first email on this is likely closer to the truth:
>  > 
>  >     "More accurately it is "program exception," which is also triggered
>  > by illegal opcode."
>  > 
>  > You had followed this up by asking if the tool chain had changed between
>  > head from a month ago and 4.7.99.2, and the answer is: No.
>  > 
>  > So I'm a bit stumped right now.  On the one hand I have an application
>  > that works with the older RTEMs, but fails on startup with 4.7.99.2 -
>  > sounds bad for 4.7.99.2!  On the other hand, its failure sounds a bit
>  > like that of my earlier post regarding "isync, exceptions, et. al" from
>  > last Thursday - similar, but worse.
>  > 
>  > Any ideas?
>  > 
>  > Does it seem correct to rule out (at least temporarily) the tool chain
>  > as the culprit?
>  > 
>  > Thanks!
>  > -Bob
>  > 
>
>
>