I found out the problem. It was a result of difference
in address range for I/O peripherals between lubbock
and my vendor-specific board. There is at least one
invalid comment in lubbock_machdep.c
----------------------------------------------
         * The first level page table is at
0xa0004000.  There are also
         * 2 second-level tables at 0xa0008000 and
0xa0008400.
--------------------------------------
The first level page table is at 0xa01fc000 (just 16K
short of where the kernel is loaded aka 0xa0200000). 

I may have some suggestions on improving the code
-depending on how interested the powers-that-be are in
checking in my suggestions.

regards
-kamal
 
--- Richard Earnshaw <rearnsha@netbsd.org> wrote:

> On Fri, 2005-01-07 at 10:52, Kamal R. Prasad wrote:
> 
> > Can we trap the instructions that execute
> > after a tlb has been invalidated? 
> 
> Not within the core, since that would need valid TLB
> entries to do
> further processing (catch-22).
> 
> > Why won't the
> > processor throw an exception if it reads invalid
> data
> > in the L1 cache? Im stuck in the sense there is no
> > debug mechanism for me to find out why its
> hanging.
> > Can I insert some code to be executed after the
> > translation buffer has been invalidated
> (irrespective
> > of its contents)?
> 
> If you've got access to an embedded trace box (eg
> multi-trace, or
> RV-trace from arm --- there are probably other
> devices from elsewhere)
> then you can stop the core and download an accurate
> log of what it is
> trying to do.  It might (or might not, no guarantees
> here) tell you at
> what point it is failing.
> 
> R.
> 



	
		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail