APUS and IOs question

APUS and IOs question

[Benjamin Herrenschmidt]

Somebody who understands APUS around ?

In include/asm-ppc/io.h, we have a special definition of the PCI IO
accessors readw,writew,readl and writel for APUS that don't do byteswap
and also don't do barriers.

This seems very bogus to me. Can somebody explain me why it's done that
way so I can then explain why it's broken ? :-)

I will remove those definitions soon, so unless I get a very convincing
argument of why it has to be done that way on APUS, things might break
(APUS-specific drivers relying on those not swapping will have to be
fixed).

Ben.

Re: APUS and IOs question

[Simon Richter]

Hi,

Benjamin Herrenschmidt wrote:

> Somebody who understands APUS around ?

I have one, but I don't understand all of it. :-)

> In include/asm-ppc/io.h, we have a special definition of the PCI IO
> accessors readw,writew,readl and writel for APUS that don't do byteswap
> and also don't do barriers.

APUS PCI is weird, to say the least. The PCI extension is basically
built to accomodate a single PCI device, which happens to be a Permedia2
graphics chip that allows byte-swapped mappings of both register and
framebuffer space and is never told to do DMA because nobody knows what
kind of interesting effects that would have, so the only synchronisation
that is needed is between accesses to the framebuffer and the GPU.

That, and that the 604e+ probably doesn't reorder accesses that much
anyway that the barriers would do any good here. :-)

   Simon

Re: APUS and IOs question

[Segher Boessenkool]

> That, and that the 604e+ probably doesn't reorder accesses that much
> anyway that the barriers would do any good here. :-)

Is there any reason though to have APUS-specific I/O accessors
instead of using the generic stuff (except for perhaps a minor
performance hit)?


Segher

Re: APUS and IOs question

[Benjamin Herrenschmidt]

On Mon, 2006-11-06 at 16:18 +0100, Simon Richter wrote:
> Hi,
> 
> Benjamin Herrenschmidt wrote:
> 
> > Somebody who understands APUS around ?
> 
> I have one, but I don't understand all of it. :-)
> 
> > In include/asm-ppc/io.h, we have a special definition of the PCI IO
> > accessors readw,writew,readl and writel for APUS that don't do byteswap
> > and also don't do barriers.
> 
> APUS PCI is weird, to say the least. The PCI extension is basically
> built to accomodate a single PCI device, which happens to be a Permedia2
> graphics chip that allows byte-swapped mappings of both register and
> framebuffer space and is never told to do DMA because nobody knows what
> kind of interesting effects that would have, so the only synchronisation
> that is needed is between accesses to the framebuffer and the GPU.
> 
> That, and that the 604e+ probably doesn't reorder accesses that much
> anyway that the barriers would do any good here. :-)

Still, it annoys me to have an  APUS-specific definition of accessors
that would otherwise be common to everybody...

Anyway, I decided not to change asm-ppc/io.h, so this will only become
an issue if we ever move APUS over to arch/powerpc

Ben.

Re: APUS and IOs question

[Simon Richter]

Hi,

Benjamin Herrenschmidt schrieb:

> Can you give me a proper explanation of the whole memory map story on it
> so I get a better idea of how invasive handling it would be ?

On APUS systems, you have two (major) kinds of memory, that on the Amiga
board and that on the CPU board. The former is generally mapped at
address zero, but you don't want to use it except as DMA buffers when
talking to the internal hardware (because the internal hardware doesn't
see the memory on the CPU board).

The memory on the CPU board is the "main" memory for Linux (because
there is more of it, and the access is faster), but its location is
assigned dynamically during the boot process, and depends on the size of
the memory and on other boards installed.

My plan for moving APUS to arch/powerpc involves writing a new
bootloader (I'm currently hacking binutils to support AmigaOS binaries)
that builds a proper flattened device tree and calls the kernel, but I'm
not sure where the kernel virtual mapping that allows the kernel to run
from a fixed address should be set up -- if in the bootloader, the
kernel needs to be aware that changing the MMU settings will yield
interesting results, and if in the kernel, we need some platform
specific init code to handle that.

   Simon

Re: APUS and IOs question

[Benjamin Herrenschmidt]

> My plan for moving APUS to arch/powerpc involves writing a new
> bootloader (I'm currently hacking binutils to support AmigaOS binaries)
> that builds a proper flattened device tree and calls the kernel, but I'm
> not sure where the kernel virtual mapping that allows the kernel to run
> from a fixed address should be set up -- if in the bootloader, the
> kernel needs to be aware that changing the MMU settings will yield
> interesting results, and if in the kernel, we need some platform
> specific init code to handle that.

Well, the problem is that you basially have to hack the linear mapping,
thus hitting anything that relies on __pa/__va or operating in real mode
indeed.

How do you do for exception vectors ? Since those have to be either at 0
or at ff* ? You stick branches at 0 to jump to where the kernel
resides ?

Ben.

Re: APUS and IOs question

[Geert Uytterhoeven]

On Fri, 10 Nov 2006, Benjamin Herrenschmidt wrote:
> > My plan for moving APUS to arch/powerpc involves writing a new
> > bootloader (I'm currently hacking binutils to support AmigaOS binaries)
> > that builds a proper flattened device tree and calls the kernel, but I'm
> > not sure where the kernel virtual mapping that allows the kernel to run
> > from a fixed address should be set up -- if in the bootloader, the
> > kernel needs to be aware that changing the MMU settings will yield
> > interesting results, and if in the kernel, we need some platform
> > specific init code to handle that.
> 
> Well, the problem is that you basially have to hack the linear mapping,
> thus hitting anything that relies on __pa/__va or operating in real mode
> indeed.
> 
> How do you do for exception vectors ? Since those have to be either at 0
> or at ff* ? You stick branches at 0 to jump to where the kernel
> resides ?

IIRC (Roman please correct me if I'm wrong), APUS has them at ff* because the
memory at adress 0 is slower.

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

Re: APUS and IOs question

[Roman Zippel]

Hi,

On Fri, 10 Nov 2006, Geert Uytterhoeven wrote:

> On Fri, 10 Nov 2006, Benjamin Herrenschmidt wrote:
> > > My plan for moving APUS to arch/powerpc involves writing a new
> > > bootloader (I'm currently hacking binutils to support AmigaOS binaries)
> > > that builds a proper flattened device tree and calls the kernel, but I'm
> > > not sure where the kernel virtual mapping that allows the kernel to run
> > > from a fixed address should be set up -- if in the bootloader, the
> > > kernel needs to be aware that changing the MMU settings will yield
> > > interesting results, and if in the kernel, we need some platform
> > > specific init code to handle that.
> > 
> > Well, the problem is that you basially have to hack the linear mapping,
> > thus hitting anything that relies on __pa/__va or operating in real mode
> > indeed.
> > 
> > How do you do for exception vectors ? Since those have to be either at 0
> > or at ff* ? You stick branches at 0 to jump to where the kernel
> > resides ?
> 
> IIRC (Roman please correct me if I'm wrong), APUS has them at ff* because the
> memory at adress 0 is slower.

Earlier APUS did put the exception vectors at 0, which is slow of course. 
The hardware maps part of the local memory to ff, so the exception vectors 
are copied there and the transfer handler jump to the mapped location.

bye, Roman