[ECOS] why jump from hal_cpu_merge_int to hal_null_call() ?

Gary D. Thomas gary.thomas@mind.be
Mon May 12 16:45:00 GMT 2003


On Mon, 2003-05-12 at 10:56, Zi Zhou wrote:
> Hi Gary,
> 
> I tried with both Redboot and GDB, I can load the application, but once I enter the
> command to run the application, it will hang without any information on the console.
> GDB doesn't seem to be able to step that early part of the startup code.
> 

You should be able to load your application using GDB and then
step through it - slowly.  At some point, this will stop working.
This is the part of the code that may need changing for your port.

Note: I can't tell you where this may happen.  I do know that GDB
works fine on the PowerPC ports, including stepping through eCos
programs from the very start.

> thanks
> 
> Zi
> 
> "Gary D. Thomas" wrote:
> 
> > On Fri, 2003-05-09 at 17:59, Zi Zhou wrote:
> > > "Gary D. Thomas" wrote:
> > >
> > > > On Fri, 2003-05-09 at 16:33, Zi Zhou wrote:
> > > > > Hi,
> > > > >
> > > > > I am trying to port eCos on to a demo board which uses MPC8245. So I use
> > > > > csb281 as a baseline. I am able to bring up Redboot with minimum hardware
> > > > > initialized (e.g. UART). I am trying to load the simple eCos 'hello world'
> > > > > application but failed. I have a VisualClick EJTAG to help debugging,  and I
> > > > > found that when execute to hal_cpu_merge_int macro, right after the first
> > > > > 'sync',  the program will jump to hal_null_call(), which is at address 0x0.
> > > > > The MSR register is 0x3032 and r0 is 0xb032 right after 'rlwimi' instruction,
> > > > >   and MSR becomes 0 after jumping to hal_null_call(). Since I am not an
> > > > > expert of eCos or PowerPC, I will really need some info about what could go
> > > > > wrong to cause this scenorio. Could someone give me some suggestion?
> > > >
> > > > If you're not using a ROM monitor (like RedBoot), have you initialized
> > > > the interrupt environment?  The default case on the PowerPC for RAM
> > > > applications is to inherit an already initialized environment.  In
> > > > particular, the application will normally not set up interrupt and
> > > > exception handlers.
> > > >
> > >
> > > I have a Redboot running in PROM at address 0xfff00000. And I use EJTAG to load
> > > RAM application.
> > >
> > > >
> > > > I suspect that this is your problem. Try disabling CYGSEM_HAL_USE_ROM_MONITOR.
> > >
> > > I try to disable it, and it failed even before cyg_start(), seems while trying to
> > > invoke C++ constructor, it entered an endless loop  of
> > > cyg_hal_diag_mangler_gdb_flush. BTW, if I don't use a ROM monitor, by disabling
> > > CYGSEM_HAL_USE_ROM_MONITOR,
> > > what should I expect to happen? If I have initialized interrupt environment in RAM
> > > application, I guess everything should be fine,
> > > if not, will I jump to address 0x0? But I don't understand why I would jump to
> > > hal_null_call() before I enable external exception by
> > > writing 0xb032 to MSR? What is actually happening while CPU is executing 'sync' ?
> > >
> > > Thanks a lot for any help !
> > >
> >
> > If you've got RedBoot running, there's no need to disable this option;
> > leave it alone.
> >
> > What happens if you load & start the application via RedBoot?
> > How about if your load & start it using GDB?
> >
> > Both of the above options should be supported already by your
> > environment.
> >
> > > Zi
> > >
> > > >
> > > >
> > > > --
> > > > Gary D. Thomas <gary.thomas@mind.be>
> > > >
> > > > --
> > > > Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> > > > and search the list archive: http://sources.redhat.com/ml/ecos-discuss
> > --
> > Gary D. Thomas <gary.thomas@mind.be>
> >
> > --
> > Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> > and search the list archive: http://sources.redhat.com/ml/ecos-discuss
-- 
Gary D. Thomas <gary.thomas@mind.be>


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



More information about the Ecos-discuss mailing list