On Mon, 2009-11-30 at 06:50 +0100, Albert Herranz wrote:

Benjamin Herrenschmidt wrote:

quoted

On Sat, 2009-11-28 at 21:43 +0100, Albert Herranz wrote:

quoted

+        * Prepare again the same BAT for MMU_init.
+        * This allows udbg I/O to continue working after the MMU is
+        * turned on for real.
+        *
+        * We are assuming here that exi_io_base is identity mapped.
+        */
+       addr = ((unsigned long)exi_io_base) & 0xffff0000;
+       setbat(1, addr, addr, 128*1024, PAGE_KERNEL_NCG); 

How do you prevent that from overlapping otherwise valid kernel
mappings ?

ug_udbg_init() is called from ppc_md.init_early.
It doesn't overlap any valid kernel mappings because exi_io_base is
hardcoded to an i/o region not used yet by the kernel.

But that doesn't allocate virtual space does it ?

See udbg_early_grab_exi_io_base().

Yeah, I see that:

+#if defined(CONFIG_GAMECUBE)
+       return (void __iomem *)0x0c006800;
+#elif defined(CONFIG_WII)
+       return (void __iomem *)0x0d006800;
+#else

So you'll have BATs floating over user addresses ? That sounds fishy :-)

It should be trivial to just create a fixmap entry instead. That will
give you a virtual address that is known at compile time (so you can
use it from head_32.S as well for setting up your BAT).

Actually you probably need more than one entry in there since it needs
to be big enough to cover a BAT min size and be aligned, but it's not
-that- hard to do (I think x86 does similar tricks in their fixmap
iirc) 

The setbat just prepares again, exactly in the same way, the same BAT that we got
setup by setup_usbgecko_bat in head_32.S.

 .../...

quoted

You need to allocate the virtual space. For a debug thing like that, you
could use the fixmap. In fact, I think we should create a fixmap entry
or two always available for use by early debug.

Or give us back ppc_md.setup_io_mappings :)

Not happening :-) Or if you get one, it will allocate virtual addresses
and so you cannot rely on an identity mapping.