[rescue] sun 3/60 update

[Romain Dolbeau]

Le mar. 27 mai 2025 à 22:26, Dan Moisa <dmoisa at gmail.com> a écrit :
> There are severe limitations to the pre-inbuilt MMU

Indeed. However, I think for a redesigned board and using current 5V
SRAM, some of those (performance, size) could be work around with
minimal impact on the OS kernel (I'm thinking NetBSD, I don't think
SunOS would be fixable unless the source for 4.1.1U1 were available).

TL;DR: using cheap modern larger SRAM, but can easily add hardware
context and map more physical memory with minimum software update (and
backward compatibility), but expanding the virtual space is a problem.

So the MMU in the Sun3 works that way:

(a) A context id (read: ~ process Id) and some upper address bits are
use to look-up an 8-bits index (in a 16Ki entries SRAM) in a page
segment table
(b) This 8-bits index, combined with another 4 address bits, returns
the upper 19 bits of the physical address [16 on the 3/60] and some
status bits from a 4 Ki entries SRAM
(c) Those 19 [16] bits, concatenated with the lower 13 bits of the
virtual address, is the accessed physical address on 32 bits [29]

One big issue with that: only 2^8 (256) segments are available (the
index), each containing 2^4 (16) pages. Those pages are consecutive in
virtual memory, so only 256 areas of up to 128 KiB (16 pages of 2^13 =
8 KiB each) can be mapped at a time. That's only 32 MiB, and includes
virtual mappings for some devices. You can have more physical memory
than that, but then you need to software reload the MMU a lot -
there's no hardware page walker as on modern systems! Also, 38 MiB is
the optimistic view that all 16 pages are used in all segments. With
enough sparsity in the virtual space(s), the worst case scenario is 2
MiB - only one page used per segment... That's not great.

However, the SRAM used are quite small (would have been costly back
then), and modern SRAM are usually bigger. Not taking advantage of
that is wasteful IMHO :-) It should be possible to redefine some
parameters to make the MMU "better" by leveraging those bigger SRAM -
the question being, can it be used by software? If not, there's no
point in bothering. I believe it is possible!

For the first SRAM containing  the index to the segment, two things can be done;

(a) a deeper SRAM (more entries)
(b) a wider SRAM (more data)
The first would enable to have extra bits in the context ID (==
cheaper context switch when both process can keep their mappings in
the MMU) and/or extra bits in the virtual address (larger virtual
space for process, repurposing the reserved and FPA area - you can't
have an FPA on the 3/60 anyway [FPA != FPU, you can have a FPU]).
However, extra bits of virtual address have an update issue with the
MMU design, see below.
The second would produce more bits of index, thus enabling a deeper
(more entries) page map in the second SRAM, which is what is really
needed (at least according to the comments in the NetBSD code!).

For the second SRAM, going wider to go beyond 16-bits + tags isn't
really useful - I don't think anyone really want more than 512 MiB of
physical RAM in a 3/60 - but in theory it's possible, and it would
make the 3/60 actually comply with the specifications.

Hardware-wise, it's not very expensive. 4 Mib SRAM, so 256x16 for the
first SRAM and four 512x8 (two of the current x4 for permission and
status can't be combined, different control signals) for the second
SRAM, are less than 4€ each on Mouser, MOQ 1. That's less about 20€
worth of SRAM for a MMU with:
(a) 4 (resp 5, 6, 7) bits of context and up to 31 (resp 30, 29, only
28) bits of virtual addresses (4 extra bits to play with vs. stock
3/28) and output of up to 16 bits
(b) 32768 segments instead of 256, able to directly map 4 GiB. Even
with maximum sparsity, it's at least 256 MiB mapped.
Smaller SRAM could be used, but they are not much less expensive, and
if the SW needs to be fixed, might as well go big :-)

Software-wise, two out of three shouldn't be difficult, the third
(extra virtual bits) is a problem:
(a) context ID is specified as a 8-bits register with reserved upper
bits. Except for the number and mask in NetBSD, nothing to change,
byte load/stores are fine. This would break the memory error register
though, as it can only store the standard 3 bits of context ID (does
it matter?)
(b) segment index is accessed via a byte register. It could be
extended to a Word register by changing the number in NetBSD (and
maybe adding a mask) and updating the access function from byte to
word.
(c) Extra virtual bits are likely fine in the kernel (there's probably
a restriction somewhere for the sun3 architecture to prevent A[28..31]
!= 0, didn't look it up, but I assume it could be made to work just as
on other architectures) and for MMU look-up. However, there's an issue
with writing the value in the SMAP memory. This is done through
Control Space (FC code 0x3). The actual device is identified by
A[28..31], with the SMAP register in 0x2. So the bits could be used in
a virtual address, but that virtual address cannot be written in the
SMAP register for mapping without some hacks :-( [1]

Also note that as long as the "new" bits are set to zero, all of that
would be backward-compatible to all existing software.

Cordially,

Romain

[1] Not all 4-bits prefixes are specified in control space, and some
specified aren't going to be used (no cache, no block copy, etc.), so
some combinations *might* be usable. I think A31 could be used, as
none of the "useful" control space devices set it to 1, which would
double the virtual space (256 MiB at bottom with A[28..31]=0x0, 256
MiB at top with A[28..31] = 0x8).

-- 
Romain Dolbeau