On 2026-09-28 13:29, Imre Kaloz wrote:
The SS-10, SS-20 and SPARCserver 600MP accept -m up to 60 GiB, and the
LX, SS-4, SPARCclassic and Voyager accept 256 MiB, more than any of
these machines could hold. On the SS-10, SS-20 and 600MP, sizes above
the hardware limit fall into three ranges:
- Up to 4 GiB, QEMU maps the RAM, but no real machine could hold it.
- From 4 GiB, the size wraps around in the firmware. QEMU passes it as
an 8-byte fw_cfg item, but the sparc32 OpenBIOS reads only its low
32 bits, so -m 5120 boots as if it were -m 1024.
- Above about 56 GiB, the RAM also overlaps the SBus devices, which
start at 0xe20000000 (TCX).
Set each limit from the real hardware:
- The SS-10 and SS-20 memory controllers (EMC and SMC) decode eight
SIMM slots as 64 MiB windows from 29 DRAM address bits, 512 MiB in
total (Sun patent EP0571099).
- The SPARCserver 600MP takes at max 1 GiB, onboard plus expansion
boards (SPARCsystem 600MP service manual, 800-5318).
- The SS-4 takes at most 160 MiB in its five SIMM slots.
- The LX and SPARCclassic use the microSPARC-I on-chip controller,
which decodes four 32 MiB banks, 128 MiB.
- The Voyager has 16 MiB onboard and two slots for 16 or 32 MiB cards,
80 MiB. Its default RAM size becomes 80 MiB, so -M Voyager without
-m still starts.
- The SPARCbook model gets 128 MiB, the decode limit of its
microSPARC-I. This keeps QEMU's default -m of 128 MiB working and
does not describe a real SPARCbook configuration.
Machines without ECC map an empty slot so that accesses to missing RAM
do not fault. It now ends at iommu_base, where memory decode ends on
those machines, rather than at max_mem.
Update the maximum memory sizes in docs/system/target-sparc.rst.
Signed-off-by: Imre Kaloz <[email protected]>
---
docs/system/target-sparc.rst | 6 ++++--
hw/sparc/sun4m.c | 24 ++++++++++++++----------
2 files changed, 18 insertions(+), 12 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
