search

ZuluSCSI / ZuluSCSI-firmware

Firmware for the ZuluSCSI advanced SCSI emulator
https://zuluscsi.com
Other
182 stars 20 forks source link

missing "tracks per zone" (heads) value in mode sense page 03h (format params) #150

Closed vvuk closed 1 year ago

vvuk commented 1 year ago

For mode sense page 03h, at https://github.com/ZuluSCSI/ZuluSCSI-firmware/blob/4c1750726ea9a602f7060a7569561a19576ec8c7/lib/SCSI2SD/src/firmware/mode.c#L402 sectors per track and data bytes per sector are written, but bytes 2 and 3 are left as zero. These bytes are defined to hold "TRACKS PER ZONE" (i.e. heads?). I believe this should be writing scsiDev.target->cfg->headsPerCylinder in there.

(Yes page code 03h is obsolete; I'm using an OS from 1992 (Domain/OS) and it seems to want these values! :) )

aperezbios commented 1 year ago

@vvuk thanks for this feedback. @PetteriAimonen at your convenience, please take a look at this.

vvuk commented 1 year ago

Oh also -- at least from my reading of the spec, the "bytes per sector" value is not changeable via MODE SELECT -- image so I don't think this should be included in the mask.

The ST15150N manual (https://www.seagate.com/support/disc/manuals/scsi/28880d.pdf) helpfully lists the drives' responses to all the mode sense commands (!) and it doesn't indicate that this value is changeable in the response to 03h. It probably doesn't matter though, since I can't imagine anything actually trying to change it here even if it was marked as changeable. (Weirdly ST15150N manual marks the number of heads as changeable?)

PetteriAimonen commented 1 year ago

From https://www.staff.uni-mainz.de/tacke/scsi/SCSI2-09.html#9.3.3.3

The tracks per zone field specifies the number of tracks per zone to use in dividing the capacity of the device for the purpose of allocating alternate sectors. A value of zero means that one zone is defined for the entire device.

So I don't think "headsPerCylinder" is the correct value to write, while a value of zero is a valid value.

But it is possible to add a new config parameter for this. Have you actually tested if setting this value to something other than zero resolves your problem? It could be tested by directly editing mode.c.

vvuk commented 1 year ago

Hmm, you're right, I misread the spec. I'll build the firmware locally and try to figure out what's going on with my hardware.

On Sun, Mar 5, 2023 at 10:19 PM Petteri Aimonen @.***> wrote:

From https://www.staff.uni-mainz.de/tacke/scsi/SCSI2-09.html#9.3.3.3

The tracks per zone field specifies the number of tracks per zone to use in dividing the capacity of the device for the purpose of allocating alternate sectors. A value of zero means that one zone is defined for the entire device.

So I don't think "headsPerCylinder" is the correct value to write, while a value of zero is a valid value.

But it is possible to add a new config parameter for this. Have you actually tested if setting this value to something other than zero resolves your problem? It could be tested by directly editing mode.c.

— Reply to this email directly, view it on GitHub https://github.com/ZuluSCSI/ZuluSCSI-firmware/issues/150#issuecomment-1455522437, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABPTFNN744QZZ7MXWD3JIDW2V6VTANCNFSM6AAAAAAVQTXC6A . You are receiving this because you were mentioned.Message ID: @.***>

aperezbios commented 1 year ago

@vvuk closing this for now, if you feel it should be re-opened in the future, please do so. Thanks!

vvuk commented 1 year ago

Yep, sorry, I forgot to follow up on this! This turned out to not be theissue; the problem is with the 0x01 mode sense/mode select; the OS is expecting a certain initial value and then it expects to be able to mode select some additional error recovery parameters. Giving it some more bits & letting it mode select some others works fine. I'll try to put up a patch soon.

It might be interesting to consider a full ST15150N emulation mode because they helpfully published all their mode sense values & changeable masks -- or even a generic "emulate this type of drive/device exactly" framework. Still masked off by whatever zuluscsi can actually support, but there's a lot of stuff that doesn't really matter to zuluscsi (e.g. the error recovery bits) but that might matter a lot to the host.

aperezbios commented 1 year ago

@vvuk I agree, 1:1 (or as close as we can get to it) emulation of something like the ST15150N and a few other very, very common SCSI devices is something I'd like to implement. We'll get to it eventually, but if you many any local changes and would be willing to submit pull requests for anything like what you've described above, we'd be grateful.

vvuk commented 1 year ago

Sounds good, I'll take a look soon. Right now I have hardcoded hacks and it's not great :) I've been doing some of the development using piscsi since it's very convenient to be able to recompile your scsi controller directly on.. the controller ;) I'll isolate e.g. the ST15150N values to a separate (BSD-licensed) file to avoid licensing issues.