On Tue, Oct 5, 2010 at 11:31 AM, Segher Boessenkool <seg...@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. You 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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev