Re: [ECOS] Axiom CME-555: RedBoot ROM crashing

Re: [ECOS] Axiom CME-555: RedBoot ROM crashing

[Bob Koninckx]

On Tue, 2004-05-18 at 00:18, Eric Castle wrote:
> Hi again Bob, everyone on the list,
> 
> We have an Axiom CME-555 board and are attempting to load RedBoot into
> internal flash.  We built this using the 2.0 version of eCos using the
> configtool by:
> 1) Selecting Axiom CME-555 and RedBoot from the templates menu

that's ok

> 2) Importing the redboot_ROM.ecm file.

that's ok too

> 3) Selecting the "RESET vector jumps to startup" option (this actually gets

don't do that

> it so that execution goes to the start of the program).
> 
> We download the produced .elf file using the flash programmer in Metrowerks
> CodeWarrior and a wiggler.  The jumper settings are M-select off, Ram-select
> 1, and Flash-select 2.  We set the config switch so that 2, 4, 5, and 6 are
> on (5 and 6 allow writes to internal flash, 2 and 4 are standard).  This
> allows us to successfully download RedBoot to internal flash.
> 
> We then reset the board, setting the config switch so that only 2 and 4 are
> on, and setting mode switch 2, switch 1 on, so that internal flash is
> enabled.  After opening a hyperterminal window (running at settings that are
> at least compatible with a RAM version of RedBoot), we don't get any output.
> 
> Examining the code, it seems to fail somewhere within RedBoot.  We noticed a
> few pieces of suspicious behavior (using OCD Commander to try stepping
> through execution):

If you have access to a bdm, it shouldn't be too hard to find out what's
wrong

> 
> 1) It did not seem to recognize floating point instructions (maybe this is
> just a failing of OCD Commander?)

Floating point? Redboot does not use floating point instructions. May be
usefull for debugging to purposes to turn them on anyway

In the powerpc 5xx variant hal package, turn on

Variant FPU support
enable internal flash
set QSCI interrupt source priority to 31



> 
> 2) It hung on a "RFI" instruction.


Could be that something causes an exception (illegal instruction
perhaps). Normally, redboot should not execute any rfi


> 
> 
> Does anyone have any idea if how we configured RedBoot incorrectly, or what
> is going wrong in our version of RedBoot?  Any ideas or assistance would be
> greatly appreciated.

Try stepping through the code from the reset vector and see how far you
get. Make sure the reset vector effectively gets you to the _start
routine. From what you describe, I doubt it will be the case.

Bob

> 
> Thanks,
> 
> -Eric Castle and Miguel Vega
> FEGI
> University of Michigan
> 
> 


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Axiom CME-555: RedBoot ROM crashing

[Eric Gregory Castle]

On Tue, 18 May 2004, Bob Koninckx wrote:

> On Tue, 2004-05-18 at 00:18, Eric Castle wrote:
> > Hi again Bob, everyone on the list,
> >
> > We have an Axiom CME-555 board and are attempting to load RedBoot into
> > internal flash.  We built this using the 2.0 version of eCos using the
> > configtool by:
> > 1) Selecting Axiom CME-555 and RedBoot from the templates menu
>
> that's ok
>
> > 2) Importing the redboot_ROM.ecm file.
>
> that's ok too
>
> > 3) Selecting the "RESET vector jumps to startup" option (this actually gets
>
> don't do that

Looked at that again, you were right.

>
> > it so that execution goes to the start of the program).
> >
> > We download the produced .elf file using the flash programmer in Metrowerks
> > CodeWarrior and a wiggler.  The jumper settings are M-select off, Ram-select
> > 1, and Flash-select 2.  We set the config switch so that 2, 4, 5, and 6 are
> > on (5 and 6 allow writes to internal flash, 2 and 4 are standard).  This
> > allows us to successfully download RedBoot to internal flash.
> >
> > We then reset the board, setting the config switch so that only 2 and 4 are
> > on, and setting mode switch 2, switch 1 on, so that internal flash is
> > enabled.  After opening a hyperterminal window (running at settings that are
> > at least compatible with a RAM version of RedBoot), we don't get any output.
> >
> > Examining the code, it seems to fail somewhere within RedBoot.  We noticed a
> > few pieces of suspicious behavior (using OCD Commander to try stepping
> > through execution):
>
> If you have access to a bdm, it shouldn't be too hard to find out what's
> wrong

That's what I'd hoped, but using OCD commander and the wiggler seems to
give rather bogus results.  Stepping through results in rather random
jumping that quickly ends at unknown opcodes or address 0xFFFFFFFF.

Is there some sort of settings that need to be enabled to use a background
debugger?

> >
> > 1) It did not seem to recognize floating point instructions (maybe this is
> > just a failing of OCD Commander?)
>
> Floating point? Redboot does not use floating point instructions. May be
> usefull for debugging to purposes to turn them on anyway

Did you mean on, or to turn off floating point?

> In the powerpc 5xx variant hal package, turn on
>
> Variant FPU support
> enable internal flash
> set QSCI interrupt source priority to 31

I had all of these set except the last.  This alters the priority of the
serial module; why?

>
> >
> > 2) It hung on a "RFI" instruction.
>
>
> Could be that something causes an exception (illegal instruction
> perhaps). Normally, redboot should not execute any rfi
>
>
> >
> >
> > Does anyone have any idea if how we configured RedBoot incorrectly, or what
> > is going wrong in our version of RedBoot?  Any ideas or assistance would be
> > greatly appreciated.
>
> Try stepping through the code from the reset vector and see how far you
> get. Make sure the reset vector effectively gets you to the _start
> routine. From what you describe, I doubt it will be the case.

