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: problem in vrc437x/idt79s334a ROMRAM code





> -----Original Message-----
> From: nickg@miso.calivar.com 
> Subject: Re: [ECOS] problem in vrc437x/idt79s334a ROMRAM code
> 
> > I think what needs to happen is a two-piece copy - the exception
> > handlers from 0xbfc0_0200 down to 0x8000_0000 until end of the last
> > one, and a separate copy of the rest of the text and data segments.
> > The exception handlers currently don't reference themselves, so 
> > should be relocatable in this fashion.  Maybe also a zero-fill
> > between the end of the exception handlers and the start of .text.
> > And then copy the start of .text to __ram_data_end.
> 
> 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 :-) )

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.

Both of the copy loops could be optimized a little more - the lw/sw pair
will stall the pipe for a cycle, so one of the adds should be moved in
between the lw and sw.  The hal_memc_init loop should use the branch
delay
slot.

> > 
> > As a related problem for the ROMRAM configurations, it looks like
> > SR[BEV] is cleared in hal_cpu_init based on the value of INITIAL_SR
> > well before the actual exception handlers are copied down into RAM
> > in hal_memc_init.
> 
> Since we don't expect to get any exceptions or interrupts while we are
> running the initialization code this should not matter. 
>

For the systems we work on I like to have this support, because
sometimes
the production code also has to serve as the code that tests the h/w.
If I can blink an LED on a bus error or do something to show the board
is alive, then less bad boards get put in the "completely dead" pile.
Boards in that pile often get returned to engineering for
troubleshooting :-(

 
> > 
> > One more problem looks to be missing handlers for some exceptions:
> > It looks like xtlb and the cache exceptions present on some 
> mips cores
> > are ignored.  There is no code at those vector locations, 
> but the linker
> > will fill with 0x00000000 which is a NOP and it should fall 
> through to
> > whatever is next unless the exception vector is greater than base +
> > 0x180.
> 
> Certainly if there is any expectation that any of these exceptions
> will be used, there should be a vector installed. Most of them are
> things that eCos apps would never provoke.
> 

I would agree that well mannered apps should never provoke some of these
exceptions, but I think it's prudent to have handler code installed on
every vector that could possibly happen, because not everything is under
the apps control.



--
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]