NetBSD/mac68k Work Entry #2


This entry follows up on the work from Work Entry #1, but unfortunately is much less interesting. I've mainly been focused on making the previous changes more generic and able to be integrated into mainline NetBSD.

RAM Controller Reconfiguration

I've made a "DJMEMCMAX" kernel configuration option which will configure all the djMEMC banks for their maximum 64MB. It currently detects the amount of soldered memory, so it should work with both 4 and 8MB logic boards, and it is enabling the first 2 SIMM banks as well, so on my 8MB Centris 650, all 520MB are available to the NetBSD kernel.
To enable the first SIMM bank, I'm first enabling all banks >=4, then copying the bank 2 & 3 enabling code into memory now located in bank 4 & 5, jumping to it, enabling banks 2 & 3, then jumping back. The enabling process is non-destructive, so there's no need to copy the contents of that bank. We just can't be executing from it while changing it.
To be really robust, this code should attempt to dynamically size the memory banks, detecting whether 128MB SIMMs have been installed, and support any combination of installed SIMMs, interleaving or not where appropriate. That would be the ideal, but... I'm not there yet, and I think it would be helpful to get something in to allow 128MB SIMM usage instead of delaying indefinitely on an ideal that might not materialize.

djMEMC Documentation

I've documented what I know about the djMEMC on this wiki page.

Process' Segment Tables

In the previous work entry I gave some background on the problems with NetBSD's 68k user process page tables. Specifically, it only allocates one page to hold the user process' level 1 & 2 MMU tables, which results in user processes only having 224MB of virtual address space before the kernel panics.

I've developed a plan on how to address this without needing to allocate physically contiguous pages or changing page size, I just need to actually do it. Here is the plan:
The current code assumes the level 1 & 2 tables are allocated physically contiguous. It has a single pointer to "the" segment table, and then initializes all entries from there. The MMU doesn't require the entries to all be physically contiguous, it's the current code that just assumes they are. For instance, the level 1 MMU table is a 512 byte block of 128 pointers to level 2 tables, which are themselves 512 byte blocks. The level 2 tables can exist anywhere in physical RAM, as long as the level 1 table points to the right place. So, the plan would be to update the 68k pmap_t structure to contain an array of pointers to segment tables, with only one allocated initially. When that table is exhausted, instead of the current panic, allocate another page, initialize it with 8 level 2 tables, and update the corresponding level 1 entries to point to the 8 new entries.
This involves a lot of tedious work updating the book keeping structures and all accesses to the segment table within the m68k pmap code. Assuming this approach actually works, it should help most of the NetBSD m68k ports.

Updated April 23 2013