Hello Mr. Tsutsui,
thank you very much for the reply! Glad to see someone is working on this!
Am 07.02.2023 um 17:09 schrieb 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"
---
Unfortunately I have no setup to compile the kernel. But maybe Mr. Engel can compile it once he has some spare time. Anyway I’m quite confident that it will work.
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
I do not own any NeXT hardware. But my SCSI disk simulation is based on the Seagate ST3283N SCSI-2 hard drive from the early 90s. It has a 54 byte inquiry message. The NeXT ROM and kernel ask for 66 bytes but have no problem handling the shorter reply. Same for the NetBSD kernel which also asks for longer messages, just the NetBSD bootloader does not like it.
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)
I’m pretty sure the patch below will fix the problem with Previous, as it has a 54 byte message. But on the other hand it would be more secure to handle any (short) length of message. The messages might vary, especially on old disks. I don’t see the point of treating this as an error condition.
---
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 thatcan 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
The bootloader is not contained on a partition. The first 160 kB (320 blocks) are reserved for the disk label and bootloader. There are 4 copies of the label and 2 copies of the bootloader in case there are faulty blocks. The label already contains correct information about the bootloader positions (else NeXT ROM wouldn’t load it). But the first partition overlaps with the bootloader.
NeXT’s disktab is useful for understanding the structure of the disk and the disk label (appended).
Thanks,
---
Izumi Tsutsui
If I can help with anything that does not require NeXT real hardware or compiling I’ll do my best.
Best wishes,
Andreas
|