![[OpenBSD]](http://www.openbsd.org/images/smalltitle.gif){kind=small}
I have been working on the disk partition layout. I now have code able to understand a DG/UX VDM partition ``table''. At least a simple configuration, without any clustering. And my understanding of partition aggregates is a guess, which might be completely wrong (there is only one aggregate partition on the disk I am parsing, and I still can't get DG/UX to work anymore - but then I'm not trying too much).
Here is what my parsing code has to say about the 1GB disk found on the 4605:
found verification signature at alt offset version 0000 disk boot info: sig 1234abcd start 00000008 size 000001f4 version 00000001 sector 00000001: vdit portion type 14, 0007 sectors, next portion at 00000208 sector 00000208: vdit portion type 13, 0009 sectors, next portion at ffffffff vdit final size: 0x1e80 bytes vdit entry: type 03 size 32 subdriver: version 00 id 6ba42ddb name "vdmphys" vdit entry: type 03 size 32 subdriver: version 00 id 0c64a291 name "vdmpart" vdit entry: type 03 size 32 subdriver: version 00 id 3027e8f3 name "vdmaggr" vdit entry: type 04 size 3f instance: version 00 name "" subdriver id 6ba42ddb instance id 373a3aac export 0 vdmphys: version 00 mode 01 vdit entry: type 04 size 55 instance: version 00 name ".Bootstrap" subdriver id 0c64a291 instance id 373a3aac export 0 vdmpart: version 00 child instance id 373a3aac starting block 00000008 size 000001f4 remap instance id 00000000 vdit entry: type 04 size 55 instance: version 00 name ".Primary_Bad_Block_Table" subdriver id 0c64a291 instance id 373a3aac export 0 vdmpart: version 00 child instance id 373a3aac starting block 00000204 size 00000004 remap instance id 00000000 vdit entry: type 04 size 55 instance: version 00 name ".Remap_Area" subdriver id 0c64a291 instance id 373a3aac export 0 vdmpart: version 00 child instance id 373a3aac starting block 00000211 size 000000fc remap instance id 00000000 vdit entry: type 04 size 55 instance: version 00 name ".Secondary_Bad_Block_Table" subdriver id 0c64a291 instance id 373a3aac export 0 vdmpart: version 00 child instance id 373a3aac starting block 0000030d size 00000004 remap instance id 00000000 vdit entry: type 03 size 32 subdriver: version 00 id 1269c3d7 name "vdmremap" vdit entry: type 04 size 55 instance: version 00 name ".Remap" subdriver id 1269c3d7 instance id 373a3aac export 0 vdmremap: version 00 primary remap table instance id 373a3aac secondary remap table instance id 373a3aac remap area instance id 373a3aac vdit entry: type 04 size 55 instance: version 00 name "swap" subdriver id 0c64a291 instance id 373a3aac export 1 vdmpart: version 00 child instance id 373a3aac starting block 00000320 size 0003e800 remap instance id 373a3aac vdit entry: type 04 size 55 instance: version 00 name "root" subdriver id 0c64a291 instance id 373a3aac export 1 vdmpart: version 00 child instance id 373a3aac starting block 0003eb20 size 00027100 remap instance id 373a3aac vdit entry: type 04 size 55 instance: version 00 name "" subdriver id 0c64a291 instance id 373a3aac export 0 vdmpart: version 00 child instance id 373a3aac starting block 00065c20 size 0000bc50 remap instance id 373a3aac vdit entry: type 04 size 55 instance: version 00 name "" subdriver id 0c64a291 instance id 373a3aac export 0 vdmpart: version 00 child instance id 373a3aac starting block 00071870 size 00055730 remap instance id 373a3aac vdit entry: type 04 size 55 instance: version 00 name "" subdriver id 0c64a291 instance id 373a3aac export 0 vdmpart: version 00 child instance id 373a3aac starting block 000c6fa0 size 00018da0 remap instance id 373a3aac vdit entry: type 04 size 5b instance: version 00 name "usr" subdriver id 3027e8f3 instance id 373a3aac export 1 vdmaggr: version 00 count 03 stripe size 00000000 vdit entry: type 04 size 55 instance: version 00 name "swap1" subdriver id 0c64a291 instance id 373a3aac export 1 vdmpart: version 00 child instance id 373a3aac starting block 000dfd40 size 0003e800 remap instance id 373a3aac vdit entry: type 04 size 55 instance: version 00 name "cmmtmp" subdriver id 0c64a291 instance id 373a3aac export 1 vdmpart: version 00 child instance id 373a3aac starting block 0011e540 size 000d763b remap instance id 373a3aac vdit entry: type 00 size 00 sector 000001fc: vdit portion type 14, 0008 sectors, next portion at 00000311 sector 00000311: vdit portion type 13, 0009 sectors, next portion at ffffffff vdit final size: 0x2068 bytes bcmp of both vdit: 0
I need to put a few more hours of work into this (probably between 10 and 20), and we'll be able to support disks either as native OpenBSD, with or without an MBR partition table, or shared with DG/UX using a VDM layout, and a dedicated OpenBSD VDM partition. Of course this means we will also need a pdisk-like VDM partition tool.
I also need to work on a standalone boot loader. Unfortunately the PROM doesn't have documented interfaces to get data from a disk, so I need to write a stripped-down, polling only, scsi layer with an oosiop driver.
In the meantime, I have ported the MVME188 SMP implementation, to be able to use both processors on my 4605:
OpenBSD 4.7-current (GENERIC.MP) #9: Sat Apr 24 17:42:46 GMT 2010
miod@arzon.gentiane.org:/usr/src/sys/arch/aviion/compile/GENERIC.MP
real mem = 134217728 (128MB)
avail mem = 126148608 (120MB)
bootpath: 'dgen()' dev 0 unit 0 part 0
mainbus0 at root: 4600/530, cpuid 0x7930
cpu0: M88100 rev 0xb, 6 CMMU
cpu0: M88200 (16K) rev 0x9, split Icache, M88200 (16K) rev 0x9, split Dcache
cpu0: M88200 (16K) rev 0x9, split Icache, M88200 (16K) rev 0x9, split Dcache
cpu0: M88200 (16K) rev 0x9, split Icache, M88200 (16K) rev 0x9, split Icache
cpu1: M88100 rev 0xb, secondary, 6 CMMU
cpu1: M88200 (16K) rev 0x9, split Icache, M88200 (16K) rev 0x9, split Dcache
cpu1: M88200 (16K) rev 0x9, split Icache, M88200 (16K) rev 0x9, split Dcache
cpu1: M88200 (16K) rev 0x9, split Icache, M88200 (16K) rev 0x9, split Icache
syscon0 at mainbus0 addr 0xfff00000
nvram0 at syscon0 offset 0x80000 ipl 0: MK48T02
dart0 at syscon0 offset 0x82000 ipl 3: console
dart1 at syscon0 offset 0x82c00 ipl 3
oosiop0 at syscon0 offset 0xb0000 ipl 2: NCR53C700 rev 0, 33MHz
scsibus0 at oosiop0: 8 targets, initiator 7
sd0 at scsibus0 targ 0 lun 0: <IBM OEM, 0662S12 IQ, DG06> SCSI2 0/direct fixed
sd0: 1003MB, 512 bytes/sec, 2055035 sec total
sd1 at scsibus0 targ 2 lun 0: <SEAGATE, ST34371N, 0484> SCSI2 0/direct fixed
sd1: 4148MB, 512 bytes/sec, 8496884 sec total
st0 at scsibus0 targ 4 lun 0: <TANDBERG, TDC 3800, G03:> SCSI1 1/sequential removable
vme0 at syscon0 offset 0x85000 ipl 0
vme0: A16 0000-ffff
vme0: A24 000000-ffffff
vme0: A32 40000000-7fffffff
vme0: A32 90000000-fdffffff
le1 at vme0 a16 0x4000 a32 0x55900000 ipl 1 vec 0: address 00:00:77:82:fe:14
le1: 128 receive buffers, 32 transmit buffers
WARNING: SYSFAIL* ASSERTED
/dev/ksyms: Symbol table not valid.
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
boot device: <unknown>
root device: le1
nfs_boot: using interface le1, with revarp & bootparams
nfs_boot: client_addr=10.0.1.194
nfs_boot: server_addr=10.0.1.101 hostname=vezou
root on 10.0.1.101:/netboot/vezou/root
WARNING: bad date in nvram -- CHECK AND RESET THE DATE!
swap on 10.0.1.101:/netboot/vezou/swap
And I am now working on building a new snapshot...
After a few more hours of hacking, I am now running multiuser on the 4605 here. On-board Ethernet is not supported yet (it's a few hours of hacking ahead), so I figured I could use an Hawk Ethernet VME board (actually, I picked a MVME376 board which is a rebadged Hawk).
Unfortunately for me, it turns out that the metallic chassis of the small VME cage is too narrow and causes a contact with the board. The power supply is well engineered and shuts itself down before too much harm is done.
A sticker on the back of the machine advises to use an insulator, but the dual-SCSI VME board which was in the machine when I received it has one, and it does not seem to help reliably.
So I ended up putting a small sheet of paper between an edge of the board and the chassis, and it works!
Things are still rough: I am netbooting the kernel directly from the PROM (since the netboot code does not support the onboard Ethernet interface either yet), and of course it won't find its boot device yet. Anyway, here is the dmesg:
OpenBSD 4.7-current (GENERIC) #85: Wed Apr 21 19:17:43 GMT 2010
miod@arzon.gentiane.org:/usr/src/sys/arch/aviion/compile/GENERIC
real mem = 134217728 (128MB)
avail mem = 126152704 (120MB)
bootpath: 'dgen()' dev 0 unit 0 part 0
mainbus0 at root: 530/4600 series, cpuid 0x7930, sysid 373a3aac
cpu0: M88100 rev 0xb, 6 CMMU
cpu0: M88200 (16K) rev 0x9, split Icache, M88200 (16K) rev 0x9, split Dcache
cpu0: M88200 (16K) rev 0x9, split Icache, M88200 (16K) rev 0x9, split Dcache
cpu0: M88200 (16K) rev 0x9, split Icache, M88200 (16K) rev 0x9, split Icache
syscon0 at mainbus0 addr 0xfff00000
nvram0 at syscon0 offset 0x80000 ipl 0: MK48T02
dart0 at syscon0 offset 0x82000 ipl 3: console
dart1 at syscon0 offset 0x82c00 ipl 3
oosiop0 at syscon0 offset 0xb0000 ipl 2: NCR53C700 rev 0, 33MHz
scsibus0 at oosiop0: 8 targets, initiator 7
sd0 at scsibus0 targ 0 lun 0: <IBM OEM, 0662S12 IQ, DG06> SCSI2 0/direct fixed
sd0: 1003MB, 512 bytes/sec, 2055035 sec total
st0 at scsibus0 targ 4 lun 0: <TANDBERG, TDC 3800, G03:> SCSI1 1/sequential removable
vme0 at syscon0 offset 0x85000 ipl 0
vme0: A16 0000-ffff
vme0: A24 000000-ffffff
vme0: A32 40000000-7fffffff
vme0: A32 90000000-fdffffff
le1 at vme0 a16 0x4000 a32 0x55900000 ipl 1 vec 0: address 00:00:77:82:fe:14
le1: 128 receive buffers, 32 transmit buffers
WARNING: SYSFAIL* ASSERTED
/dev/ksyms: Symbol table not valid.
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
boot device: <unknown>
root device: le1
nfs_boot: using interface le1, with revarp & bootparams
nfs_boot: client_addr=10.0.1.194
nfs_boot: server_addr=10.0.1.101 hostname=vezou
root on 10.0.1.101:/netboot/vezou/root
swap on 10.0.1.101:/netboot/vezou/swap
I now need to figure out how to set up partitions, so that the PROM would be
able to run boot blocks. I know DG/UX uses a MBR scheme, but as you can see,
the boot partition has strange boundaries:
# fdisk sd0
Disk: sd0 geometry: 4119/5/99 [2055035 Sectors]
Offset: 0 Signature: 0x100
Starting Ending LBA Info:
#: id C H S - C H S [ start: size ]
-------------------------------------------------------------------------------
0: AB 0 2 59 - 0 2 58 [ 256: 0 ] MacOS X boot
1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
3: AB 4 0 69 - 130 1 64 [ 2048: 62465 ] MacOS X boot#
I made a copy of the disk for safety and backup purposes, with
dd if=/dev/rsd0c bs=32k | nc remote_machine 1234and performance was miserable (both because oosiop requires a lot of interrupts for its scripts processing, and 10Mbit/s le Ethernet):
32109+1 records in 32109+1 records out 1052177920 bytes transferred in 4032.577 secs (260919 bytes/sec)There were 11 spurious SCSI interrupts during the copy:
av530_intr: unclaimed extended interrupt, level 2, bit 17, mask 0x20000<SCSI0>and lots of interrupts counted:
$ vmstat -iz interrupt total rate irq7/abort 0 0 irq7/acfail 0 0 irq7/sysfail 1 0 irq3/dart0 50 0 irq3/dart1 0 0 irq2/oosiop0 160802 30 irq1/le1 1074939 202 irq5/clock 523643 98 Total 1759435 331
More work under the surface. I have reworked the bus_space interface and added bus_dma for non-VME devices; this allowed the on-board SCSI controller driver to attach and probe the bus:
scsibus0 at oosiop0: 8 targets, initiator 7 sd0 at scsibus0 targ 0 lun 0: <IBM OEM, 0662S12 IQ, DG06> SCSI2 0/direct fixed sd0: 1003MB, 512 bytes/sec, 2055035 sec total st0 at scsibus0 targ 4 lun 0: <TANDBERG, TDC 3800, G03:> SCSI1 1/sequential removableAll I need now is the clock and the onboard Ethernet interface to work...
After a long hiatus, I am working on the AViiON port again.
The 4605 machine found its way to my place sometime late 2008, and had been mostly collecting dust in my machineroom. The good surprise was that, unlike the 4300, its power supply accepts 220V AC, so I don't need to put it behind a 110/220V converter. The bad surprise was that the graphics board has been removed (or has never been present).
Both machines have their NOVRAM dead by now, so DG/UX no longer boots (well, it boots to the point of mounting root and filling /dev, and then nothing happens) and the only think I can do is to reset the machine (or send a software vulcan nerve pinch with the magic ctrl-] ctrl-[ ctrl-] ctrl-[ ctrl-] ctrl-[ sequence).
Fortunately netboot still works (I had to add a kluge to let the 4300 netboot, since the PROM will use 00:00:00:00:00:00 as the Ethernet address because of the NOVRAM failure, despite the address being stored in some form of stable storage (an EEPROM?) and not lost).
Here is what -CURRENT looks like on the 4300:
OpenBSD 4.7-current (GENERIC) #50: Sun Apr 18 15:01:20 GMT 2010
miod@arzon.gentiane.org:/usr/src/sys/arch/aviion/compile/GENERIC
real mem = 50331648 (48MB)
avail mem = 43933696 (41MB)
bootpath: 'inen() -z' dev 0 unit 0 part 0
mainbus0 at root: 100/200/300/400/3000/4000/4300 series, cpuid 0x7932, sysid f026120
cpu0: M88100 rev 0xb, 2 CMMU
cpu0: M88200 (16K) rev 0x9, full Icache, M88200 (16K) rev 0x9, full Dcache
syscon0 at mainbus0 addr 0xfff00000
nvram0 at syscon0 offset 0x80000 ipl 0: MK48T02
dart0 at syscon0 offset 0x82000 ipl 3: console
dart1 at syscon0 offset 0x82c00 ipl 3
le0 at syscon0 offset 0x8c000 ipl 1: address 08:00:1b:18:4a:1c
le0: 128 receive buffers, 32 transmit buffers
vme0 at syscon0 offset 0x85000 ipl 0
vme0: A32 10000000-7fffffff
vme0: A32 90000000-fdffffff
vme0: A24 00000000-00ffffff
vme0: A16 00000000-0000ffff
le1 at vme0 a16 0x4000 a32 0x55900000 ipl 1 vec 0: address 00:00:77:82:fe:14
le1: 128 receive buffers, 32 transmit buffers
vscsi0 at root
scsibus0 at vscsi0: 256 targets
softraid0 at root
boot device: le0
nfs_boot: using interface le0, with revarp & bootparams
nfs_boot: client_addr=10.0.1.194
nfs_boot: server_addr=10.0.1.101 hostname=vezou
root on 10.0.1.101:/netboot/vezou/root
swap on 10.0.1.101:/netboot/vezou/swap
The next step was to tinker with the 4605. Of course this one has the dreaded 6:1 CMMU combination, for which no documentation is available. So I wrote basic support for this setup, and eventually reached this state:
Jp#0/SCM>b dgen()
Booting dgen()
Local Ethernet address is 08:00:1B:33:14:30
Local Internet address is 10.0.1.194, or 0A0001C2 hex.
Trying server at 10.0.1.101, or 0A000165 hex for TFTP transfer.
CPU0 is associated to 6 MC88200 CMMUs
CPU1 is associated to 6 MC88200 CMMUs
[ no symbol table formats found ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2010 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 4.7-current (GENERIC) #61: Sun Apr 18 21:25:16 GMT 2010
miod@arzon.gentiane.org:/usr/src/sys/arch/aviion/compile/GENERIC
real mem = 134217728 (128MB)
avail mem = 126234624 (120MB)
bootpath: 'dgen()' dev 0 unit 0 part 0
mainbus0 at root: 530/4600 series, cpuid 0x7930, sysid 373a3aac
cpu0: M88100 rev 0xb, 6 CMMU
cpu0: M88200 (16K) rev 0x9, split Icache, M88200 (16K) rev 0x9, split Dcache
cpu0: M88200 (16K) rev 0x9, split Icache, M88200 (16K) rev 0x9, split Dcache
cpu0: M88200 (16K) rev 0x9, split Icache, M88200 (16K) rev 0x9, split Icache
syscon0 at mainbus0 addr 0xfff00000
nvram0 at syscon0 offset 0x80000 ipl 0: MK48T02
dart0 at syscon0 offset 0x82000 ipl 3: console
dart1 at syscon0 offset 0x82c00 ipl 3
vme0 at syscon0 offset 0x85000 ipl 0
vme0: A32 40000000-7fffffff
vme0: A32 90000000-fdffffff
vme0: A24 00000000-00ffffff
vme0: A16 00000000-0000ffff
WARNING: SYSFAIL* ASSERTED
CPU 0 Reset Exception
R00-05: 0x00000000 0x001f28a8 0x0064ef40 0x00060000 0x0064ef60 0x00000003
R06-11: 0x00000000 0x00000004 0xfff8e000 0x00209488 0x00000000 0x00000000
R12-17: 0x001f4160 0x00260000 0x00270000 0x00260000 0x00200000 0x00250000
R18-23: 0x00260000 0x00260000 0x00250000 0x00260000 0x00240000 0x00262e98
R24-29: 0x00200fd0 0x00201594 0x00000000 0x00000001 0x00200000 0x00200000
R30-31: 0x07ffaff0 0x00200f60
sxip 1f8e52 snip 1f8e5e sfip 1f8e72
fpsr 1dec48 fpcr 260000 epsr 800003f0 ssbr 0
fpecr aaaaaaaa fphs1 250000 fpls1 1f89cc fphs2 0 fpls2 1f33a4
fppt 1f3318 fprh 1000 fprl 0 fpit 0
vector 0 mask aaaaaaaa flags 4 scratch1 10a8 cpu 0x0
panic: unrecoverable exception 0
Stopped at 0x1dae18: tb0 0, r0, 0x84
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb>
The reset exception is actually a intentional NULL function pointer
dereference, when initializing the clock (this board needs different clock
routines to be written).
Note the lack of SCSI and Ethernet drivers at the moment. SCSI should be quite easy (but I need to write code for the DMA controller), Ethernet will be slightly more difficult.
The developer proxy has received the 4605. Although USPS destroyed the packaging, the machine inside survived. As expected, it has two processors. And it has a nice 128MB of memory. I'm looking forward to the machine to cross the atlantic, but this will wait for the next month.
I spent some time chasing a nonexisting bug... netboot was horribly slow, plugging the machine to another hub fixed it. Grr.
For some reason the onboard interface stops working after a while. It might need a periodic reset (I have some machines with old LANCE chips which do). I'll look further into this once I'll be able to boot from disk. In the meantime I am using a MVME376 card as the main interface under OpenBSD (but I am still booting my kernels from the DG/UX disk).
The long-awaited kernel bowels rewrite to make the code as board-independent as possible is almost complete, I still need to clean a few leftovers in the vme driver, and then plugging another board support code (such as the model 530 code, hint, hint) will be trivial.
Speaking of which... I found a model 4605 on eBay. Exactly what I was looking for, since it's a 530 design with graphics! It will take a few weeks for the machine to reach me (it did not reach the developer I am using as a US proxy yet), but it will help immensely, if the machine survives the travel.
My priority now, after the vme driver changes are completed, is to get the AIC-6250 SCSI controller to work in PIO mode. Once this works, I'll add DMA support. The DMA engine is very similar to the one used on hp300, and I'll probably borrow its design. Then it will be time to bake a snapshot...
The clock interrupt issue was trivial to fix, so the kernel went up to ask for the root device. And then... THE PAIN! The internal speaker went full power, with a healthy sound a bit too aggressive for my ears. I can't believe Chris did not complain about it on his 410... or maybe his speaker was dead, or not initialized the same way by the PROM.
Thanks to the documentation, it was a matter of minutes to silence the naughty speaker. And there was much rejoicing:
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2007 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 4.2-current (GENERIC) #8: Wed Dec 12 20:24:13 GMT 2007
miod@ramade.gentiane.org:/usr/src/sys/arch/aviion/compile/GENERIC
real mem = 50266112
avail mem = 44154880 (10780 pages)
bootpath: 'sd(insc(),0)bsd.ecoff -s' dev 0 unit 0 part 0
mainbus0 at root: 100/200/300/400/3000/4000/4300 series, cpuid 0x7932, sysid
f026120
cpu0: M88100 rev 0xb, 2 CMMU
cpu0: M88200 (16K) rev 0x9, full Icache, M88200 (16K) rev 0x9, full Dcache
syscon0 at mainbus0 addr 0xfff00000
nvram0 at syscon0 offset 0x80000 ipl 0: MK48T02
dart0 at syscon0 offset 0x82000 ipl 3: console
dart1 at syscon0 offset 0x82c00 ipl 3
le0 at syscon0 offset 0x8c000 ipl 1: address 08:00:1b:18:4a:1c
le0: 32 receive buffers, 8 transmit buffers
vme0 at syscon0 offset 0x85000 ipl 0
vme0: A32 10000000-7fffffff
vme0: A32 90000000-fdffffff
vme0: A24 00000000-00ffffff
vme0: A16 00000000-0000ffff
le1 at vme0 a16 0x4000 a32 0x55900000 ipl 1: address 00:00:77:82:fe:14
le1: 128 receive buffers, 32 transmit buffers
/dev/ksyms: Symbol table not valid.
softraid0 at root
boot device: <unknown>
root device: le0
nfs_boot: using interface le0, with revarp & bootparams
nfs_boot: client_addr=10.0.1.194
nfs_boot: server_addr=10.0.1.101 hostname=vezou
root on 10.0.1.101:/netboot/vezou/root
WARNING: clock gained 1593 days -- CHECK AND RESET THE DATE!
swap on 10.0.1.101:/netboot/vezou/swap
Got the 4300. Took me a while to unpack it and check it was still in good condition. Of course, the NVRAM is dead, which makes netbooting quite difficult (the ethernet address is 00:00:00:00:00:00 despite the correct address being known and printed at cold boot time), as I couldn't find the ``write enable'' jumper on the motherboard yet (jumper and chip layout is completely different than 300 series).
So I ended up copying an a2coff'ed bsd kernel to the disk, from DG/UX, and here is the result:
SCM>b sd(insc())bsd.ecoff
Booting sd(insc())bsd.ecoff
DG/UX System Release 5.4.2 Bootstrap
Loading image
.................................................................CPU0 is
associated to 2 MC88200 CMMUs
[ no symbol table formats found ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2007 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 4.1 (GENERIC) #1: Thu Mar 15 02:56:54 GMT 2007
root@ramade.gentiane.org:/usr/src/sys/arch/aviion/compile/GENERIC
real mem = 50266112
avail mem = 41385984 (10104 pages)
using 639 buffers containing 2617344 bytes of memory
' dev 0 unit 0 part 0bsd.ecoff
mainbus0 (root): 100/200/300/400/3000/4000/4300 series, cpuid 0x7932, sysid
f026120
cpu0: M88100 rev 0xb, 2 CMMU
cpu0: M88200 (16K) rev 0x9, full Icache, M88200 (16K) rev 0x9, full Dcache
syscon0 at mainbus0 addr 0xfff00000
nvram0 at syscon0 offset 0x80000 ipl 0: MK48T02
dart0 at syscon0 offset 0x82000 ipl 3: console
dart1 at syscon0 offset 0x82c00 ipl 3
le0 at syscon0 offset 0x8c000 ipl 1: address 08:00:1b:18:4a:1c
le0: 32 receive buffers, 8 transmit buffers
vme0 at syscon0 offset 0x85000 ipl 0
vme0: A32 10000000-7fffffff
vme0: A32 90000000-fdffffff
vme0: A24 00000000-00ffffff
vme0: A16 00000000-0000ffff
le1 at vme0 a16 0x4000 a32 0x55900000 ipl 1: address 00:00:77:82:fe:14
le1: 128 receive buffers, 32 transmit buffers
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
av400_intr: spurious interrupt, level 5, vec 0x56, mask 0x200000<CIOI>
panic: av400_intr: broken interrupt behaviour
Stopped at 0x1c2728: tb0 0, r0, 0x84
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb>
The spurious interrupt 5 mean that the clock interrupts are not handled
correctly. That's my first bug to fix... after I get some sleep! Oh, and the
boot commandline doesn't get printed correctly, I'll need to check it as well.
And update to a more recent kernel.
We found a working model 4300 on eBay. 48MB, single 88100, similar to the 400 series which were initially supported. Since the sender will not ship worldwide, the machine will first go to another developer, who will have it shipped to me, so I don't know when I'll get it, but it's a major incentive to do some serious work on the aviion port again (even though everyone seems to have moved to a 530 model...)
I am back with a complete OpenBSD/aviion snapshot, and some spare time to spend on this port again. But still no hardware...
New kernel, lots of under-the-radar work to support model 530, not much on the AV400 SCSI front.
New netboot binary which will really recognize the network interface, now (it has been commited to the tree).
Machines list updated.
The ILACC vs LANCE problem changes a bit... It turns out the 530 is a different design than the 5000, and its ILACC ethernet is at a different address than the 400's LANCE, so no confusion is possible. However, the real 5000 will need this problem solved. Fear not, I found a semi-decent way to tell the chips out, so the LANCE driver will not attach to ILACC... and the ILACC driver is not there yet.
Collecting information on model 530. This one shares the 5000 design, so I need a reliable way to tell the 5000 design apart from the 400 design. I think I have something decent for this.
The next stop will be the on-board Ethernet. On series 400, this uses the AMD LANCE (79C90), which is a 16bit chip. On series 5000, this use the AMD ILACC (79C900), which can either work in LANCE compatibility mode, or in a faster but incompatible 32bit mode. By default it runs in 16bit mode, until one performs a 32 bit access to its data register. Guess what? When the 400 series were designed, the ILACC did not exist... and the design forces the software to access the LANCE as 32 bit bus transaction, always (with the extra 16 bits ignored). So if one were to attempt running the current code on a 5000 design, simply trying to check if the Ethernet controller is present will switch it into 32 bit mode... I have to find a simple way to tell LANCE from ILACC apart, and then I'll port the existing pcn driver (which is currently PCI-only).
Chris confirms the VME Hawk Ethernet board is recognized now.
netboot, network-based bootloader, is available. Currently only able to use the on-board Ethernet interface, it can load any file from the network, and will correctly zero fill the bss section, as well as load its symbols if there are any.
New kernel with VME glue fixes, the Hawk Ethernet board should attach and work now.
I eventually found the datasheet for the AIC-6250 SCSI chip; a driver is on its way as well.
Running multiuser on series 400!
The latest AV400 kernel found its root device and went multiuser. It will not shutdown properly, however, but I have a fix for this coming.
Later that day: after renaming the port to OpenBSD/aviion, it has been commited to the OpenBSD main repository, and development will continue there from now on. The AV400 kernel disappears, future work will stick to the GENERIC kernel from now on. Next step in the todo-list: try and get the SCSI chip to work!
Kernel reached the ``root device'' prompt on AV400, but bugs in the interrupt code cause a panic as soon as interrupts are enabled.
dmesg with some debug information left:
[PROM banner at 0x27ff4c4: ]
CPU0 is associated to 2 MC88200 CMMUs
CPU1 is associated to 2 MC88200 CMMUs
[ no symbol table formats found ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2006 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 3.9-current (AV400) #65: Sun May 7 22:26:59 GMT 2006
miod@arzon.gentiane.org:/usr/src/sys/arch/dg88k/compile/AV400
real mem = 41943040
avail mem = 34910208 (8523 pages)
using 537 buffers containing 2199552 bytes of memory
[Boot device information: args 0x27ff37c (inen()) dev 0 unit 0 part 0]
mainbus0 (root): , cpuid 0x7908
cpu0: M88100 rev 0xb, 2 CMMU
cpu0: M88200 (16K) rev 0x9, full Icache, M88200 (16K) rev 0x9, full Dcache
syscon0 at mainbus0 addr 0xfff00000
nvram0 at syscon0 offset 0x80000 ipl 0: MK48T02
dart0 at syscon0 offset 0x82000 ipl 3: console
le0 at syscon0 offset 0x8c000 ipl 1: address xx:xx:xx:xx:xx:xx
le0: 32 receive buffers, 8 transmit buffers
vme0 at syscon0 offset 0x85000 ipl 0
vme0: A32 10000000-7fffffff
vme0: A32 90000000-fdffffff
vme0: A24 fe000000-feffffff
vme0: A16 ffff0000-ffffffff
boot device: <unknown>
root device :
I have just realized that series 500 (500, 530) is 88100-based, and not 88110-based as I was thinking. My rule to figure out whether a model is 88100 or 88110 based thus becomes:
EDIT: This logic is wrong. I know better since then.
New kernel images which will talk to the serial port directly after the kernel goes virtual.
Kernel runs up to the end of pmap_bootstrap(), then hangs at the next printf() call.
I suppose this is because I need to map more than 128KB of PROM for the PROM services to keep working, despite what the documentation says. Or it could be that the PROM does not work at all with the MMU enabled, so I would have to disable interrupts and disable the MMU before invoking it, but this would be so wrong I doubt this is the case (after all, Motorola's BUG PROM does not have this problem, but is 512KB on MVME188...)
If I remain stuck at this point, I will change the console strategy and force using the DART serial ports directly, instead of using the PROM services until all the devices have been probed, as done on mvme88k - this way if the kernel panics, at least we'll have a chance of seeing its last messages.
The kernel printed its first line, then died horribly while I was attempting to access an MVME188 register as a byte - looks like the DG adaptation of the MVME188 design needs 32 bit accesses everywhere, even for registers which only have 8 significant bytes. But then, the particular register might just be missing, so I have added a check around this and uploaded new binaries, and we'll see how they behave.
Chris tested and found the hard way my first stupid bug: although I made sure I had the console information set up before doing my first printf(), I did not have all the necessary board-dependent function pointers set for the kernel output mutex to be held (on m88k, mtx_enter() invokes raiseipl() which in turn invokes a board-dependent function pointer).
I have started to work on VME support as well; this is a new implementation of the VME core attachment and userland device nodes, which will also replace the mvme88k implementation soon, and mvme68k later.
I expected the PROM to use a zero VBR, but it doesn't - I can only rely on the high address mapping at 0xfffc0000. Fixed the PROM (SCM) invocation code accordingly (swapping the VBR on the fly).
But then, this allows relocating the kernel down to zero, since there is no PROM space underneath.
Baked a simple a.out->ECOFF converter which should be enough to get the PROM to like my binaries. Now eagerly waiting for volunteers to try them (-: