address translation

address translation

[Trevor Woerner]

I want to setup a mapping so that when anything tries to read/write the
16 bytes of 0x1f0 - 0x1ff the actual physical memory that gets accessed
is 0xf7000000 - 0xf700000f.

I can't figure out what I need to call to get this done.

ioremap() is the exact opposite of what I want, and remap_page_range()
comes very close but aligns everything to the page boundary (in other
words, after I do the mapping, accessing 0x1f0 gives me 0xf70001f0
instead of 0xf7000000). I also tried using io_block_mapping(), which I
use in my platform io setup routine, but the MMU crashed with one of
those '###A' thingies. :-)

any suggestions, please?

	Trevor

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

address translation

[Trevor Woerner]

I want to setup a mapping so that when anything tries to read/write the
16 bytes at 0x1f0 - 0x1ff the actual physical memory that gets accessed
is 0xf7000000 - 0xf700000f.

I can't figure out what I need to call to get this done.

ioremap() is the exact opposite of what I want.

remap_page_range() comes very close but aligns everything to the page
boundary. In other words, after I do the mapping with either 0x1f0 or
0x0 as the virtual address, accessing 0x1f0 gives me 0xf70001f0 instead
of 0xf7000000. I don't want *page* translation, I need
*address-for-address* translation (if such a thing is possible). I
tried setting the physical address to 0xf7000000 - 0x1f0 but that
didn't work (I didn't think it would :-)

I think resetting _IO_BASE is just another page translation trick.

I also tried using io_block_mapping(), which I use in my platform io
setup routine, but the MMU crashed with one of those '###A' reports.

any suggestions, please?

        Trevor

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: address translation

[Gary Thomas]

On Thu, 2003-05-15 at 05:29, Trevor Woerner wrote:
> I want to setup a mapping so that when anything tries to read/write the
> 16 bytes at 0x1f0 - 0x1ff the actual physical memory that gets accessed
> is 0xf7000000 - 0xf700000f.
>
> I can't figure out what I need to call to get this done.
>
> ioremap() is the exact opposite of what I want.
>
> remap_page_range() comes very close but aligns everything to the page
> boundary. In other words, after I do the mapping with either 0x1f0 or
> 0x0 as the virtual address, accessing 0x1f0 gives me 0xf70001f0 instead
> of 0xf7000000. I don't want *page* translation, I need
> *address-for-address* translation (if such a thing is possible). I
> tried setting the physical address to 0xf7000000 - 0x1f0 but that
> didn't work (I didn't think it would :-)
>
> I think resetting _IO_BASE is just another page translation trick.
>
> I also tried using io_block_mapping(), which I use in my platform io
> setup routine, but the MMU crashed with one of those '###A' reports.
>

The memory management on the PowerPC does not have this capability.

I'd suggest rethinking how you are looking at this problem.
  * What is it that wants access to this specific range of physical
    memory in such a way?
Perhaps a specialized device driver would be a better choice.

--
Gary Thomas <gary@mlbassoc.com>
MLB Associates


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: address translation

[Magnus Damm]

It sounds like you have some kind of memory mapped hardware like
an IDE device or a UART that in the PC world would be accessed
with in/out instructions. These instructions are mapped to a set
of macros/inline functions on a PC running Linux.
Once upon a time (I'm not sure how it works today) Linux for PowerPC
implemented all these in/out functions/macros using memory access to
a memory area could be mapped to one ore more physical addresses.

I don't think it is possible to remap individual bytes, you have to
stick with mapping one page at a time. And I think the in/out space
is limited to 64KBytes, and that gives you a maximum of 16 devices
if you use a pagesize of 4KByte.

I think the PCMCIA layer should be pretty flexible when it comes to
allocating addresses, maybe you could have a look at that.

/ magnus

On Thu, 15 May 2003 07:29:36 -0400
Trevor Woerner <ppc339@vtnet.ca> wrote:

>
> I want to setup a mapping so that when anything tries to read/write the
> 16 bytes at 0x1f0 - 0x1ff the actual physical memory that gets accessed
> is 0xf7000000 - 0xf700000f.
>
> I can't figure out what I need to call to get this done.
>
> ioremap() is the exact opposite of what I want.
>
> remap_page_range() comes very close but aligns everything to the page
> boundary. In other words, after I do the mapping with either 0x1f0 or
> 0x0 as the virtual address, accessing 0x1f0 gives me 0xf70001f0 instead
> of 0xf7000000. I don't want *page* translation, I need
> *address-for-address* translation (if such a thing is possible). I
> tried setting the physical address to 0xf7000000 - 0x1f0 but that
> didn't work (I didn't think it would :-)
>
> I think resetting _IO_BASE is just another page translation trick.
>
> I also tried using io_block_mapping(), which I use in my platform io
> setup routine, but the MMU crashed with one of those '###A' reports.
>
> any suggestions, please?
>
>         Trevor
>
>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: address translation

