Re: use of BAT before taking over the MMU

[Albert Cahalan <acahalan@gmail.com>]

On Tue, Oct 5, 2010 at 11:31 AM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:

> An OS shouldn't expect to have more than its own program image
> RAM mapped, in general.

Linux actually makes calls to allocate more. I'm thankful
that Linux always specifies an address, so I was able to
get away with simply returning success. I wonder how this
works for a firmware implementation that resides in RAM,
using the memory that Linux demands. Must the firmware
move itself out of the way?

>> Of course that faults immediately, so I have a handler that
>> loads IBAT0 with a 128 KiB mapping. I treat the BAT like a
>> direct-mapped software-loaded TLB. (like MIPS arch MMU)
>
> Just map the first 256MB and don't worry about anything else?
> Seems a lot simpler to me ;-)

I was expecting that Linux would demand plenty of mappings,
including small ones and ones for IO. I was preparing myself
for that.

>> Note that Linux can fail even with a firmware that doesn't touch
>> the BAT registers. The MMU is on,
>
> You can boot Linux with the MMU off as well.

That wasn't obvious for the prom_init path. IEEE docs seemed
to suggest that the firmware must provide MMU handling.

>> and 0xc0000000 may be
>> where the firmware expects to have... MMIO for the console,
>> the client interface entry point, a forth stack, whatever.
>> The BAT takes priority, and thus the firmware splatters stuff
>> right onto the kernel or dies trying to read something it left there.
>
> Like I said, you're supposed to swap OS BATs with firmware BATs
> in your client interface entry and exit. =A0You have to switch
> a lot of other registers there as well already, so that's no
> big deal.

Well no. This isn't real hardware. My prom entry point looks
something like this:

eciwx r0,r0,r0
blr

My ISI and DSI handlers look something like this:

ecowx r0,r0,r0
rfi

The firmware doesn't need **any** registers. It's magic. I was
just using the BAT registers to map what Linux wanted mapped.

Anyway, I'm no longer able to reproduce the problem. I think
something unrelated was causing strange behavior. This is a
bit of a surprise since I would've expected a crash. Oh well.