Ticket #309 (Open)Thu Aug 30 13:25:26 UTC 2012
SCSIFS may run out of drive slots to find/mount the boot drive
| Reported by: | Sprow (202) | Severity: | Normal |
| Part: | RISC OS: Module | Release: | |
| Milestone: | Status | Open |
Details by Sprow (202):
SCSIFS is looking in Boot:Choices somewhere for a file called ‘Hide’ to decide whether to supress a drive being used. For example, cheapo 7-in-1 card readers might try to grab 7 drive numbers (of a current limit of 8). The scheme employed seems incredibly short sighted and can render it impossible to boot of SCSIFS (for example if the maximum number of drives is used up before the USB attached boot drive is added!).
Having more than 8 drives per FileCore filing system is probably some way off.
Maybe do a CRC16 of the name string/vendor/product id and bung that in CMOS? Aside from Castle’s USB podule (which seems to be no longer supported) all platforms to date with USB have had 2k of CMOS, so starting a new allocation there might make sense.
Similarly, having some way to retrospectively go back and apply the hide file would avoid dipping into CMOS (ala *READMIMEMAP command).
Changelog:
Modified by Trevor Johnson (329) Fri, July 26 2013 - 13:35:33 GMT
For reference (particularly intended for any newcomers having difficulty navigating the site):
- Jeff Doggett’s SCSIFS Bodger
- SCSIFS sources (unless I’ve been searching in the wrong place)
Modified by Sprow (202) Thu, June 26 2014 - 07:52:12 GMT
The boot sequence now issues Service_BootChoicesVarsSet when Choices$Path is known valid, so SCSIFS can listen for this and reread the configuration. The slight complication is that the drives may already have been added by then, so would need to be reassessed and detached from the table of attached ones.
Modified by Jeffrey Lee (213) Sat, September 09 2017 - 20:54:35 GMT
Partially resolved by SCSIFS 1.32; the Hide file will now be re-scanned when Service_BootChoicesVarsSet is received.
https://www.riscosopen.org/viewer/revisions/log…
There’s still the problem that having too many devices detected during ROM init could prevent the boot drive from mounting, so I’ll leave this ticket open for now.
A potential solution I can think of would be to use a few spare CMOS bytes to allow a certain device to be “locked” to a given drive number, so you can ensure your boot drive (and only your boot drive) is assigned the correct drive number. This could be as simple as using two bytes to store the CRC16 of the inquiry data of the device you want to have locked to the SCSIFSDrive number (plus an enable flag bit).
Modified by Sprow (202) Mon, August 16 2021 - 16:43:46 GMT
- Summary changed from SCSIFS 'hide' file doesn't work when SCSIFS in ROM to SCSIFS may run out of drive slots to find/mount the boot drive
