NeXT Cube Motherboard Boot Code?

Folks,

Just wondering if anyone here has bothered to disassemble the boot EEPROM on a 68030/040 motherboard?  It could be useful, for example, if one wanted to replace the 68040 by a 68060.

-- josé k.

Actually I meant to ask you about that yesterday (it was yesterday, right?!) I've been trying to find the ROM on a black box, but I think the MMU has hidden it....

On 68000's If I remember correctly the first word at 0x00000000 is the location of where they should put their code pointer & 0x00000004 is the location of the stack pointer... I would need access to a black box to talk to /dev/mem & /dev/kmem to see what is going on, if its not hiding it to pull some rom images...  Or try netBSD as I imagine it wouldn't feel the need to hide stuff....

All my next gear is now in the hands of FedEX, so I'm just waiting for it to arrive...

I could just whip of a super simple c program to check, or actually you could just use dd....

try this from any black box:

dd if=/dev/ram of=initalcodepointer bs=1 count=1
dd if=/dev/ram of=initalstackpointer bs=1 count=1 skip=1

I just did this on a x86 nextstep (under qemu)

dd if=/dev/ram of=rom bs=1 count=65536 skip=983040

And yes, I did get the rom code.. However it takes dd *FOREVER* to count that high! :)

c would be faster, but at the least you could see where the rom / ram is located in the memory map....

I'm trying to remember why I didn't do this a long time ago....

Thank you very much for all the goodies. Did you ever find the sealed optical drive?

-- josé k.

Quote from: "korneluk"Thank you very much for all the goodies. Did you ever find the sealed optical drive?

-- josé k.

Sadly no... :|  It seems to have 'been lost in the mysts of time'...  Although I did find softpc 3.0 (with windows!.. so it proudly claims) on CD.. 68k only though.'

Quote from: "neozeed"...  Although I did find softpc 3.0 (with windows!.. so it proudly claims) on CD.. 68k only though.'

