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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox