Subject: Re: -pmap initlialization
To: None <email@example.com>
From: Chris Gilbert <firstname.lastname@example.org>
Date: 01/07/2005 11:10:55
On Fri, 7 Jan 2005 02:52:21 -0800 (PST)
"Kamal R. Prasad" <email@example.com> wrote:
> --- Richard Earnshaw <firstname.lastname@example.org> wrote:
> > 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.