[ECOS] RE : [ECOS] RedBoot crash after do_go()

[nprasad3 at gmu dot edu]

Best guess would be to check the individual MSR bits that change.
----- Original Message -----
From: David POUTY <david.pouty@com2gether.net>
Date: Friday, January 9, 2004 4:28 am
Subject: [ECOS] RE : [ECOS] RE : [ECOS] RedBoot crash after do_go()

> Nirmal,
> 
> I made the test with MMU and caches disabled, but nothing change !
> I don't understand why there are several address content change 
> after a
> 'sync' instruction if caches are really disabled ?
> 
> David
> 
> -----Message d'origine-----
> De : nprasad3@gmu.edu [mailto:nprasad3@gmu.edu] 
> Envoyé : jeudi 8 janvier 2004 18:44
> À : David POUTY
> Cc : 'Gary Thomas'; 'eCos Discussion'
> Objet : Re: [ECOS] RE : [ECOS] RedBoot crash after do_go()
> 
> 
> David,
> 
> I had the same problem initially but that was because MMU was being
> enabled. You might not have the proper settings for the MMU or may 
> wantto try by disabling MMU totally.
> 
> Nirmal
> 
> 
> ----- Original Message -----
> From: David POUTY <david.pouty@com2gether.net>
> Date: Thursday, January 8, 2004 11:54 am
> Subject: [ECOS] RE : [ECOS] RedBoot crash after do_go()
> 
> > The program works also well with GDB.
> > I don't understand your explanation about the cache flush code ! I
> > thinkalso there's a problem with cache but I not familiar with it.
> > 
> > The stack is corrupt when 'sync' is executed, just after the 
> 'mtmsr' 
> > instruction with the bit EE set.
> > 
> > David
> > 
> > 
> > -----Message d'origine-----
> > De : Gary Thomas [mailto:gary@mlbassoc.com]
> > Envoyé : mercredi 7 janvier 2004 18:38
> > À : David POUTY
> > Cc : eCos Discussion
> > Objet : Re: [ECOS] RedBoot crash after do_go()
> > 
> > 
> > On Wed, 2004-01-07 at 10:32, David POUTY wrote:
> > > Hi,
> > > 
> > > I try to execute a simple application from RedBoot (MPC8xx
> > plateform).
> > > When application is finished RedBoot display exit code, then
> > crash
> > > (enter in GDB mode). It seems that the stack is corrupted BEFORE
> > the
> > > application is executed.
> > > 
> > > During function hal_thread_load_context(), the macro
> > > 'hal_cpu_int_merge' is called to merge MSR register value with 
> > the
> > > thread context previously initialized (HAL_THREAD_INT_CONTEXT).
> > The
> > > thread MSR value contains MSR_EE (to external enable irqs).
> > > 
> > > The stack is corrupted when MSR_EE bit is set to MSR in
> > > 'hal_cpu_int_merge' !! I use GDB with BDI probe. There's no 
> > interrupt
> > > pending (SIPEND=0).
> > 
> > What happens if you execute the program via GDB, instead of RedBoot?
> > 
> > One thing to try (no guarantees) would be to disable the cache 
> flush 
> > code that's in mbx.S (only when CYG_HAL_STARTUP_RAM is defined). 
> Look
> 
> > at how it's done on a newer platform, like the adder.
> > 
> > --
> > Gary Thomas <gary@mlbassoc.com>
> > MLB Associates
> > 
> > 
> > --
> > Before posting, please read the FAQ: 
> > http://sources.redhat.com/fom/ecosand search the list archive: 
> > http://sources.redhat.com/ml/ecos-discuss
> > 
> > 
> > 
> 
> 
> -- 
> Before posting, please read the FAQ: 
> http://sources.redhat.com/fom/ecosand 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