linux-mips
[Top] [All Lists]

Re: TLB mapping questions (followup q)

To: linux-mips@linux-mips.org
Subject: Re: TLB mapping questions (followup q)
From: "Erik J. Green" <erik@greendragon.org>
Date: Sun, 20 Apr 2003 04:20:00 +0000
In-reply-to: <1050809885.3ea2161d7bfc7@my.visi.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1050730370.3ea0df8263a21@my.visi.com> <20030419164854.A15699@linux-mips.org> <1050805826.3ea2064281289@my.visi.com> <1050809885.3ea2161d7bfc7@my.visi.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Internet Messaging Program (IMP) 4.0-cvs
Quoting "Erik J. Green" <erik@greendragon.org>:

> How can this work in the existing head.S for a mapped kernel?  Wouldn't other
> machines have the same problem, where the location for kernelsp is within the
> non-writeable segment?
> 


And a followup to my followup: =)

Later in the boot, in tlb-andes.c, the andes_tlb_init function re-sets CP0_wired
to 0 (and pagemask to 4k), then the local_flush_tlb_all function overwrites the
TLB entry for the kernel, causing an immediate halt to things.

Am I correct in thinking the 16M page size initally set up in head.S (with
CONFIG_MAPPED_KERNEL=1) was so the mapped kernel could get to the point of
setting up the TLB "for real" later on?  If so, how is the switch to 4k pages
supposed to work?  I can see the existing code working if local_tlb_flush_all is
running out of unmapped memory, but in my case I would think the "starter" TLB
entry would need to be preserved until a replacement is created.

Thanks again,
Erik



-- 
Erik J. Green
erik@greendragon.org

<Prev in Thread] Current Thread [Next in Thread>