From: Jon Masters <jonmasters@gmail.com>
To: "P. Sadik" <psadik@gmail.com>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Address mapping PPC 405
Date: Sun, 28 Aug 2005 16:15:38 +0100 [thread overview]
Message-ID: <35fb2e5905082808152031ef53@mail.gmail.com> (raw)
In-Reply-To: <ea43f4f9050825183121655ba2@mail.gmail.com>
On 8/26/05, P. Sadik <psadik@gmail.com> wrote:
> I have a question on how PPC addressing works. I am familiar with
> the MIPS architecture and new to PPC.
Hello!
> On MIPS, there are KUSEG (0x0000_0000 to 0x07FF_FFFF)
> which is always translated using TLB. Then there are two
> un-translated areas KSEG0 (0x8000_0000 which is cached)
> and KSEG1 (0xA000_0000).
Lovely. We don't do it that way on 405 but we could - since the MMU is
heavy soft assisted we could do that - we actually have everything run
through the MMU once we've done initial MMU setup, but we do have the
ability to mark ranges of addresses for IO and have the concept of TLB
pinning to lock ranges of kernel addresses in large translated (BAT
like for bigger PPC users) regions using just a few TLB slots. There
is also a ZPR (zone protection register), but that's mostly used to
fake the usual USER/KERNEL page distinction.
> On PPC I see that, the kernel .text is at 0xC000_0000. Is it a
> translated address? If it is, for running kernel code, the CPU has to
> consult the TLB always?
It's translated except during early setup and on certain exceptions -
but everything else you will do in the kernel sees virtual addresses.
> Another question is regarding addressing local peripherals. I am using
> an ML310 board from Xilinx
That I guessed. Partly since Peter had already replied, but also
because that's a large chunk of ppc405 users currently working on new
designs. Please bear in mind that only a few of us are aware of the
issues below.
> and it has DDR mapped to 0x0000_0000
> to 0x0FFF_FFFF (256 MB). Now, I need to add an IP to the PLB.
> For that, I am thinking of using 0x2000_0000 to 0x2000_0FFF.
> Now, my driver need to access the registers within the above region.
> How will I do that? It is an I/O, hence should I use ioremap, or can
> I access it directly? What role cache will play in this case?
You'll need to do an ioremap to get at that physical address from the
kernel, then use the returned virtual address to access your
peripheral. You should always use the appropriate read function rather
than doing a stw and an eieio and you probably want to make sure your
bootloader also has setup the right ZPR/etc. if you want to write to
that before Linux.
> The third question is, can I use de-referencing of address. Is it O.K
> to use pointers to access the registers, or do I have to use read/write
> variants?
You /can/ use a deference if you're setup that region as an IO remap
but why bother? That said, we've probably all done it and it does work
- that is your call.
> I would appreciate a lot if you could give some insight into this. Any
> pointers or reading materials will be very helpful.
Feel free to email. I've done a bunch of ml<insert number> projects
and I'm coming up on a ML403 when I get around to buying one for home
:-)
Jon.
P.S. I've been quiet on this list for a while, standard moving and
conference season combo.
next prev parent reply other threads:[~2005-08-28 15:22 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-26 1:31 Address mapping PPC 405 P. Sadik
2005-08-26 3:10 ` Grant Likely
2005-08-26 22:47 ` Peter Ryser
2005-08-28 15:15 ` Jon Masters [this message]
2005-08-29 0:26 ` Grant Likely
2005-08-29 1:11 ` Jon Masters
2005-08-30 15:38 ` Matt Porter
2005-09-15 16:03 ` PPC4xx cleanup Stefan Roese
2005-09-15 16:25 ` Matt Porter
2005-09-15 19:03 ` Dan Malek
2005-09-19 14:08 ` Matt Porter
2005-09-16 11:06 ` [PATCH] ppc32: cleanup AMCC PPC4xx eval boards to better support U-Boot Stefan Roese
2005-09-16 16:27 ` Eugene Surovegin
2005-09-19 11:02 ` Stefan Roese
2005-09-19 13:59 ` Matt Porter
2005-09-19 15:06 ` Stefan Roese
2005-09-19 15:21 ` Matt Porter
2005-09-19 17:14 ` Eugene Surovegin
2005-11-22 17:34 ` [PATCH] ppc32: Add P3P440 (440GP) board support Stefan Roese
2005-09-19 11:20 ` [PATCH] ppc32: cleanup AMCC PPC44x eval boards to better support U-Boot Stefan Roese
2005-09-30 12:52 ` [PATCH] ppc32: cleanup AMCC PPC40x eval boards to " Stefan Roese
2005-10-28 15:58 ` [PATCH] ppc32: Remove internal PCI arbiter check on PPC40x Stefan Roese
2005-10-31 9:29 ` [PATCH] ppc32: Add missing initrd header on ppc440 Stefan Roese
2005-10-31 14:41 ` Matt Porter
2005-08-30 15:09 ` Address mapping PPC 405 Matt Porter
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=35fb2e5905082808152031ef53@mail.gmail.com \
--to=jonmasters@gmail.com \
--cc=jonathan@jonmasters.org \
--cc=linuxppc-embedded@ozlabs.org \
--cc=psadik@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).