Subject: Re: -pmap initlialization
To: None <>
From: Chris Gilbert <>
List: port-arm
Date: 01/07/2005 11:10:55
On Fri, 7 Jan 2005 02:52:21 -0800 (PST)
"Kamal R. Prasad" <> wrote:

> --- Richard Earnshaw <> wrote:
> [snip]
> > 
> > One more thought.
> > 
> > Your PC is set to the correct kernel VA by the time
> > you enter initarm() 
> > isn't it?  That is, you have set up a preliminary
> > page table mapping in 
> > your bootstrap code and done an appropriate jump
> > (not pc-relative) to VA 
> > addresses.  One way to tell would be to pass
> > __builtin_return_address(0) 
> > to printf.  The value must be in KVA space not
> > physical space.  If it 
> > isn't then you'll die when you switch to the real
> > page tables.
> > 
> > R.
> It is in the virtual address space and is 0xc0200094
> I believe the L1 table has been setup correctly my
> pmap_map_chunk() which prints to the console on
> bootup. When we switch to the L1 table, it seems to go
> for a toss. Can we trap the instructions that execute
> after a tlb has been invalidated? 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)?

Are you running with the right domain?  When we started to use domains for pmap I found that some boot loaders (ABLE on cats) also setup domains, so I to do the first tlb flush I needed to do:
        /* be a client to all domains */
        cpu_domains(DOMAIN_CLIENT << (PMAP_DOMAIN_KERNEL*2));

So that when the tlb comes in we're able to access it, otherwise it just locks up.  Without being a client of all domains we end up locked up before the tlb change as the bootloader used a different domain.