Port-next68k archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Fwd: next68k: current issues



Hi,

> thank you very much for the reply! Glad to see someone is working on this!

No problem, I'm also glad to see activities including emulators.
(luna68k port also has emulator users :-)

> Unfortunately I have no setup to compile the kernel.
> But maybe Mr. Engel can compile it once he has some spare time.

Ok, I'll try to implement for three variants and put a kernel
binary somewhere.

> > 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.
 :
> 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.

I see your point.  Drivers should handle short transfers especially
for SCSI disconnect etc. But one concern is the residual byte number
check was explicitly added 20 years ago and it looks a workaround of
some problem:
 https://github.com/NetBSD/src/commit/b1ce5975467f3b2651ba9b206a1e35a4af60e0f1

If a fix against a number of inquiry xfer bytes works around,
I would like to commit it for now.

> > --- 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)

> 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. 

I'm using the following label on my NetBSD/next68k:
---
4 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 a:   2026528       872     4.2BSD   2048 16384   128  # (Cyl.      2 -   4649)
 b:     76736   2027400       swap                     # (Cyl.   4650 -   4825)
 c:   2109840         0     unused      0     0        # (Cyl.      0 -   4839*)
 d:       872         0       boot                     # (Cyl.      0 -      1)
---

The partition d is not necessary for kernel or bootloader,
but we can denote explicitly leading sectors should be preserved
for a bootloader so that installboot(8) utility can check not
overwriting existing root partition.

Anyway we have to update install notes..
https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.3/next68k/INSTALL.html

Thanks,
---
Izumi Tsutsui


Home | Main Index | Thread Index | Old Index