On Tue, Oct 5, 2010 at 4:10 AM, Benjamin Herrenschmidt <b...@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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
