[LMH]SIB, Config ROMs, Fonts, Diagnostic Engine Code
Steve Krueger
stevelisp@grape-krueger.com
Wed Aug 6 21:34:01 2003
Alastair,
You are right about most of this. I have a few specifications for
related stuff but first the genralities:
At startup, one processor device (the processor in the lowest slot, I
think) becomes the system test and boot master (STBM). The STBM begins
by probing the system to see what's there. It then enters an
interpreter for a "Forth-like" byte-coded instruction set. The
interpreter is called the Diagnostic Engine. Each slot contains a ROM
at a specified address in FsXXXXX space. I think I have the spec for
this. I don't actually have the spec for the instruction set used by
the Diagnostic Engine interpretter.
OK. A bit of digging around and I have the Identification ROM spec.
The ID ROM is on every board and occupies the highest addresses in
"slot space" ( 0xFsFFFFFC downto 0xFsFFFE00). Addresses are assigned
down from the highest address so that the size of the ROM containing the
configuration parameters can be board dependent. The ROM supplies a
single byte per word address. The following is the table of NuBus
system-defined byte addresses:
NuBus Addr Field Len Enc. Description
Comments:
---------- --------- ----- --------------------------------
---------------------------
FsFF FFFC 9 D Week of Manufacture (00-52)
9-bytes make up Serial Number
FsFF FFF8 A Year of Manufacture (3-Z)
3=1983 A=1990 Z=2010
FsFF FFF4 A Site (leftmost char)
'A' on TI hardware
FsFF FFF0 A Site (middle char)
'U' on TI hardware
FsFF FFEC A Site (rightmost char)
'S' on TI hardware
FsFF FFE8 H Sequence Number (MSHD) most
significant hex digit (0X)
FsFF FFE4 H Sequence Number
middle two hex digits (XX)
FsFF FFE0 H Sequence Number least
significant two hex digits (XX)
FsFF FFDC A Check Code of
Serial Number - Uses weight table
FsFF FFD8 7 A 6th revision letter
if 0x00 or 0xFF isn't used yet
FsFF FFD4 A 5th revision letter
if 0x00 or 0xFF isn't used yet
FsFF FFD0 A 4th revision letter
if 0x00 or 0xFF isn't used yet
FsFF FFCC A 3rd revision letter
if 0x00 or 0xFF isn't used yet
FsFF FFC8 A 2nd revision letter
if 0x00 or 0xFF isn't used yet
FsFF FFC4 A 1st revision letter
if 0x00 or 0xFF isn't used yet
FsFF FFC0 A Primary version letter or '*'
FsFF FFBC 2 B CRC signature, most significant
covers 2**ROM_Size -18 bytes
FsFF FFB8 B CRC signature, least significant
covers only addresses lower than this
FsFF FFB4 1 H ROM Size: Log2 of ROM size in bytes
FsFF FFB0 4 A Vendor ID (rightmost char)
'U' on TI hardware
FsFF FFAC A Vendor ID
'A' on TI hardware
FsFF FFA8 A Vendor ID
'I' on TI hardware
FsFF FFA4 A Vendor ID (leftmost char)
'T' on TI hardware
FsFF FFA0 8 B Board dependent info
FsFF FF9C B Board dependent info
FsFF FF98 B Board dependent info
FsFF FF94 B Board dependent info
FsFF FF90 B Board dependent info
FsFF FF8C A Rightmost char
Valid: MEM CPU SIB NPI?
FsFF FF84 A Middle char
FsFF FF80 A Leftmost char
FsFF FF7C 16 A Part number string
FsFF FF40 3 H Config Register Offset (most
significant) Addr = Fs000000 + offset
3C H "
FsFF FF38 H Config Register Offset (least
significant)
FsFF FF34 3 H Device Driver Code Offset (most
significant)
FsFF FF30 H "
FsFF FF2C H Device Driver Code Offset (least
significant)
FsFF FF28 3 H Diagnostic Code Offset (most significant)
FsFF FF24 H "
FsFF FF20 H Diagnostic Code Offset (least
significant)
FsFF FF1C 3 H Flag Register Offset (most significant)
FsFF FF18 H "
FsFF FF14 H Flag Register Offset (least significant)
FsFF FF10 1 B ROM Flags: Bit 0 = capable of selftest
Bit 1 = Nubus test candidate
Bit 2 = STBM candidate
Bit 3 = supports block moves
Bit 4 = system memrory
Bit 5 = needs power-fail
event
Bit 6 = NuBus test pointer
Bit 7 = reserved
FsFF FF0C 1 H ID ROM Format (incremented each time
the format is changed)
The document I have is for revision
03 - June 1, 1985
FsFF FF08 1 H Test Time = log2 of extended test
time in seconds
standard self test must be less than
20 seconds
STBM candidates must complete self
test in 10 seconds
FsFF FF04 1 H 0xC3, a known value for test purposes
FsFF FF00 1 B Resource Type: Bit 0 = memory
Bit 1 = boot source
(disk)
Bit 2 = LAN
Bit 3 = monitor (display)
Bit 4 = bootable
processor
Bit 5 = keyboard
Bit 6 = NVRAM
Bit 7 = has
sub-boards (optional daughter cards)
FsFF FEFC 3 H NVRAM Offset if NVRAM bit set in
resource type (most significant)
FsFF FEF8 H "
FsFF FEF4 H NVRAM Offset (least significant)
FsFF FEF0 H NVRAM Size if NVRAM bit set (Log2 of
NVRAM in bytes)
FsFF FEEC H Event Offset (required if bootable
processor) (most significant)
FsFF FEE8 H "
FsFF FEE4 H " (least significant)
FsFF FEE0 3 H STBM Event Offset (most significant)
FsFF FEDC H "
FsFF FED8 H " (least significant)
FsFF FED4 3 H Restart Event Offset (most
significant) Non-Maskable Event
FsFF FED0 H "
FsFF FECC H " (least significant)
FsFF FEC8 8 H Sub-board base address #7 (addr =
Fs000000 + 00(base)0000)
0xFF = unused
FsFF FEC4 H Sub-board base address #6
FsFF FEC0 H Sub-board base address #5
FsFF FEBC H Sub-board base address #4
FsFF FEB8 H Sub-board base address #3
FsFF FEB4 H Sub-board base address #2
FsFF FEB0 H Sub-board base address #1
FsFF FEAC H Sub-board base address #0
FsFF FEA8 3 H NuBus Test Address (code?) Offset
(most significant)
FsFF FEA4 H "
FsFF FEA0 H " (least significant)
FsFF FE9C Reserved.
thru
FsFF FE00
"Device driver code may optionally reside in a ROM on the board. The ROM
will normally be organized byte-wide, with one byte per word. The
address of the ROM will reside in the control space of the board. The
"Device Driver Offset" field of the ID ROM will point to the lowest
address of the portion of the ROM that contains the device driver code.
This address shall be call the "first byte" of the device driver. The
first byte will contain a -x01 which implies that the driver is written
in Diagnostic Engine code. The second byte will contain the number of
bytes per word to allow various ROM address implementations. The third
byte will contain the revision level of the driver code. The Diagnostic
Engine Specification should be consulted for further details on device
drivers; "
I don't think I have the Diagnostic Engine spec, but I'll look.
BTW, the STBM and DI approach is very similar to what Sun later adopted
as OpenBoot(tm - no doubt), even to using a Forth interpreter to run the
host-independent device driver code.
It's late. More another day.
-Steve
Nyef wrote:
>Hello all.
>
>I'm somewhat bored and killing time at work, and figured a few things out
>that may be interesting to some of you.
>
>For some reason I felt like looking for the text font used by the Explorer
>during startup. I figured that it had to be in ROM somewhere (since SSDN2
>talks about displaying messages on the screen before accessing disk or
>network devices). I also figured that it would be in the SIB config ROM,
>since that was the place that made the most sense.
>
>I eventually found an 8x12 font in the SIB config ROM starting at about
>offset 0x19ac or so. But that's not the interesting bit.
>
>While I was looking, I saw this in the ROM:
>
>000004a0: 1a 88 02 82 90 e8 f0 f0 f0 f0 88 1a 88 03 82 90 ................
>000004b0: e8 cc cc cc cc 88 1a 88 04 82 90 e8 aa aa aa aa ................
>000004c0: 88 1a 88 05 82 90 e8 55 55 55 55 88 1a 88 06 82 .......UUUU.....
>000004d0: 90 e8 33 33 33 33 88 1a 88 07 82 90 e8 0f 0f 0f ..3333..........
>000004e0: 0f 88 1a 88 08 82 90 e8 00 ff 00 ff 88 1a 88 09 ................
>000004f0: 82 90 c8 00 ff ff 88 1a 88 0a 82 90 88 00 88 1a ................
>
>What caught my eye was the two strings 'UUUU' and '3333'. These correspond
>to the values 0x55555555 and 0x33333333, respectively. Nearby, you can see
>the values 0xf0f0f0f0, 0xcccccccc, and 0x0f0f0f0f.
>
>This made me curious, so I started looking for patterns, and I found some:
>
> Each block of four bytes with a regular bit pattern is prefixed by a
>0xe8 byte.
>
> Each block is followed by 0x88, 0x1a, 0x88, <something>, 0x82, 0x90.
>The <something> has a low value, and appears in rising sequence.
>
>I figured this for a block of Diagnostic Engine Code, since it "feels"
>like code, and there's only one kind of code I remmeber reading about
>appearing in the configuration ROMs.
>
>What I figure so far is that it's a stack-based system using an 8-bit
>opcode. The opcodes I'm figuring on so far are:
>
> 0x88: Push an 8-bit literal constant from the next byte in the
>instruction stream.
>
> 0xa8: Push a 16-bit literal constant from the next two bytes in the
>instruction stream.
>
> 0xc8: Push a 24-bit literal constant from the next three bytes in the
>instruction stream.
>
> 0xe8: Push a 32-bit literal constant from the next four bytes in the
>instruction stream.
>
> 0x90: Some sort of memory set operation? Pops an address at the top
>of the stack, and a data value immediately below it, and stores the data
>value at the address?
>
> 0x82: Some sort of math / address computation operation? Pops an
>offset from the top of the stack and a base immediately below it, and
>pushes an address?
>
>The similarity between the four literal push opcodes suggests that there
>may be a common length encoding for other instruction groups that take
>lengths. Or I could be reading too much into far too little data.
>
>There also appears to be some sort of header at the start of a Diagnostic
>Engine Code block. At offsets 0 and 0x1400 of the SIB configuration ROM
>(which are indicated by the config area at the end as being the diagnostic
>and driver entry points, respectively) is the sequence 0x01, 0x04. The
>network config ROM (the 'NEC' board) has a signature of 0xe1, 0x04 at
>offset 0. I'm not sure what to make of these yet.
>
>The two NUPI ROM images are weirder. Each byte of the last 128 is doubled.
>And this is in both ROMs. I'm thinking that they might be high/low paired
>16-bit wide ROMs shared between the NuPI's 68k CPU and the Explorer NuBus
>requests. Certainly the low 128 bytes of each feels like a 68k interrupt
>vector table.
>
>Anyway, that's my report from a day's forced idleness. I almost hope that
>tomorrow is just as boring. ^_^
>
>---------------------------
>All programming can be viewed as an exercise.
>---------------------------
>Alastair Bridgewater
>e-mail: nyef@softhome.net
>
>http://lists.unlambda.com/mailman/listinfo/lispm-hackers
>
>
>