View Single Post
Old 06 April 2017, 17:00   #15
Registered User

Join Date: Mar 2017
Location: Philadelphia / United States
Posts: 49
A couple of items to keep in mind for the GVP controllers (and a number of others from the past era):

The FastROM (3.x/4.x) drivers will behave with up to <4GB disks. Step over the 4GB line and you will have wrap problems with the block numbers of the SCSI target. Because of the next issue, file systems, I recommend 'slicing' up any larger flash media in the PC setup tool for 2GB pieces. In any case, I recommend making the first slice, and partition, 2GB to boot from.

If you have plans to use a file system that addresses beyond the classic FFS limit of 2GB, keep the actual disk 'slice' under 4GB unless you have access to GuruROM v6.11 or newer, which can go beyond the 4GB device size. This would naturally apply to the A2091 version of the GuruROM, too, or any known revisions of C= scsi.device that have been properly updated for the same reason. I defer to other experts when it comes to patching or updating a Kickstart ROM-based scsi.device driver like that.

Classic FFS partitions should be kept to <2GB due to signed 32-bit integer limits in the original code. If you have an updated FFS that can handle beyond that (Read about TD_64 extensions that were proposed and implemented by 3rd parties years since). Be sure it doesn't get contaminated with an older version on a boot floppy when you make changes. In any case, don't go beyond a 4GB partition unless you also have the underlying driver able to go beyond 4GB SCSI block counts.

Use of PFS or SFS, which have >2GB functionality, I will defer to other people with more experience, and their docs. I would only caution going >4GB on a controller driver that isn't able to - you are in danger of experiencing integer wrap problems if the file system requests a block over 4GB.

On older GVP v1.98 FastPrep disks, there is the Expert mode of the tool that allows one to tick the Sync mode flag. There are other RDP tools that can do it too. For GuruROM, and any board that supports Sync transfers, that rdb flag is typically needed to be able to negotiate above Async SCSI. The GuruROM has a tool (similar to GVPSCSICtrl) called OmniSCSICtrl (IIRC) with an option to turn on Sync negotiation with a target manually. It would be advisable to also make sure Disconnect/Reconnect is enabled if you are using more than one device on the cable.

Another item to be aware of is the disk partitioning tools are also mostly 32-bit integer-based, and going beyond 2GB or sometimes 4GB on a partition will result in wrap-around. Know the capabilities of your RDB/Partitioning tools before you go over 4GB. HDToolBox I believe has been updated to handle it in a later version. GVP FastPrep won't be good to use on partitions over 2GB.

RDB Last Disk and Last LUN flags are important for some drivers. It's the flag that a driver may interpret, at boot time, whether to look further up the numeric chain for devices. Most drivers scan device ID 0, starting at LUN 0, then LUN 1, LUN 2, etc... Then on to ID1, and scan LUNs, etc, until stopping after finishing ID 6. Setting the Last Disk stops the scan at that SCSI ID. Setting the Last LUN stops the scan at that LUN. Most of the time, drives with no LUNs are actually LUN 0. Adapter boards may implement LUNs. Setting the flag is suggested in many cases to speed up boot time (time to scan the bus for drives, devices, and partitioning), but up to the driver as to how long to wait for timeout. FastROM supports the flags. GuruROM I believe ignores them (come back later with the OmniSCSICtrl tool to find/mount/modify them). Older scsi.device ROMs tended to not be willing to address any devices at addresses after encountering the flag (newer version behavior I have no experience with).

I hope that helps with some understanding of what is at play.
thebajaguy is offline  
Page generated in 0.04523 seconds with 11 queries