Note that there is a variant architecture (the sun3x) typified by the Sun 3/80. This uses the mc68030 chip, which has its own MMU and is entirely different.
Sun 3 systems work with 24 bit virtual addresses. Indeed the 68020 chip is a 32 bit machine and handles 32 bit addresses, but the sun3 MMU "ignores" the upper 8 bits. Saying "ignores" is not quite true, but is the best way to think about things for now.
There are 3 main components to the sun 3 MMU.
One section of the segment map has 2048 entries. (So the entire segment map has 8*2048 = 16K entries). Each entry covers 128K of address space. (With 2048 entries this gives 2048*128K = 256M)
The entries in the segment map are only 8 bits! This is called a PMEG index. It serves to select one group of 16 pages (PMEG = page map entry group)
The page map has 4096 entries. Pages are 8K in size. So with 4096 entries, we can cover 32M of address space.
Each page map entry is 32 bits in size. The field that selects the physical page is 16 bits in size, so we can identify one of 64K pages. In other words we can select pages from a physical address space that is 64*8 = 512M in size.
A fundamental issue is the size of the page map. The page map is shared by all contexts, unlike the segment map where each context gets its own map. With 4096 entries, each 8K in size, we can map only 32M of ram at one time. To access more ram, entries would need to be replaced and "shuffled" with an operating system keeping track of what was currently mapped and how.
So consider one context that was using 32M of ram, transparently mapped. The segment map defines 256M of virtual address space, only 32M of which would be referencing physical memory. The segment map has no control and status bits, that is all handled by the page map, so what do we do with the segment map entries for invalid entries? This still need to point to page map entries. Two choices are available. We can point them at some page with valid entries and let that PMEG be aliases all across the address space. The other more likely choice is to set aside one PMEG full of page map entries (16 pages, 16*8 = 128K) and mark all those pages as invalid. This means we would have to sacrifice 128K out of the 32M of physical memory we had mapped.
This is not quite true. Many modern processors have control bit somewhere that is labeled "MMU enable". What the Sun 3 has is a "boot" bit. The simple description of the "boot bit" is that when it is clear, all supervisor program fetches are to EPROM regardless of the MMU. it also states that "all other types of references are unaffected. This bit is in the system enable register.
This leaves me with questions. What about stack references by the boot rom? It would seem that the boot rom would need to perform a minimal setup of at least one PMEG before it could access the stack. It would be worth examining the bootrom code to see what is does in this regard, as well as when it sets the boot bit to allow normal behavior.