No, it doesn't seem to.  Any idea why?

> Bob
>
> >
> > Thanks,

And more thanks,

-Eric

> > -Eric Castle and Miguel Vega
> > FEGI
> > University of Michigan
> >
> >
>
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Axiom CME-555: RedBoot ROM crashing

[Bob Koninckx]

Eric, sorry that it took me so long to reply. Becoming a father is a
good excuse tough :-)


On Tue, 2004-05-25 at 16:03, Eric Gregory Castle wrote:

> That's what I'd hoped, but using OCD commander and the wiggler seems to
> give rather bogus results.  Stepping through results in rather random
> jumping that quickly ends at unknown opcodes or address 0xFFFFFFFF.
> 
> Is there some sort of settings that need to be enabled to use a background
> debugger?
> 

hmmm... stepping one instruction at a time should work since it does not
require write access to program memory on the powerpc. Are you sure you
initialize th processor as it should _before_ trying to step? You find
info on how to do this on axiom's website. Make sure your debugger works
using some piece of working software.

...

> > Floating point? Redboot does not use floating point instructions. May be
> > usefull for debugging to purposes to turn them on anyway
> 
> Did you mean on, or to turn off floating point?

Turn them on. Even if redboot does not use them, the application you are
debugging might. Turning on floating point support makes sure redboot
saves floating point registers, enabling GDB to display their contents.

> I had all of these set except the last.  This alters the priority of the
> serial module; why?

It is not really necessary I suppose. Just gave you the configuration
that works for me.

> >
> > Try stepping through the code from the reset vector and see how far you
> > get. Make sure the reset vector effectively gets you to the _start
> > routine. From what you describe, I doubt it will be the case.
> 
> No, it doesn't seem to.  Any idea why?
> 

Nope. That's for you to find out :-)




-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Axiom CME-555: RedBoot ROM crashing

[Eric Castle]

> Eric, sorry that it took me so long to reply. Becoming a father is a
> good excuse tough :-)

Congrats! 

> > That's what I'd hoped, but using OCD commander and the wiggler seems to
> > give rather bogus results.  Stepping through results in rather random
> > jumping that quickly ends at unknown opcodes or address 0xFFFFFFFF.
> > 
> > Is there some sort of settings that need to be enabled to use a 
> > background debugger?
> > 

> hmmm... stepping one instruction at a time should work since it does not
> require write access to program memory on the powerpc. Are you sure you
> initialize th processor as it should _before_ trying to step? You find
> info on how to do this on axiom's website. Make sure your debugger works
> using some piece of working software.

So we tried the sample programs from Axiom, which sort of worked.  I'll have
to try this again.

... <editing stuff I no longer think was so relevant>

> > >
> > > Try stepping through the code from the reset vector and see how far
you
> > > get. Make sure the reset vector effectively gets you to the _start
> > > routine. From what you describe, I doubt it will be the case.
> > 
> > No, it doesn't seem to.  Any idea why?
> > 

> Nope. That's for you to find out :-)

To get redboot to run, Miguel converted it into an srec file:

powerpc-eabi-objcopy -O srec --force-s3 redboot.elf redboot.srec 
	(syntax approximated)

This was to try out the Axiom flash programmer, which requires srec files
(and only works if you set the delay between lines to something like 60-100
ms, not 15, as Axiom claims).

At this point, redboot worked (minus the external flash driver, as Miguel
has noted in other posts).

Downloading to flash via BDM works fine as well when given an SREC file.  I
think the trouble is either inherent to the .elf format (although I thought
I'd successfully run Axiom's program this way before), or, converting to an
SREC made the program small enough to fit into internal flash (the .elf file
was something like 600K).

Thanks for your help with this,

-Eric Castle
C&DH Subsystem of FEGI
University of Michigan



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Axiom CME-555: RedBoot ROM crashing

[Eric Castle]

Hi again Bob, everyone on the list,

We have an Axiom CME-555 board and are attempting to load RedBoot into
internal flash.  We built this using the 2.0 version of eCos using the
configtool by:
1) Selecting Axiom CME-555 and RedBoot from the templates menu
2) Importing the redboot_ROM.ecm file.
3) Selecting the "RESET vector jumps to startup" option (this actually gets
it so that execution goes to the start of the program).

We download the produced .elf file using the flash programmer in Metrowerks
CodeWarrior and a wiggler.  The jumper settings are M-select off, Ram-select
1, and Flash-select 2.  We set the config switch so that 2, 4, 5, and 6 are
on (5 and 6 allow writes to internal flash, 2 and 4 are standard).  This
allows us to successfully download RedBoot to internal flash.

We then reset the board, setting the config switch so that only 2 and 4 are
on, and setting mode switch 2, switch 1 on, so that internal flash is
enabled.  After opening a hyperterminal window (running at settings that are
at least compatible with a RAM version of RedBoot), we don't get any output.

Examining the code, it seems to fail somewhere within RedBoot.  We noticed a
few pieces of suspicious behavior (using OCD Commander to try stepping
through execution):

1) It did not seem to recognize floating point instructions (maybe this is
just a failing of OCD Commander?)

2) It hung on a "RFI" instruction.


Does anyone have any idea if how we configured RedBoot incorrectly, or what
is going wrong in our version of RedBoot?  Any ideas or assistance would be
greatly appreciated.

Thanks,

-Eric Castle and Miguel Vega
FEGI
University of Michigan



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss