Sun 3 bootrom

August 16, 2025

Sun 3 bootrom souce - Tour: startup and diagnostics

The help menu for the Sun 3/80 shows these three additional commands that we don't have in the 3/160 code.

^a                                       | Display Phys and Virtual Addresses
^t [addr]                                | Translate virtual addr to physical
^r                                       | Read On Board Device Registers

I particular, it would be nice to have the "^a" command which gives information like this:

EEPROM -- 0x6400_0000  (0xfef0_4000 virtual)
TOD    -- 0x6400_07f8  (0xfef0_6000 virtual)
IDPROM -- 0x6100_0C00  (0xfef1_cc00 virtual)

I wish I had preserved the entire display, but I didn't. Maybe this could be implemented in the 3/160 rom if there is room.

Note that the 3/80 uses a bigger 128K rom, so there is room for such things. The 3/80 uses about 92K, with 36K of unused space.

A lesson in all of this is that IO devices can only be accessed via virtual addresses! This is very different from any other machine I have worked on (and it is just as true on the 3/160 as it is on the 3/80).

For example, I access the registers for serial port A at address 0x0fe02000 -- and it works! The reference manual shows the physical address for this zilog SCC as 0x00020000 (and the physical address for the keyboard mouse as 0x0!)

Virtual address for the intel ethernet control register

First of all, this is not part of the i82586 chip. That chip actually has no registers in the address map! It works by pulling data structures via DMA out of memory. The game is to set up those structures, then pull the reset line on the chip and it will read them in.

This address is set up by this call:

devalloc(MAP_OBIO, VIOPG_ETHER << BYTES_PG_SHIFT, sizeof(*obie));

The value for VIOPG_ETHER is 0x60. We have 8K pages so BYTES_PG_SHIFT is 13. The shifted value is 0x60<<13 = 0x000C_0000, which is exactly the physical address given on page 31 of the Technical manual.
We also see these definitions in cpu.map.h:

#define VIOPG_KBM       0x00    /* Dual serial Z8530 SCC for keyboard&mouse */
#define VIOPG_SERIAL0   0x10    /* Dual serial Z8530 SCC */

But devalloc() is not used to set up the virtual addresses for these. The work is done in sys/mapmem.c, driven by a table "mapinit", which has these entries, among others:

	{(char *)KEYBMOUSE_BASE, 0, {1, PMP_SUP, VPM_IO, 0, 0, VIOPG_KBM}},
	{(char *)SERIAL0_BASE, 0, {1, PMP_SUP, VPM_IO, 0, 0, VIOPG_SERIAL0}},

This process does not use devalloc(), but apparently works. This may explain some of the trouble I am having with accessing the obie register.

Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org