use of BAT before taking over the MMU

[Albert Cahalan]

On Tue, Oct 5, 2010 at 4:10 AM, Benjamin Herrenschmidt
<benh at kernel.crashing.org> wrote:
> On Mon, 2010-10-04 at 06:25 +0200, Segher Boessenkool wrote:
>> > On the prom boot path, with the firmware supposed to
>> > be managing the MMU, there is a case where:
>> >
>> > 1. Linux changes some BAT registers.
>> > 2. Bits 0x00000070 are/become set in the MSR.
>> > 3. Linux takes an MMU fault.
>> > 4. The firmware handles it.
>> >
>> > AFAIK, you can't expect the firmware to leave the BAT alone.
>> > If the firmware provides mapping services by using the BAT
>> > as a software-filled TLB, Linux's BAT changes may be lost.
>> >
>> > You also can't expect that your BAT changes will not conflict
>> > with mappings that the firmware uses for itself. The firmware
>> > might write to your new BAT mapping, relying on those virtual
>> > addresses to be something else entirely.
>>
>> The PowerPC OF binding requires the firmware to save and restore
>> the BATs on entry to / exit from the firmware.

That would defeat the purpose of setting them.
They are used to provide Linux with mappings.

> I'm not sure he was talking about OF here... In any case, we don't muck
> around with BATs until after we're done with OF anyways.

It's the Open Firmware client interface, not Firmworks code.
I wrote it. It just does hypervisor-like calls to an emulator which
does the real work. Essentially I have a prom_call opcode
and a handle_exception opcode. I claim to be an MPC7400.

The kernel is sitting at address 0, MSR becomes 0x70 when
an rfi goes to address 0. This will be head_32.S with r5 set,
so Linux will call prom_init to fetch the device tree.

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)

I threw in a hack to skip to the next BAT when the chosen
one is not a 128 KiB 1:1 mapping. That seems to work, but
sure doesn't feel right.

Note that Linux can fail even with a firmware that doesn't touch
the BAT registers. The MMU is on, 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.