In message <20060221102327.GA1569@laiska.chello.upc.cz>, Jachym Holecek writes:
>Actually, if your startup code is close-enough to that of Walnut,
>you have all on-chip peripherals mapped in the initial TLB setup.
>Take a look at powerpc/include/ibm4xx/ibm405gp.h for (physical) base
>addresses -- now in walnut_start.S you'll see that 0xef000000
>upto 0xff000000 is mapped in. You can use opb_get_bus_space_tag()
>to get a tag for bus_space(9) to use.

Oh!

Hmm.  The design seems to imply that I still want to use bus_space_map
on that tag to get a suitable bus_space_handle for use by the
various i2c functions.  I have established that I can do this, and
it works, but I can't unmap it; I get a very strange error asserting that
a value isn't in an extent, even though it appears to be:

extent `opbtag' (0xef600300 - 0xef6012fe), flags = 0x3
     0xef600500 - 0xef60051f
extent_free: extent `opbtag', start 0x1e, size 0x20
panic: extent_free: extent `opbtag', region not within extent

>opb_get_bus_space_tag() can be called multiple times by your
>machdep code if you really need (which I don't think -- just
>reuse the one you're using for UART console).

True.

>They are constants on your core -- see 405GP user's guide.

Okay, that helps, and it seems that I can get this to come up, and even do
so without crashing.  Woo!

I am a little confused about the relationship between map and unmap.  It
seems to me that, if bus_space_map(tag, addr, ... &handle) has been called,
it's obligatory to later call bus_space_unmap(tag, handle); not because
it necessarily does anything, but simply as a matter of the interface
contract.

-s