[OpenBIOS] Running client with MMU off
Alexander Graf
agraf at suse.de
Wed Jun 25 01:30:43 CEST 2014
On 25.06.14 01:21, BALATON Zoltan wrote:
> On Sat, 21 Jun 2014, BALATON Zoltan wrote:
>> On Fri, 20 Jun 2014, Mark Cave-Ayland wrote:
>>> As for the code that generates the ISIs, is this in MorphOS as
>>> opposed to OpenBIOS? I guess something must have previously accessed
>>> an entry on the same page before the registers were updated, or
>>> maybe there is some kind of hardware readahead?
>>
>> The code is in the MorphOS boot loader and what it does is trying to
>> take over memory management. Unfortunately it seems there is a period
>> when it already replaced the vectors but have not set up the TLB hash
>> table yet so it cannot actually handle exceptions. I could prevent
>> DSIs but running the code during this period generates ISI-s. If the
>> code is run in the same order on real hardware then it's not likely
>> that the page is accessed there and not on QEMU. A readahead could
>> explain it but I don't know if that happens. I have no better idea
>> now than manually generating faults for all pages where the client
>> code is loaded before calling it. I'll try to implement that unless
>> someone can suggest a better solution.
>
> Experimenting with it some more I could not make it work that way
> probably because by the time the ISI happens the vectors are already
> replaced and the sr0 register is overwritten so even if I manage to
> put translations in our hash table for that code that won't be correct
> any more by the time the ISI that causes a crash is handled.
>
> So the only things that might work are using IBATs or disabling the
> MMU bits when MorphOS overwrites the vectors. I think this latter
> option is a bit cleaner but how can I get an interrupt when a memory
> address is written to? (Apart from setting up a watch point for it.)
> In the OpenBIOS code there are comments stating that page 0 is not
> mapped to catch NULL pointer dereferences but this does not seem to
> work as MorphOS can write over page 0 and only get an exception when
> reaching the next page. (Also I've found documented in one version of
> the PPC programming environments document that 0x00-0xff is reserved
> for operating system use so they can legally write there.) I'm sure
> I'm missing something here again.
>
> It could possibly work on real hardware because of caches and that's
> where the read ahead might happen during the critical part. This is
> what seems to happen during MorphOS's MMU take over as far as I
> understand:
>
> 1. memcpy to 0, len=0x2000
> 2. fixup jumps and write base address to 0x80 (this is what's zeroed at
> the earlier write at the beginning)
> 3. Set MSR_BE and tweak HID0 (this may cause code to be preloaded in
> cache?)
> 4. Set sr0-15 from stack variables
> 5. Values for IBAT and DBAT registers are loaded from the stack and SDR1
> is set to 0 dropping the hash table
> 6. MSR_DR and MSR_IR are cleared
> 7. BAT registers are set up as shown in this message:
> http://www.openfirmware.info/pipermail/openbios/2014-June/008419.html
> which means that the stack should be within the first 256MB
> 8. TLB entries are invalidated then MMU bits are re-enabled (but
> hashed page tables are not there yet so it relies on BATs at this
> point)
> 9. After doing some other stuff eventually a function is called that sets
> up the hash table
> 10. Vectors are replaced again later during boot after the microkernel
> has
> started its servers
Shouldn't the above sequence work fine if it's executed with MSR_IR=0
MSR_DR=0 from the beginning?
Alex
More information about the OpenBIOS
mailing list