iFusion not working

[DvdBoon]

At the moment iFusion is not working. It depends on some advanced features of WarpOS. If we ever get iFusion running we can effectively say that we are done regarding WarpOS compatibility :-) This is why I want to add a separate issue to it.

Debugging sessions have not taken me far yet. The first hurdle was exception handlers. These have been implemented and the large_context ones work (they are used by wosdb). iFusion however uses small_context exception handlers and are not fully tested yet.

At startup, iFusion sets up a number of exception handlers and jumps to the program/trap/privilege exception handler. Here it hangs due to loading a wrong value into SDR1 (needed for MMU setup).

Recently i discovered that this is due to alignments not supported by AllocVecPPC(). iFusion allocates 0x400000 bytes with alignment 0x100000 for the page table. It gets a non-aligned (well, actually 0x20 aligned) block in return. This is invalid for SDR1.

Hope to add alignment support for AllocVecPPC() soon. I also foresee problems/conflicts with the default MMU setup of the library. but first things first.

[DvdBoon]

Alignment support has been added to AlocVecPPC(). IFusion now requests and gets a correctly aligned block. However, this block is under influence of the current MMU setting. For example, it gets memory at 0x7a100000. When it builds a page table, it does so with translated addresses. The actual physical address is 0x0a100000. So when the MMU context changes from the default MMU setup to the iFusion MMU setup the PPC freezes as the new pagetable is not correct.

The most ideal solution would be to move the whole memory range to the same address as the 68K sees it. This is at the moment in the 0x60000000-0x80000000 range (512MB Zorro3 window). The PPC now translates 0x0-0x20000000 to this range.

However, the TSi107 chipset only support up to 0x40000000. This would mean that we should move the whole memory-space of the Mediator to 0x20000000-0x40000000 so translation on the PPC is not required anymore . And iFusion sees actual physical addresses. It might akso remove the need of the ATUs.

As the Mediator documentation is not in my possession, I'm not sure this is even possible.

[rkujawa]

Mediator space is assigned according to AutoConfig mechanism. So the real question is, how AutoConfig allocates memory space in Zorro III area. In Amiga 3000 and 4000, area of 0x10000000-0x80000000 is used for this purpose. So at least in theory, it is possible to make Mediator reside in area below 0x40000000. The question is, how deep would we have to dig to achieve that (expansion.library is responsible for this? or something else?).

[DvdBoon]

I think the allocation is done automatically without an option to patch it as I think it happens upon boot. Or patch the expansion.library and LoadModule it.

But maybe it is a lot easier/better to just patch cd_BoardAddr before the pci.library is loaded. and change it to 0x20000000 if no other board is occupying this region. This could be done by a small patch program at the start of the startup-sequence.

Also the swap jumper needs to be closed so the 512MB region is sitting at 0x20000000 and the 16MB config region is sitting at 0x400000000. I don't know if this would work as the manual describes this jumper as being open for PCI graphic cards, but I don't think it should matter. Probably needs some code change in the sonnet.library as there might be dependencies on the jumper being open.

[DvdBoon]

This will not work. cd_BoardAddr is read-only and setup during AutoConfig.
Another thing is that according libraries/configregs.i EZ3_CONFIGAREA runs from 0x40000000 to 0x80000000..... So not from 0x10000000.

In expansionbase.i, there is a private eb_private03 (which is actually a word, not ULONG as far as I can see) which indicates the start slot in memory. Each slot is 0x10000 big and eb_private03 probably starts at 0x4000 when expansion library is initialized but no AutoConfig has taken place yet. It is used by AllocExpansionMem(). Number of slots passed to AllocExpansionMem is 0x2000 (= 512MB).

So not sure if this can be done.

[DvdBoon]

The libinit routine of expansion.library does an explicit move.w #$4000,eb_private03(libbase)

I can patch that but Loadmodule or Loadresident does not override the expansion.library in ROM. Maybe I am doing something wrong, though.

[DvdBoon]

The sonnet uses up to 6 banks of memory. The latest internal builds now run with 1 bank with address 0x00000000-0x02000000 and the rest from 0x10000000-0x1A000000 (32MB/160MB in case of 3x64MB DIMMs). With the 68K MMU paging 0x10000000 to 0x70000000 (the PCI Memory window of the Mediator) the 160MB is accessible to the 68K. The other 32MB is not. The kernel, pagetables etc. will be stored in the 32MB as the 68K does not need to access these items.

iFusion needs a switched off PPC MMU during its exceptions. With the old builds this was not possible as the PPC MMU was needed to translate 0x00000000 to 0x70000000. Now with the new internal builds, if the PPC MMU is disabled 0x10000000 is still accessible by the PPC and by the 68K.

In other words: Now with logical and physical address being the same (both 0x10000000) and not different anymore (0x70000000 versus 0x00000000) the PPC MMU can be switched off when needed.

The exception handlers of the sonnet library are not correct at the moment. So a rewrite is needed of those handlers before I can test iFusion again.

[DvdBoon]

Rewrote the exception handlers. But there is still a problem. iFusion invalidates all BAT registers and sets up a clean SDR1 register with an empty page table. Then it hangs.

[DvdBoon]

Hang was due to PSL_IP being flipped by iFusion. Resulting in the system expecting the exception vectors being at 0xFFF00000 in stead of 0x00000000. That's at least why it hang on this spot. On to the next error.

[DvdBoon]

iFusion sets up three custom MMU page tables. At the moment I am not sure how WarpOS handles those. The context switch takes care of Segment registers and BAT registers but not the SDR1 register as far as I can see.

Some private stuff in the TaskPPC structure comes also into play: TaskPPC_Table and TaskPPC_TableLink.

[DvdBoon]

As said before, iFusion invalidates the (upper) BAT registers. Any attempt to reactivate the MMU in the kernel handlers will halt the processor as there is no valid address space.

Unlike CSPPC, the sonnet needs access to PCI config space (guarded/cache inhibited) and a cache inhibited memory area for message sending to 68K.

Maybe do a internal SetExcMMU and ClearExcMMU.

Start Kernel Exception (MMU = off by default)
SetExcMMU
Enable MMU
Kernel Code
Disable MMU
ClearExcMMU
Custom iFusion handler
SetExcMMU
EnableMMU
More Kernel Code
Disable MMU
ClearExcMMU
End Kernel Exception

or pinpoint the code in the exceptions where cache manipulation is needed through dcbf and dcbi.