This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: problem in vrc437x/idt79s334a ROMRAM code
- From: "Andy Dyer" <adyer at righthandtech dot com>
- To: "Nick Garnett" <nickg at ecoscentric dot com>
- Cc: <ecos-discuss at sources dot redhat dot com>
- Date: Sat, 23 Aug 2003 19:30:07 -0500
- Subject: RE: [ECOS] problem in vrc437x/idt79s334a ROMRAM code
> -----Original Message-----
> From: Andy Dyer
> Sent: Saturday, August 23, 2003 8:35 AM
> To: 'Nick Garnett'
> Cc: 'ecos-discuss@sources.redhat.com'
> Subject: RE:
> >
> > In the vrc437x HAL we just copy the utlb refill vector into
> place once
> > we have copied the entire ROM down into RAM. This is done in the
> > hal_mon_copy_trampoline macro, which is part of hal_mon_init in
> > platform.inc. Does this not fix the problem? The REF4955 and
> > idt79s334a platforms do not seem to have this code. So
> maybe it should
> > be added.
> >
>
> I missed that little snippet - although looking at the code I have it
> only does the other_vector, not the utlb handler and other vectors.
> Since the tlb handler catches null pointer references, it's important
> to have around (at least for my code :-) )
looking again I see the UTLB handler stuff - disregard this comment.
> I notice in the hal_mon_copy_trampoline macro the code is
> copying to the
> uncached area, but in the previous copy loop in hal_memc_init the code
> copies to a cached area. Thinking about it there is the potential for
> cache coherency issues in the hal_memc_init code between the
> d-cache and
> the i-cache. The code in hal_memc_init should probably at least flush
> the d-cache and maybe invalidate the i-cache before jumping into the
> copied code.
>
>
Staring at this a bit more it looks like the ROMRAM hal_memc_init
code including the copy loop using cached addresses is run before
hal_cache_init (see hal/mips/arch/current/src/vectors.S).
I seem to remember some R4/5xxx cache init code that wanted to zero
the first 64k of memory (something about generating good parity?),
so it would seem to me a good idea to postpone the copy operation
until after cache init is done.
I hope it doesn't seem that I'm harping on this stuff, I'm just trying
to understand what's going on and make it work for my target.
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss