This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: why jump from hal_cpu_merge_int to hal_null_call() ?
- From: Zi Zhou <zzhou at 3upsystems dot com>
- To: "Gary D. Thomas" <gary dot thomas at mind dot be>
- Cc: eCos Discussion <ecos-discuss at sources dot redhat dot com>
- Date: Fri, 09 May 2003 16:59:59 -0700
- Subject: Re: [ECOS] why jump from hal_cpu_merge_int to hal_null_call() ?
- Organization: 3upsystems
- References: <3E77E13A.AF0154CE@3upsystems.com> <3E8E1953.24199633@3upsystems.com> <3EBC2CC5.DFC3087A@3upsystems.com> <1052519388.6959.5263.camel@hermes>
"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 !
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
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss