From: "Erik J. Green" <erik@greendragon.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: TLB mapping questions
Date: Sun, 20 Apr 2003 02:30:26 +0000 [thread overview]
Message-ID: <1050805826.3ea2064281289@my.visi.com> (raw)
In-Reply-To: <20030419164854.A15699@linux-mips.org>
Quoting Ralf Baechle <ralf@linux-mips.org>:TLB_SE
> > So if I construct a TLB entry such that cp0_entryhi is 0xffffffffc0002000,
> and
> > cp0_entrylo0 has a PFN address of 0x0000000020006, giving it the correct
> ASID
> > (0) and valid bitflags(VG), I should be able to access the physical memory
> > offset above using the ckseg2 virtual address 0xffffffffc0002000?
>
> You also want to set the dirty flag or otherwise the page is not writable.
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.
>
> Which page size have you been using?
16 megabyte
>
> The physical address must be a multiple of the page size of the page and
> the virtual address must be a multiple of the double of the page size of
> entry - remember that each TLB entry maps a pair of adjacent pages!
This was my main problem - after I rounded my physical load address up to the
next 16M boundary: 0xa800000021000000 and adjusted the LOADADDRESS in my
makefile to point to the beginning of ckseg2 (the address of which is a multiple
of 32M) I am now able to jump into the ckseg2 code successfully.
> The entrylo value is computed by shifting the physical address right by
> 6 bits then inserting the right flag bits into the low 6 bits. In your
> case you want to set the valid, dirty and global bits. You also need to
> set the 3 coherency bits. We want cachable coherent, the same mode as
> used in the 0xa8... portion of XKPHYS. So we set them to 5. So:
>
> c0_entrylo0 = (phyaddr >> 6) | cacheable_coherent | dirty | valid | global
>
> c0_entrylo0 = 0x800180 | 0x28 | 0x4 | 0x2 | 0x1
>
> c0_entrylo0 = 0x8001af
These are the very bits I'm using. I'm actually using a modded version of the
MAPPED_KERNEL_SETUP_TLB macro in head.S.
> An extra word about the global bit - there exists only one global bit in
I made a note of this paragraph, will do some reading on it.
> would generated the mapping and make sure the entry won't be overwritten
> by random TLB writes.
Yes, CP0_WIRED is getting set to 1 to protect this entry.
>
> > Of course, the reason I discuss all this is that the above doesn't work. =)
>
> Every Linux port has started in a state as advanced as where you are so
> keep up :-)
I will do so =) My next problem is getting the stack working.
Erik
>
> Ralf
--
Erik J. Green
erik@greendragon.org
next prev parent reply other threads:[~2003-04-20 2:30 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 [this message]
2003-04-20 3:38 ` TLB mapping questions (followup q) Erik J. Green
2003-04-20 4:20 ` 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=1050805826.3ea2064281289@my.visi.com \
--to=erik@greendragon.org \
--cc=linux-mips@linux-mips.org \
--cc=ralf@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