WANT! I think I only have SoftPC 2.0 or something.. Wanna trade or sell? (If sell, it'll be a few weeks.... *sigh*)

http://sourceforge.net/projects/bsd42/

That is the project I was mentioning yesterday... I've built a 'windows' installable copy of the old Berkley UNIX's & SIMH.  Reno even works with networking!

Has anyone tried dumping out those 2 words on a black box, via dd?

Oh and here is TME...

http://people.csail.mit.edu/fredette/tme/

An 030 cube rom would be best, as this thing emulates an 020, complete with MMU & basic 688881.

I have a ROM image here somewhere. I pulled the chip and dumped it (I've been working on an emulator).

Quote from: "gtnicol"I have a ROM image here somewhere. I pulled the chip and dumped it (I've been working on an emulator).

Far out, any luck?  Memory maps, anything???

:D

We have ROM images in the NeXTfiles archive.  These files are placed here with permission from Apple, Inc.  :D

http://www.nextcomputers.org/NeXTfiles/Software/ROM_Files/

I'll have more soon.

Enjoy

Quote from: "Nitro"We have ROM images in the NeXTfiles archive.  These files are placed here with permission from Apple, Inc.  :D

http://www.nextcomputers.org/NeXTfiles/Software/ROM_Files/

I'll have more soon.

Enjoy

so cool!  I'll have to hope they map at 0x00000000 ... And you got AAPL permission?  Thats awesome...!

Hmmm the 030 rom seems scrambled some how.. I tried flipping it (big to little) and no dice, all garbage... the 2 offsets I get are:

one 4093D6
two 404A87

which doesn't make much sense for a memory map....

Now reading the v41 rom which does have ascii I can make some sense out of...

one 4093D6
two 404A87

I took a peek at v66, and it also uses the same offsets.. interesting.  Since my cube is in transit does anyone have a high resolution picture of a mother board where you can actually read the chips?  Perhaps we can idenify what is there... Also schematics for *any* motherboard?

You know ok, maybe my offset's aren't off... Does anyone have a memory map on the NeXT?  I get the feelign that if those offsets are correct, then there must be some small ram or even ram/rom combination at that offset ( 0x00400000)..

I'm not claiming to be captain 680000 here, but I would imagine the roms would be at some kind of even offset... But then who knows, maybe they used weird offsets....


Ok here is the ASCII table for those who are interested....

NMIpwrfailsystimerenetTXDMAenetRXDMAscsiDMAopticalDMAprinterDMAsoundoutDMAsoundinDMAsccDMAdspDMAm2rDMAr2mDMAsccrpibusrtcoptical
scsiprinter
enetTX
enetRX   soundrunphone dspvideomonitorkybd/mousepowersoftint2
softint1 intrmask scr1 ÝsidÑDMArevÉCPUrevÇvmssÅmmssÁccms scr2  DSPresetDSPblockDSPunpkDSPbDSParpisoftint2softint1Õmem256K/4MÑmem1M/4Mtimeripl7ÍROMwait
rtdata
rtclk   rtceˆROMovly
ekgLED boot command DRAM tests perform power-on system test    sound out tests    SCSI tests    loop until keypress    verbose test mode boot extended diagnostics serial port A is alternate console allow any ROM command even if password protected allow boot from any device even if password protected allow optical drive #0 eject even if password protected enable parity checking if parity memory is present UD UP SD SP cpu no 16MB nibble mode 4MB nibble mode 1MB nibble mode illegal 16MB page mode 4MB page mode 1MB page mode (illegal) 16MB parity nibble mode 4MB parity nibble mode 1MB parity nibble mode 16MB parity page mode 4MB parity page mode 1MB parity page mode (illegal) 8MB of page mode 2MB of page mode 8MB of parity page mode 2MB of parity page mode en Testing
system ... Main Memory Configuration Test Failed

Main Memory Test Failed

VRAM VRAM Memory Test Failed
CPU MC68040  %d MHz, memory %d nS
Backplane slot #%d
Ethernet address: %x:%x:%x:%x:%x:%x
Warning: non-volatile memory is uninitialized.
Memory sockets %d-%d configured for %s SIMMs but have %s SIMMs installed.
Memory sockets %d and %d configured for %s SIMMs but have %s SIMMs installed.
Memory size %dMB , parity enabled
can't continue without some working memory


System test failed.  Error code %x.


System test passed.
diagnostics -h No default boot command.
  bogus stack frame
Exception #%d (0x%x) at 0x%x
NeXT> New password:  Retype new password:  Mismatch - password unchanged
a d  Memory sockets %d-%d have %s SIMMs installed (0x%x-0x%x)
Memory sockets %d and %d have %s SIMMs installed (0x%x-0x%x)
Old error code: %x
Last error code: %x
Function code %d (%s)
default input radix %d
Huh?
System
test
failed Password:  Sorry
usage error, type "?" for help
%s%s:  %08x?  %b?  %s?  must be < %d chars long
yes  %s?  There must be a disk inserted in drive #0 before you can set this option
%08x %04x %02x %x:  ?  %s
DRAM error type %d
Check socket (0 is the first socket):  %d  
Memory error at location: %x
Value at time of failure: %x
Coupling dependent memory fault!
One or more SIMM at memory bank %d is bad
Note: bank 0 is the first bank
SCSI DMA intr?
Sound Out Over Run Interrupt.

Sound Out DMA error!
Bank %d has mixed mode SIMM's
All of the SIMMs must be parity SIMMs if you want parity to work.
Testing the FPU , SCC , SCSI , Enet , ECC , RTC , Timer , Event Counter , Sound Out

Starting Extended Self Test...
Extended SCSI Test

Press and hold any key to exit self test . Check socket (0 is the first socket): %d

One or both SIMMs in memory bank %d are bad
Bank %d has mixed size SIMMs.

VRAM failure at 0x%x:  read 0x%08x, expected 0x%08x, bad bits %08x, IC U%d
VRAM failure at 0x%x:  read 0x%08x, expected 0x%08x, bad bits %08x, IC U%d
Loading
from
disk ... Please
insert
disk Please
flip
disk Bad
disk SCSI
error Loading
from
network ... Bad
network Loading
from
floppy ... Ethernet (try thin interface first) tp Ethernet (try twisted pair interface first) sd SCSI disk od Optical disk fd Floppy disk Boot command: %s
Default boot device not found.
(%d,%d,%d) boot %s%s%s
Usage: b [device[(ctrl,unit,part)] [filename] [flags]]
boot devices:
   %s: %s.
unknown binary format
Booting %s from %s
octet
tftp: %s
%s(%d,%d,%d)%s %s()%s tftp: timeout
Requesting BOOTP information from %s boot NeXT  [OK]
 [timeout]
0123456789abcdef   0t 0x X L en_write: tx not ready
NeXT ROM Monitor %d.%d (v%d)
really power down?  Error during boot Didn't complete scstart: bad state software error parity error selection failed bus error target aborted fifo level target aborted2 msgin fifo level scintr program error SCSI command phase SCSI bad i/o direction SCSI unaligned DMA segment SCSI unaligned DMA SCSI msgout phase scmsgin: no current sd SCSI unexpected msg:%d
Unexpected msg scmsgin: no FUNCCMPLT sc: %s
SCSI Bus Hung
no SCSI disk
booting SCSI target %d, lun %d
dev blk len?
READ CAPACITY REQ SENSE waiting for drive to come ready bad dev blk size %d
READ sdcmd bad state: %d
%s:  Selection timeout on target
Failed, sense key: 0x%x
Target busy
Target disconnected
Driver refused command
sdfail bad state: %d
dma_list: bad alignment dma_cleanup: negative resid Bad label
No bootfile in label
dev blk len %d, fs sect %d
Can't load blk0 boot
Bad version 0x%x
Bad blkno
Bad cksum
short read
uncorrectable ECC error sector timeout media upside down no disk inserted PLL failed retry restore re-spin failed no optical disk
no valid disk label found
bad ctrl or unit number
read write erase command od%d%c: %s %s  (%s) (error #%d)  %d:0:%d
fd: RECALIBRATE FAILED
fd: CONTROLLER I/O ERROR
RECALIBRATE FAILED
No Floppy Disk Drive
No Floppy Disk Present
Floppy Disk not Formatted
Unknown Floppy Disk error (%d)
Floppy Disk not Initialized
fd_intr: BOGUS fvp->state FATAL RECALIBRATE RETRY Read Write fd%d: Sector %d(d) cmd = %s; status = %d: %s
Bad Controller Phase Controller hang fc: Controller Reset: %s
fd: Bogus density (%d) in fc_specify()
fc_send_cmd: Error sending command bytes  (%d)
fc_send_cmd: Error getting status bytes
dma_bytes_moved: DMA buf overflow

Ok, here's some ROM pics I have from when I ripped my ROMs a long time ago.  I used an EPROM burner to rip the "bin" files.  I don't know jack about what an offset is.  :)






And here's an original 030 ROM, version 1.0.  The first pic is of the top label, and the second pic is with the top label removed.





Hope this helps.  I'll try to get more ROM images made soon.  Also, refer to this thread for more info:

http://www.nextcomputers.org/forums/viewtopic.php?t=11

I'm going to look at an Amiga rom & a mac rom (again I'm assuming both have their roms mapped to 0x0.. ) but here is what I'm seeing... Oh and I think I goofed before with weird offsets...


#include <stdio.h>

struct S_rominfo
{
unsigned char one[4];
unsigned char two[4];
unsigned char vendor[3];
unsigned char unique[3];
unsigned char padding[8];
unsigned char CRC[4];
};

void rread(char *name);

void main(void)
{
rread("v41-next cube 68030.BIN");
rread("v59-next cube 68040.BIN");
rread("v65-next cube 68040.BIN");
rread("v66-next cube 68040.BIN");
}

void rread(char *name)
{
FILE *rom;
struct S_rominfo rominfo;

memset(&rominfo,0x0,sizeof(rominfo));
printf("\nOpening %s\n",name);
rom=fopen(name,"rb");
if(rom==NULL)
{return-1;}
printf("reading rom file.\n");
fread(&rominfo,sizeof(rominfo),1,rom);
fclose(rom);

printf("one %02X%02X%02X%02X\n",rominfo.one[0],rominfo.one[1],rominfo.one[2],rominfo.one[3]);
printf("two %02X%02X%02X%02X\n",rominfo.two[0],rominfo.two[1],rominfo.two[2],rominfo.two[3]);

printf("MAC %02X%02X%02X:",rominfo.vendor[0],rominfo.vendor[1],rominfo.vendor[2]);
printf(    "%02X%02X%02X\n",rominfo.unique[0],rominfo.unique[1],rominfo.unique[2]);

printf("CRC32 in rom %02X%02X%02X%02X\n",rominfo.CRC[0],rominfo.CRC[1],rominfo.CRC[2],rominfo.CRC[3]);
printf("\n\n");
}


Which gives me:


Opening v41-next cube 68030.BIN
reading rom file.
one 00000000
two 0000001E
MAC 000000:002F00
CRC32 in rom 000C4700



Opening v59-next cube 68040.BIN
reading rom file.
one 00000000
two 0100001E
MAC 00000F:0072FE
CRC32 in rom 307652E7



Opening v65-next cube 68040.BIN
reading rom file.
one 00000000
two 0100001E
MAC 00000F:00A634
CRC32 in rom 4B65F402



Opening v66-next cube 68040.BIN
reading rom file.
one 00000000
two 0100001E
MAC 00000F:00F302
CRC32 in rom 49730056



Which now frankly fits from what I had found from the NetBSD source code earlier ...

from cpu.h  http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/next68k/include/cpu.h?rev=1.40&content-type=text/x-cvsweb-markup

#define NEXT_RAMBASE  (0x4000000) /* really depends on slot, but... */
#define NEXT_BANKSIZE (0x1000000) /* Size of a memory bank in physical address */

#define NEXT_P_EPROM_BMAP (NEXT_SLOT_ID+0x01000000)
#define NEXT_P_EPROM_SIZE (128 * 1024)

We are going to 'assume' here that the slot that the motherboard is in 0, so we should start our code (the rom) in location 0x0100001E .  This makes some sense, and our stack pointer is at 0x0.. wierd.  I assume the rom first goes hunting for memory, and moves the stack pointer somewhere sane.  Somewhere around here I have a crc32 procedure I'll find and verify the CRC.  Also it would appear that the 030 rom dump is corrupt, or the 030 uses a vastly different memory map then the 040.  That is entirely possible, however at the moment I'm leaning to a corrupt read, because there is no printable ascii in the 030 image, even with a byteswap.....

Hmm, looking at the 68030 ROM's contents, something must definitely have gong wrong when reading the EPROM. 64 kB size is ok (since it's a 27512 in the picture - 512 kBits), but only bytes at positions 0, 3, 4, 7, 8, 11, 12 and 15 (mod 16) are non-zero.

I was wondering if the 68030 Cube used more than one eight-bit-wide ROM, but the board photo at http://www.channelu.com/NeXT/Black/68030/i/68030-1500x1480.jpg indicates that the ROM is really only byte-wide. Unfortunately, I don't own a 68030 Cube board, mine has been upgraded to 68040 non-turbo.

Btw., I'm also thinking about writing an emulator for quite some time now. I think using the ST/Falcon emulator Aranym as a base (http://aranym.org/) would be interesting, since it provides full JIT 68040 emulation.

-- cuby

It's quite possible that the 030 ROM is corrupt.  My EPROM burner requires a change in dip switch settings as well as different software settings to read/burn the smaller 512k chips.  I could have easily made a mistake while doing that.  I'll get things set up this week and re-read the chip.  I'll also take a look through my 030 motherboards because I don't think the v1.0 ROM is the latest one.  IIRC, the latest version is 1.1 or 1.2.

The only ROM that I've tested so far is the v74.  I'm using one of those in my Turbo Colorstation with a custom MAC address and it works fine.

Ok, I reread the 68030 ROM chip and the file appears to be valid.  I did find one 030 motherboard that had a v1.2 ROM, so I created that file as well.  They can be found here:

http://www.nextcomputers.org/NeXTfiles/Software/ROM_Files/68030/

Quote from: "Nitro"Ok, I reread the 68030 ROM chip and the file appears to be valid.

68k all boot from address 0x00000000.  However, the NeXT custom bridge controller remaps a substantial area of addresses.  My notes match neozeed's assumption that the slab address area is 0x010001E.  If you put a logic analyzer on the bus, you'll also see that there's some "boot code" hard wired into the bridge controller as you'll see a few fetches before you get the double bus fault if you pull the ROM.

There's no reason from the binary perspective that you couldn't replace an 030 with an 040, or an 040 with an 060.

Is there still anyone interested in working on this project?  I see a whole bunch of 68060 CPUs on ebay, it would be awesome to get them working on our cubes!

I'm somewhat interested, though I'm more interested on continuing work on an emulator...

Quote from: "sdinet"Is there still anyone interested in working on this project?  I see a whole bunch of 68060 CPUs on ebay, it would be awesome to get them working on our cubes!

Thought there was a binary compatibility issue with the '060.  Might be restricted to kernel-mode instructions but there was an issue, I thought.

Very interesting thread... I.ll play a bit with those roms...

I thought the 060 was only like ~65% compatible with 040s?

It's not totally compatible. Plus the fact that the 040 is 5V and the 060 is 3.3V you'd have to create an adapter board to do it with a voltage regulator to convert 5V -> 3.3V.

Quote from: "degs"

Quote from: "Nitro"Ok, I reread the 68030 ROM chip and the file appears to be valid.

68k all boot from address 0x00000000.  However, the NeXT custom bridge controller remaps a substantial area of addresses.  My notes match neozeed's assumption that the slab address area is 0x010001E.  If you put a logic analyzer on the bus, you'll also see that there's some "boot code" hard wired into the bridge controller as you'll see a few fetches before you get the double bus fault if you pull the ROM.

There's no reason from the binary perspective that you couldn't replace an 030 with an 040, or an 040 with an 060.

Any chance you could share a bit more detail on this:

Can you provide a list of address mappings - it doesn't have to be complete, any info is welcome.

Are you able to dump some of the boot code from the bridge - even just the locations of the fetches would be useful to know.

Quote from: "neozeed"try this from any black box:

dd if=/dev/ram of=initalcodepointer bs=1 count=1
dd if=/dev/ram of=initalstackpointer bs=1 count=1 skip=1

I know this is somewhat academic, because (at least a lot of) ROM dumps have been placed online, but I have been experiencing strange behaviour on one of my cubes and wondered if I have a bad ROM. So, I ran
dd if=/dev/kmem of=ROM.binincluding various permutations of bs, skip, etc. On a NeXTstation TurboColor with a 3.3 (v74) ROM, this produces a valid ROM dump. On a NeXTcube ('040 25MHz) with a 2.5 (v66) ROM, it produces only gibberish - indeed, it seems impossible to access the ROM via either /dev/kmem or /dev/mem, although any dump of that device starting from an address with sufficiently many low bits cleared, produces a 128kB file.

I guess this has something to do with the cube remapping the ROM to an address space which is inaccessible, while the station does not do so (one might expect the reverse, since the station is more modern, but ...). But does anyone know what more precisely is going on?