From: "Erik J. Green" <erik@greendragon.org>
To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: TLB mapping questions (followup q)
Date: Sun, 20 Apr 2003 03:38:05 +0000 [thread overview]
Message-ID: <1050809885.3ea2161d7bfc7@my.visi.com> (raw)
In-Reply-To: <1050805826.3ea2064281289@my.visi.com>
Quoting "Erik J. Green" <erik@greendragon.org>:
>
> That's ok for the first page, it's code only. The second page mapped by the
> entry is data, so I'll set the D bit on that.
A followup question: my stack is working now that I've set the D flag in the
TLB entry, allowing writes to that page. From what I can tell, the
MAPPED_KERNEL_SETUP_TLB macro in head.S actually creates two nearly identical
halves for the new TLB entry it creates, except the half in ENTRYLO1 has the D
bit set. My problem with the stack code was that the address the stack pointer
was being saved to (ok, really more of an addressing problem than a stack
problem) was within that first (16MB) page of memory, which couldn't be written
until I set the D bit.
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?
Erik
PS: Code from the current (few days old CVS) head.S:
.macro MAPPED_KERNEL_SETUP_TLB
#ifdef CONFIG_MAPPED_KERNEL
/*
* This needs to read the nasid - assume 0 for now.
* Drop in 0xffffffffc0000000 in tlbhi, 0+VG in tlblo_0,
* 0+DVG in tlblo_1.
*/
dli t0, 0xffffffffc0000000
dmtc0 t0, CP0_ENTRYHI
li t0, 0x1c000 # Offset of text into node memory
dsll t1, NASID_SHFT # Shift text nasid into place
dsll t2, NASID_SHFT # Same for data nasid
or t1, t1, t0 # Physical load address of kernel text
or t2, t2, t0 # Physical load address of kernel data
dsrl t1, 12 # 4K pfn
dsrl t2, 12 # 4K pfn
dsll t1, 6 # Get pfn into place
dsll t2, 6 # Get pfn into place
li t0, ((_PAGE_GLOBAL|_PAGE_VALID| _CACHE_CACHABLE_COW) >> 6)
or t0, t0, t1
mtc0 t0, CP0_ENTRYLO0 # physaddr, VG, cach exlwr
li t0, ((_PAGE_GLOBAL|_PAGE_VALID| _PAGE_DIRTY|_CACHE_CACHABLE_COW)
>> 6)
or t0, t0, t2
mtc0 t0, CP0_ENTRYLO1 # physaddr, DVG, cach exlwr
li t0, 0x1ffe000 # MAPPED_KERN_TLBMASK, TLBPGMASK_16M
mtc0 t0, CP0_PAGEMASK
li t0, 0 # KMAP_INX
mtc0 t0, CP0_INDEX
li t0, 1
mtc0 t0, CP0_WIRED
tlbwi
#else
mtc0 zero, CP0_WIRED
#endif
.endm
--
Erik J. Green
erik@greendragon.org
next prev parent reply other threads:[~2003-04-20 3:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-19 5:32 TLB mapping questions Erik J. Green
2003-04-19 14:48 ` Ralf Baechle
2003-04-20 2:30 ` Erik J. Green
2003-04-20 3:38 ` Erik J. Green [this message]
2003-04-20 4:20 ` TLB mapping questions (followup q) Erik J. Green
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1050809885.3ea2161d7bfc7@my.visi.com \
--to=erik@greendragon.org \
--cc=linux-mips@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.