This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: why jump from hal_cpu_merge_int to hal_null_call() ?


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.

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]