August 11, 2025

Sun 3 bootrom souce - First run of the newly compiled bootrom code

I add a "load" entry to my Makefile so I can type "make load". It does this: tom@trona:/Projects/sun3-prom/Github/build$ make load loadice -i bootrom.bin LoadICE Version 2.5-tjt 12-22-2018 Copyright (C) 1990-1994 Grammar Engine, Inc. Opening command file 'loadice.ini' File not found 'loadice.ini' - proceeding Executing command line '-i bootrom.bin' Establishing link with PROMICE (please WAIT) Opening serial device '/dev/ttyUSB0' at 19200 Baud .Link is up PROMICE units: ID 0 uCVer:8.2B MemSize=2097152 EmuSize=2097152 FillChar=FF ID 1 uCVer:8.2B MemSize=2097152 EmuSize=2097152 FillChar=FF Opening file `bootrom.bin` for processing --Done Transferred 53554 (0xd132) data bytes Exiting LoadICE
I press the reset button on the 3/160 and get:
MEMORY ERROR!  Status D2, DVMA-BIT 0, Context 0,
  Vaddr: FFFE016, Paddr: 003FC016, Type 0 at 0x0FEF0FEE.
>
This repeats endlessly. Note that I do get what looks like the bootrom prompt. I get the same thing whether the switch is in the DIAG or the NORM position.

Some comments

This is far better than I expected honestly. I just threw together the "lds" file, and expected to have to make adjustments to it before anything would even run. I more or less expected that I would get no output at all and be scratching my head at this point.

Help from Romain

I am working on this is close collaboration with Dan and Romain. I told them last Friday (3 days ago) that I had finished my first round of edits and got a clean compile and link. Romain didn't waste time. He forked my Github and began testing using the TME emulator. He as already found the above issue as well as many others and this morning reports that he has been able to boot NetBSD using the bootrom code.

This means he is going to save me a lot of work, as he has been keeping me informed of issues he has found (and fixed!).

Fix the PME entries in sun3/assym.h

This is due to bitfield order changes with the x86 compiler and genassym.c I fix this, but still get these messages. A closer look shows that there are actually two in alternation:
MEMORY ERROR!  Status D2, DVMA-BIT 0, Context 0,
  Vaddr: FFFE016, Paddr: 003FC016, Type 0 at 0x0FEF0FEE.

MEMORY ERROR!  Status D2, DVMA-BIT 0, Context 0,
  Vaddr: FFFE016, Paddr: 003FC016, Type 0 at 0x0FEF046A.
One thingwe can do is to look up these addresses in bootrom.dump. The first (fef0ffe) is in _selftest() and the code looks harmless enough. The second (fef046a) is in the middle of an instruction.

I am suspicious, so I cycle power on the sun3, now I get:

Boot PROM Selftest

PROM Checksum Test
DVMA Reg Test
Context Reg Test
Segment Map Wr/Rd Test
Segment Map Address Test
Page Map Test
Memory Path Data Test
NXM Bus Error Test
Interrupt Test
TOD Clock Interrupt Test
MMU Access Bit Test
MMU Access/Modify Bit Test
MMU Invalid Page Test
MMU Protected Page Test
Parity Test
Memory Size = 0x00000004 Megabytes
Memory Test (Testing 0x00000004 MBytes)   Testing...

Selftest passed.

Type a character within 10 seconds to enter Menu Tests...
So, pressing the reset button really didn't do what I thought. What would be helpful now is some kind of signature in the ROM that gets displayed. Pressing the reset button now gives me:o
Watchdog Reset!
>
I type "k2" to this prompt and get:
EPROM: Using RS232 A port.
Selftest Completed.

Sun Workstation, Model Sun-3/160M.
ROM Rev 3.0, 4MB memory installed, Serial #17403.
Ethernet address 8:0:20:1:DB:0, Host ID 110043FB.

Testing 4 Megabytes of Memory ... Completed.

Auto-boot in progress...
Holy cow, this is acting like a working bootrom. I didn't encounter some of Romain's problems because I am not using keyboard/framebuffer code, just the serial port.

Why is it reporting ROM Rev 3.0? It is as though it is magically running the original rom code???

Use the ROM to dump memory

We press the reset button to get the watchdog reset and then to dump memory:
v fef0000 fef0010
0FEF0000:	0F E6 0C 00 0F EF 00 EE 0F EF CA 74 0F EF 00 E4 	.f...o.n.oJt.o.d
0FEF0010:	FF FF E1 D6 0F EF 0F 28 0F EF 0E 58 0F EF 0F 56 	..aV.o.(.o.X.o.V
The default is to display bytes. We can choose b, w, or l as follows:
v fef0000 fef0020 l
0FEF0000:	0FE60C00 0FEF00EE 0FEFCA74 0FEF00E4 	.f...o.n.oJt.o.d
0FEF0010:	FFFFE1D6 0FEF0F28 0FEF0E58 0FEF0F56 	..aV.o.(.o.X.o.V
0FEF0020:	0FEF0E8E FFFFE01B FFFFE016 FFFFE017 	.o....`...`...`.
I can dump my executable via:
odx bootrom.bin
00000000 0fe6 0c00 0fef 0012 ffff e250 2e3c 7777
00000010 0000 3e7c 0009 4e7b f002 3e7c 0003 4e7b
00000020 f001 4e7b f000 9fcf 0e39 f800 3000 0000
So it would be handier to dump memory with the "w" size:
v fef0000 fef0020 w
0FEF0000:	0FE6 0C00 0FEF 00EE 0FEF CA74 0FEF 00E4 	.f...o.n.oJt.o.d
0FEF0010:	FFFF E1D6 0FEF 0F28 0FEF 0E58 0FEF 0F56 	..aV.o.(.o.X.o.V
0FEF0020:	0FEF 0E8E FFFF E01B FFFF E016 FFFF E017 	.o....`...`...`.
Clearly we are not running my compiled code. So we dump the original Sun bootrom that I read out:
00000000 0fe6 0c00 0fef 00ee 0fef ca74 0fef 00e4              t
00000010 ffff e1d6 0fef 0f28 0fef 0e58 0fef 0f56          (   X   V
00000020 0fef 0e8e ffff e01b ffff e016 ffff e017
Yep, that is what we are running. I need to read the loadice manual more carefully. Apparently I loaded the original image OK and it is somehow keeping it, even when I pull the power cord (it must have a battery). And for whatever reason, it is acting as though it loads a new image, but is not doing that at all.

My guess is this. The device can be in dialog mode or emulation mode. When it is in emulation mode, it is presenting emulation ram to the sun to execute. We will need to stop that before downloading code to the device. Now I think that the device ought to "just do that", but clearly it does not. What is definitely should not do is to act as though it has excepted a download when in fact it has done nothing at all.


Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org