[Benjamin Herrenschmidt]

On Thu, 2003-05-15 at 13:29, Trevor Woerner wrote:
> I want to setup a mapping so that when anything tries to read/write the
> 16 bytes at 0x1f0 - 0x1ff the actual physical memory that gets accessed
> is 0xf7000000 - 0xf700000f.

I would say you are taking the problem backward.

Tell us more about what you are doing. Looks like you have some IDE mapped
at 0xf7000000+. You need to tell IDE to use those. What kind of PPC CPU is
this ? IDE by default uses inx/outx accesses, which are relative to
_IO_BASE. So you just need to pass IDE some addresses that when offsetted
with _IO_BASE will fall in an ioremap'ed mapping of 0xf7000000

There is no MMU trick involved

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: address translation

[Trevor Woerner]

On May 15, 2003 07:46 am, Gary Thomas wrote:
> On Thu, 2003-05-15 at 05:29, Trevor Woerner wrote:
> > I want to setup a mapping so that when anything tries to read/write
> > the 16 bytes at 0x1f0 - 0x1ff the actual physical memory that gets
> > accessed is 0xf7000000 - 0xf700000f.
>
> Perhaps a specialized device driver would be a better choice.

Unfortunately, that seems to be the path I'm going down.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: address translation

[Trevor Woerner]

On May 15, 2003 08:13 am, Magnus Damm wrote:
> I think the PCMCIA layer should be pretty flexible when it comes to
> allocating addresses, maybe you could have a look at that.

Thanks for your tips. This last one is ironic, considering it's PCMCIA
that I'm working with! :-)

	Trevor

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: address translation

[Trevor Woerner]

On May 15, 2003 10:05 am, Benjamin Herrenschmidt wrote:
> On Thu, 2003-05-15 at 13:29, Trevor Woerner wrote:
> > I want to setup a mapping so that when anything tries to read/write
> > the 16 bytes at 0x1f0 - 0x1ff the actual physical memory that gets
> > accessed is 0xf7000000 - 0xf700000f.
>
> I would say you are taking the problem backward.

Yea, that sounds like me :-)

> Tell us more about what you are doing. Looks like you have some IDE
> mapped at 0xf7000000+. You need to tell IDE to use those. What kind
> of PPC CPU is this ?

I've got a PPC405gp-based device that has an on-board CompactFlash slot
into which CF cards can be inserted. But to save money there is no
PCMCIA controller, and the device is simply wired directly to 2 address
regions: 0xf7100000 for the attribute memory (which mostly holds config
information and the Card Information Structure (CIS) tuples) and
0xf7000000 which is where the card's ATA registers will show up (once a
card is inserted). If only it had been wired to 0xf70001f0...

The spec says these are supposed to be little endian, but I only get
meaningful data when I use big endian access (most devices on this
board appear to have been swapped in this way, e.g. RTC).

They want to be able to swap cards in and out, so I started with the
PCMCIA stuff. I've got the card detect interrupt working so inserting a
card will cause the ds.c, cs.c and all that other stuff to start
chugging along. I also twisted the cistpl.c code so it can successfully
read and parse the CIS structure.

But when it comes time to access the ATA registers I've hit a brick
wall. The default PCMCIA code keeps wanting to setup IO ranges at 0x1f0
and 0x3f6. So I've sliced out most of the configuration code from
ide-cs.c and have tried to "manually" set the ports start at 0xf000000
(0xf000000 + _IO_BASE = 0xf7000000). I don't think I've been too
successful. For one, the size of an io port is 'unsigned short' which
won't fit, so I changed that to 'unsigned int'.

This isn't a pci device, unfortunately, just straight memory-mapped. All
of the PCMCIA code expects this to be accessed using 2 IO windows with
ioremap()ping and so on. But because of the lack of wires I can only
access the device in "common-memory" mode (which the PCMCIA code isn't
setup to handle).

> IDE by default uses inx/outx accesses, which are
> relative to _IO_BASE. So you just need to pass IDE some addresses
> that when offsetted with _IO_BASE will fall in an ioremap'ed mapping
> of 0xf7000000

Ha! I spent most of the morning tracking this one down. I couldn't
figure out why, when I asked for 0xf700000, I kept getting illegal
accesses in the 0xdf000000 range (my _IO_BASE is set to 0xe8000000). So
now that I lie and ask for 0x0f000000 instead, the kernel stops
panicing :-)

