First of all, let me apologize for multiple posts -it
happened inadverently.
The hang happens in
sys/arch/arm/arm/cpufunc_asm_xscale.S in
xscale_setttb() which sets the MMU TLB base address
register. The address is 0xa01fc000. Is this the right
address? Does the datasheet mention a phys addr for
the TLB base addr?

--- Toru Nishimura <locore64@alkyltechnology.com>
wrote:

> Kamal R. Prasad asked;
> 
> > I found out that as soon as tlb is invalidated,
> the
> > system goes for a toss. Does the configuration
> below
> > look OK? The kernel is loaded at 0xa0200000 and
> the L1
> > page table is at 0xa01fc000.
> > Other than an incorrect base addr for the page
> table,
> > what else could cause the system to go for a toss?
> 
> - xxx_machdep.c of any evbarm allocates some pmap
> structure
> for kernel address below 2MB range.  PLS take a
> close look at
> #define alloc_pages in the middle of initarm().
> 
looks fine to me. I just copied xxx_machdep.c over
from lubbock subdir. The GPIO base addr and size
changes for the triton sub-type(meaning the addresses
change but the algo remains the same), but physical
memory specs(SDRAM Bank 0) remain the same.

> - The following debug message implicates your data
> segment
> base is va=0xc030d000.  PLS check objdump --headers
> result to
> see it makes sense.
> 
Yeah -(IMHO) it is correct. The kernel is loaded from
0xa0200000 and the KVA address corresponding to it is
0xc0200000, which means the data segment KVA is >
0xc0200000.

> > pmap_map_chunk: pa=0xa0200000 va=0xc0200000
> > size=0x10d000 resid=0x10d000 prot=01
> > SPPPPPPPPPPPPP
> > pmap_map_chunk: pa=0xa030d000 va=0xc030d000
> > size=0x3d000 resid=0x3d000 prot=0x31
> > PPPLLLPPPPPPPPPP
> 
> Toru Nishimura/ALKYL Technology
> 
> 

thanks
-kamal



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com