October 27, 2024

Sun 3/80 -- disassemble the bootrom

We have the file sun380.bin, which is 131072 bytes in size, just as it should be.

I have my tools "wrap.c" from the Callan project which I use to turn the .bin file into a .elf file. I make the assumption that the ROM starts a 0xfefe0000 and away I go. I need to install: 

dnf install -y gcc-m68k-linux-gnu
When I do the disassembly, it is important to specify -m68020 rather than -m68000, as there are plenty of new instructions in the 68030

My assumption is validated by some constants in NetBSD 2.0 code: 

/*
 * We don't have a separate kernel debugger like sun kadb,
 * but this range is setup by the monitor for such a thing.
 * We might as well preserve the mappings anyway.
 */
#define SUN3X_MON_KDB_BASE  0xFEE00000
#define SUN3X_MON_KDB_SIZE    0x100000

/*
 * MONSTART and MONEND define the range used by the monitor.
 * MONDATA is its data page (do not touch!)
 * PROM_BASE is where the boot PROM lives.
 */
#define SUN3X_MONSTART      0xFEF00000
#define SUN3X_MONDATA       0xFEF72000
#define SUN3X_PROM_BASE     0xFEFE0000
#define SUN3X_MONEND        0xFF000000

/*
 * These define the CPU virtual address range mapped by the
 * PROM for use as DVMA space.  The physical pages mapped in
 * this range are also mapped by the I/O MMU.  Note that the
 * last page is reserved for the PROM (really for the "ie").
 */
#define SUN3X_MON_DVMA_BASE 0xFFF00000
#define SUN3X_MON_DVMA_SIZE   0x100000  /* 1MB */

Vectors

I do a hex dump of the file. The ROM is blank (almost) after address 0x16b70. The exception is the last 2 bytes, which are: 

0001fff0 ffff ffff ffff ffff ffff ffff ffff 1ac7
The first few bytes are: 
00000000 fef6 0c00 fefe 0228 fefe 073a fefe 00f8          (   :
00000010 fef7 21d6 fefe 1f50 fefe 1e74 fefe 1f80     !    P   t
00000020 fefe 1eaa fef7 201b fef7 2016 fef7 2017
00000030 fefe 2206 fefe 21dc fef7 21ea fef7 2013     "   !   !
00000040 fef7 20d6 fef7 20da fef7 22f2 feff 4468             "   Dh
00000050 fefe 4ba0 fef7 2366 fef7 208a fefe 4bba     K   #f      K
00000060 fefe 388a fef7 2028 fef7 2020 fef7 20c6     8    (
00000070 fefe 2430 fefe 2536 fefe 2562 fef7 2096     $0  %6  %b
00000080 fefe 258c fefe 2b04 fefe 2c54 fef7 200e     %   +   ,T
00000090 fefe 0bf8 fefe 04fe fefe 0622 fef7 20c2              "
000000a0 fef7 210e 0000 0002 fef7 2000 fef7 22ee     !           "
000000b0 fef7 20ca fef7 2014 fef7 21da fef7 21aa             !   !
000000c0 fef7 21b2 fefe 03ba fef7 201c fef7 22ea     !           "
000000d0 fef7 222a fef7 222e fef7 2232 fef7 2236     "*  ".  "2  "6
000000e0 fef7 223a fef7 2376 0000 0000 0000 0000     ":  #v
000000f0 0000 0000 0000 0000 fef7 2250 206f 0004             "P o
00000100 7000 1010 4e75 206f 0004 7000 3010 4e75   p   Nu o  p 0 Nu
00000110 206f 0004 2010 4e75 206f 0004 202f 000c    o    Nu o   /
00000120 1080 4e75 206f 0004 202f 000c 3080 4e75     Nu o   /  0 Nu
This looks like vectors followed by unknown stuff. If we guess that the ROM sits at the end of feffxxxx then the first address should be fefe0000 and so on through feffffff. We need to see if assuming this and disassembling code yields a sensible result.