> There is no MMU trick involved

Perhaps you can see why I was hopeful there was.

>From a cursory look at the ide.c code, it appears the kernel wants to
access the ATA registers one byte at a time. Unfortunately, because my
device is wired directly, I have to access it 16 bits at a time. So it
looks like I'm going to have to hack the ide.c code (or something like
it) to combine adjacent registers together before reading/writing.

Is it just me, or did the hard drive controllers of the 68k era
(drivers/ide/legacy/macide.c) have memory-mapped registers? I was
looking at their code today and it seems similar to what I'm looking
for (i think).

I can't help notice that in _2_4_devel, ide-cs.c has been moved to
drivers/ide/legacy. What is the intent here, what are we supposed to
use for cs cards?

> Ben.

p.s. are you coming to OLS again this year?

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: address translation

[Geert Uytterhoeven]

On Fri, 16 May 2003, Trevor Woerner wrote:
> >From a cursory look at the ide.c code, it appears the kernel wants to
> access the ATA registers one byte at a time. Unfortunately, because my
> device is wired directly, I have to access it 16 bits at a time. So it
> looks like I'm going to have to hack the ide.c code (or something like
> it) to combine adjacent registers together before reading/writing.

Which kernel are you using? In 2.4.21-rc2, you can easily override the
hwif->{IN,OUT}B() routines.

> Is it just me, or did the hard drive controllers of the 68k era
> (drivers/ide/legacy/macide.c) have memory-mapped registers? I was
> looking at their code today and it seems similar to what I'm looking
> for (i think).

Yes, on m68k all IDE interfaces are memory mapped (just like any other I/O).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: address translation

[Benjamin Herrenschmidt]

On Fri, 2003-05-16 at 06:02, Trevor Woerner wrote:

> But when it comes time to access the ATA registers I've hit a brick
> wall. The default PCMCIA code keeps wanting to setup IO ranges at 0x1f0
> and 0x3f6. So I've sliced out most of the configuration code from
> ide-cs.c and have tried to "manually" set the ports start at 0xf000000
> (0xf000000 + _IO_BASE = 0xf7000000). I don't think I've been too
> successful. For one, the size of an io port is 'unsigned short' which
> won't fit, so I changed that to 'unsigned int'.

What you can do is to setup different iops. Starting with 2.4.21,
the IDE layer let you change the accessor functions for a given
hwif. If you want to stick to an older kernel, you can tweak
the definition for IDE_INB etc...

Regarding address mappings, what you need is:

 - Provide a virtual mapping for f7000000. That is ioremap it
basically. The resulting virtual address will be called
ide_virt

 - Feed the IDE layer with a set of ports that start at

ide_virt - _IO_BASE

That way, when the IDE layer tries to do an inb() for example,
it will do an access to port + _IO_BASE, which will turn into
an access to port_offset + ide_virt - _IO_BASE + _IO_BASE,
that is port_offset + ide_virt, which is what you want.

> >From a cursory look at the ide.c code, it appears the kernel wants to
> access the ATA registers one byte at a time. Unfortunately, because my
> device is wired directly, I have to access it 16 bits at a time. So it
> looks like I'm going to have to hack the ide.c code (or something like
> it) to combine adjacent registers together before reading/writing.

Well. This is another issue. You basically need to redefine the
accessors IDE_INB/W etc... (or use custome iops in the hwif structure
for 2.4.21 and later kernels). Typically, you will do a 16 bits
access keeping only half of the read word for reads, or writing to
half of the 16 bits word for writes. There is nothing like accessing
2 registers at a time, registers will appear to be 16 bits each if
your bus is properly wired, it's just that IDE registers other than
the data register only contain 8 bits of useful data.

Also be careful that your HW engineers properly wired the ATA bus,
so that you don't have to byteswap the data. If this is done properly,
you will have to byteswap the control but not the data. That is
the "byte" access will work on the MSB of the 16 bits word while the
word accessors will do no byteswap. If you don't do that, then you'll
have problem with insw/outsw etc...

> Is it just me, or did the hard drive controllers of the 68k era
> (drivers/ide/legacy/macide.c) have memory-mapped registers? I was
> looking at their code today and it seems similar to what I'm looking
> for (i think).
>
> I can't help notice that in _2_4_devel, ide-cs.c has been moved to
> drivers/ide/legacy. What is the intent here, what are we supposed to
> use for cs cards?

We do mmio on powermac too. On pre 2.4.21, we did pointer tricks like
described above, on 2.4.21 and later, you can fill the hwif to use
different access functions for registers.

(look drivers/ide/ppc/pmac.c)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/