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


"Andy Dyer" <adyer@righthandtech.com> writes:

> 
> So I think the code above is copying the reset vector down to
> where the TLB refill vector should be and the TLB vector is at
> 0x8000_0100.  The most common exception (interrupts) value seems
> to be different from the RAM-only version to munge it to 0x8000_0180
> like it should be.
> 
> 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.

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

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

> 
> Does this make sense or am I missing something???  I would be willing to
> make a patch for tx49 to fix this stuff, but I don't have IDT or Vr4300
> based systems to try it out on others.

Just fixing the utlb vector is probably the smallest change, and it is
something that can be copied over from the vrc437x HAL. But if you
want to do something else for the TX49 it will be considered.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


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