Hello,
I have a question on how PPC addressing works. I am familiar with
the MIPS architecture and new to PPC.
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).
Hence, the kernel is compiled with .text at 0x8000_0000. For kernel
itself, the TLB is never consulted. All the local peripherals will be mappe=
d to=20
0xA000_0000. That means, from kernel, if I have to access a register of any=
=20
peripheral, I can use the un-mapped address and everything will work.
On PPC I see that, the kernel .text is at 0xC000_0000. Is it a=20
translated address? If it is, for running kernel code, the CPU has to
consult the TLB always?
Another question is regarding addressing local peripherals. I am using
an ML310 board from Xilinx 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?
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?=20
I would appreciate a lot if you could give some insight into this. Any
pointers or reading materials will be very helpful.
Thanks and regards,
Sadik.
From: Grant Likely <hidden> Date: 2005-08-26 03:14:40
On Thu, Aug 25, 2005 at 06:31:22PM -0700, P. Sadik wrote:
Hello,
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?
Typically, PPC systems have RAM based at physical address 0 which is
mapped up to 0xc0000000. Once the MMU is turned on the TLB is consulted
for every memory access.
Another question is regarding addressing local peripherals. I am using
an ML310 board from Xilinx 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 can put your peripherals anywhere within the address space as long
as they don't conflict with each other. You must add a page mapping for
each peripheral because once the MMU is turned on you can no longer
access physical addresses directly. I believe ioremap is the correct
facility to do this.
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?
Since there is no seperate IO memory space you can access the registers
with simple pointers.
Whether or not it is a good idea (based on coding conventions) I'll
leave for someone else to answer. :)
I would appreciate a lot if you could give some insight into this. Any
pointers or reading materials will be very helpful.
Keep me updated on your progress. I'm working on the ML300 and a couple
of the MEMEC boards to make v2pro support more flexible in 2.6.x, and
I'd like to hear about your experiences.
Cheers,
g.
From: Peter Ryser <hidden> Date: 2005-08-26 22:48:40
Since there is no seperate IO memory space you can access the registers
with simple pointers.
Whether or not it is a good idea (based on coding conventions) I'll
leave for someone else to answer. :)
You want to use the read{b,w,l} and write{b,w,l} macros for two reasons:
1. Accesses to registers need to be synch'ed with 'eieio' or some other
synchronizing instructions.
2. Portability of your driver if you ever should ever move it to a
different architecture and/or change the endianness in your system
- Peter
From: Jon Masters <hidden> Date: 2005-08-28 15:22:12
On 8/26/05, P. Sadik [off-list ref] 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.
From: Grant Likely <hidden> Date: 2005-08-29 00:26:07
On 8/28/05, Jon Masters [off-list ref] wrote:
On 8/26/05, P. Sadik [off-list ref] wrote:
=20
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.
I believe TLB pinning was removed in 2.6 in favor of large TLB entries
for kernel space. Matt Porter pointed this out to me about a week
ago. This will not matter of course if you're not using 2.6.
Matt, is there any documentation covering the new design in the kernel tree=
?
Cheers,
g.
From: Jon Masters <hidden> Date: 2005-08-29 01:31:20
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grant Likely wrote:
| On 8/28/05, Jon Masters [off-list ref] wrote:
|
|>On 8/26/05, P. Sadik [off-list ref] wrote:
|>
|>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.
| I believe TLB pinning was removed in 2.6 in favor of large TLB entries
| for kernel space. Matt Porter pointed this out to me about a week
| ago. This will not matter of course if you're not using 2.6.
Maybe so. I'm thinking this is likely on 2.4 but I'd be interested to
know what you mean - this isn't hugetlb (that's different), and TLB
pinning on 2.4 means you only use a couple of (large) entries anyway. I
can go read the source I suppose :-)
| Matt, is there any documentation covering the new design in the kernel
tree?
Hmmm...doc-u-what? :P
Jon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDEmC6eTyyexZHHxERAknhAJsHFukzIvJc/GEpI6KT6VFjTm6zTgCeMlht
0jiMOVsht7kOGY2aIsnSObs=
=Uuxh
-----END PGP SIGNATURE-----