Re: next68k: current issues

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

Hi,

> I am the maintainer of Previous (NeXT Computer Emulator).
> Mr. Engel might have already introduced me. We are trying
> to make NetBSD boot on emulated NeXT hardware and have run
> into some issues. I hope to have sorted out the problems
> that were inside Previous itself. Some issues left seem to
> be inside NetBSD:

Thank you for your reports!

As I wrote on this list before, I've just resurrected my slab
in the last January and notices there are so many regressions.

I'm still working to fix them and motivated by your info :-)

> 1. Turbo VRAM: 
> Obviously NetBSD uses the same addresses for Turbo NeXTcube
> and NeXTstation as for the non-Turbo ones. In fact the Turbos
> use different locations for their VRAM: 0x0C000000 (same for
> color and monochrome, only sizes vary)
> If I hack Previous to have the VRAM at that location, NetBSD
> boots on all Turbo systems (color and monochrome).

Ok, fixes for this problem should be trivial.

However currently framebuffer kernel virtual address regions
are allocated statically (both mono and color) during early startup
in pmap_bootstrap.c:

 https://github.com/NetBSD/src/blob/338f5e0c6c82c4e90272a48cbcdbcc0e071bc3c2/sys/arch/next68k/next68k/pmap_bootstrap.c#L426-L445

Maybe we should reorganize them to handle these three cases,
rather than blindly allocate all regions.

If you could try to compile own kernel, could you check
if a custom kernel work with modifined COLORBASE and COLORTOP
(or MONOBASE and MONOTOP if your emulates NeXT_TURBO_MONO)
work on your emulator?

---
diff --git a/sys/arch/next68k/include/cpu.h b/sys/arch/next68k/include/cpu.h
index 63532eda6e59..8fb61bf54a3e 100644
--- a/sys/arch/next68k/include/cpu.h
+++ b/sys/arch/next68k/include/cpu.h
@@ -314,8 +314,8 @@ int	nmihand(void *);
 #define	INTIOTOP	(0x02120000)
 #define MONOBASE	(0x0b000000)
 #define MONOTOP		(0x0b03a800)
-#define COLORBASE	(0x2c000000)
-#define COLORTOP	(0x2c1D4000)
+#define COLORBASE	(0x0c000000)
+#define COLORTOP	(0x0c1D4000)
 
 #define NEXT_INTR_BITS \
 "\20\40NMI\37PFAIL\36TIMER\35ENETX_DMA\34ENETR_DMA\33SCSI_DMA\32DISK_DMA\31PRINTER_DMA\30SOUND_OUT_DMA\27SOUND_IN_DMA\26SCC_DMA\25DSP_DMA\24M2R_DMA\23R2M_DMA\22SCC\21REMOTE\20BUS\17DSP_4\16DISK|C16_VIDEO\15SCSI\14PRINTER\13ENETX\12ENETR\11SOUND_OVRUN\10PHONE\07DSP_3\06VIDEO\05MONITOR\04KYBD_MOUSE\03POWER\02SOFTINT1\01SOFTINT0"

---

> 2. Incomplete SCSI transfer:
> The SCSI driver in the boot program (bootloader) seems to be
> a bit too restrictive when it comes to transfer length. I
> have the problem, that a shorter than expected inquiry reply
> causes the bootloader to fail. Inquiry message length varies
> between manufacturers and short messages should not cause an
> error. I think this could be fixed easily by setting
> next68k/stand/boot/scsi.c, line 446 from #if 1 to #if 0

Hmm, do you see this problem on a real (and old) SCSI disk,
or only on emulator?  There was the same issue on NetBSD/x68k
bootloader on the XM6 typeG emulator:
 https://github.com/NetBSD/src/commit/a81affde5b99bf3af0e633c9cdeea5a2b845a8ef

It looks next68k bootloader uses "struct scsipi_inquiry_data"
to receive inquiry data defined in src/sys/dev/scsipi/scsipi_all.h:
 https://github.com/NetBSD/src/blob/338f5e0c6c82c4e90272a48cbcdbcc0e071bc3c2/sys/dev/scsipi/scsipi_all.h#L91-L166

As commit history says the structure has been extended to 76 bytes
for SCSI3 devices back after NetBSD 1.5 days:
 https://github.com/NetBSD/src/commit/f65d97bb57b56032934aba4f0e615925b6be95f5#diff-ad7fe06963e7b2afbd5e7932c7fe9c06ff0c7122a8a30393ab0ea217920665d2

I know this problem could actually happen on old real SCSI1 drives,
but I guess a proper fix is to specify only 36 bytes as SCSI2 inquiry
command on the xfer, as x68k did.

Could you try the following patch?
(at least this works on a my real SCSI2 drive as before)

---
diff --git a/sys/arch/next68k/stand/boot/sd.c b/sys/arch/next68k/stand/boot/sd.c
index 321bbb2d4139..52289d1f42ba 100644
--- a/sys/arch/next68k/stand/boot/sd.c
+++ b/sys/arch/next68k/stand/boot/sd.c
@@ -98,8 +98,8 @@ sdprobe(char target, char lun)
 
     memset(&cdb2, 0, sizeof(cdb2));
     cdb2.opcode = INQUIRY;
-    cdb2.length = sizeof(inq);
-    count = sizeof (inq);
+    cdb2.length = SCSIPI_INQUIRY_LENGTH_SCSI2;
+    count = SCSIPI_INQUIRY_LENGTH_SCSI2;
     error = scsiicmd(target, lun, (u_char *)&cdb2, sizeof(cdb2),
 		     (char *)&inq, &count);
     if (error != 0)

---

Note I just noticed yesterday that current next68k bootloader
had a bug that DMA register accesses were not handled properly.

Maybe you also have to pull the following change:
 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/next68k/stand/boot/dmareg.h#rev1.4 

> 3. There seems to be an issue with the structure of SCSI disks
> (might also be a usage problem by me):
 :
> This leads to a disk that can be mounted and I can write and
> read files. But that disk can't be used for booting, because
> the bootloader is overwritten by newfs. If I swap steps B and
> C I get a disk with broken filesystem, but the bootloader does
> work. Obviously installboot and newfs write to the same location
> and overwrite each others results.

Yes, I got the same issue and have to prepare some spaces
at the top of the this.

Then I noticed it was a requirements of the original design:
 https://mail-index.netbsd.org/port-next68k/2002/06/06/0003.html
>> You have to install an updated boot loader.  The boot blocks are located at
>> positions 32k and 96k.  I believe the one at 32k is usually used but I've
>> always written both on my disks.  The installboot.sh script will install the
>> boot blocks.  You'll need at least 61k of free space at the beginning of the
>> disk to install one boot block.  The default on Nextstep is to leave 160k
>> free.

As you noted, we should prepare some proper documents, but
I think it's also worth to have an explicit "BOOT" partition
in the disklabel partition and make the installboot(8) utility
check that the BOOT parition exists and has enough size,
as hp300 does:
 https://github.com/NetBSD/src/blob/338f5e0c6c82c4e90272a48cbcdbcc0e071bc3c2/usr.sbin/installboot/arch/hp300.c#L133-L157

Thanks,
---
Izumi Tsutsui