5.24 upgrade incompatibilities

I have been busy upgrading a number of Pi systems to 5.24

The first point is that I am impressed with the InSituBootUpdate obey file. It really makes the job so much easier.

However, I have found a couple of niggles with updates from 5.23 to 5.24

I run my systems from SSD drives and have the SDFSfiler module (number 90 on 5.23) unplugged as I do not need the SDFS ‘Floppy’ icon on the desktop. It has taken me a number of upgrades before I finally worked out why I kept getting SDFS error messages after each upgrade. It seems that ROM modules are unplugged by number and the addition of the BASICVFP module at number 15 meant that 5.24 saw the SDFS module (number 90) unplugged rather than the SDFSfiler (now at 91). The only way out of that situation appears to be to rewrite the CMOS file on the SD card on another 5.24 system.

The second issue is that SCSI drives 4 and 5 are switched round during an upgrade, such if there are two SCSI drives plugged in – the second one just having the new HardDisc4, then after the upgrade the system fails to boot until the SCSI drives are both unplugged and plugged in again the other way round on the USB ports.

But, overall, I am impressed with 5.24. :)

This change to the order in which the USB ports are allocated to SCSI drive numbers also means that on systems where I used to be able to hot plug a second mSATA drive, I can no longer do so. The harware position of the piSSDup mSATA drive (and other makes) is fixed by the hardware design.

When I plug in the second drive the system immediately re-allocates the drive numbers and complains that I need to re-insert the boot drive. If I reboot, it tries to re-boot from the wrong drive.

Perhaps, I should re-post this as a bug.

I think USB drives are numbered in the order that they are detected by the USB host controller which makes having multiple USB drives < SCSI:4 or multiple USB drives >= SCSI:4 a problem as you don’t know how they will be numbered.

I can’t comment on the boot order – however John’s post implies that if he connects a second drive, the existing drive is given a different identity.
That a mounted and in use drive has its number reallocated (and subsequently becomes “lost” to things that had references to it, possibly even open files?) – how is that anything but a bug?

In which case John can check to see if the usb device has changed too with *usbdevices. If the usbdevice has changed it is possible that adding another USB drive has caused a usb disconnect.

The only way out of that situation appears to be to rewrite the CMOS file on the SD card on another 5.24 system.

The order of modules in the ROM has changed so many times since RO2 that most long term users tend to assume there may be a renumbering and and they should ensure that all unplugged modules are reinserted before the new ROM is put in place.
The instructions for the RO5.22 ROM set specifically mention this and I rather doubt the advice would have been removed for the RO5.24 set.

If the usbdevice has changed it is possible that adding another USB drive has caused a usb disconnect.

Or that the detection code might be using a drive feature that various between manufacturers in a way that might change the order of precedence (or not).
How exactly does the USB bus determine the order? Is it truly first come first served?

Is it truly first come first served?

yes. This is my ArmX6 at boot

Computer
  | 
  +-1.USB1: Built-in, EHCI root hub
  |   | 
  |   +-1.USB2: USB 2.0 Hub [MTT]
  |       | 
  |       +-1.USB3: Hub
  |       |   | 
  |       |   +-1.USB7: Logitech, USB Receiver
  |       |   |     
  |       |   +-2.USB4: EIZO, EIZO USB HID Monitor
  |       |   |     
  |       |   +-3.USB5: USB Keyboard 
  |       |         
  |       +-4.USB6: Generic, USB Storage
  |             
  +-2.USB8: Built-in, EHCI root hub

The number before the USB number is the port number on the hub. Note port 4 on hub usb2 is initialised between port 3 and port 1 initialising on hub usb3. The ports are checked in order in the code

The order of modules in the ROM has changed so many times since RO2 that most long term users tend to assume there may be a renumbering and and they should ensure that all unplugged modules are reinserted before the new ROM is put in place.
The instructions for the RO5.22 ROM set specifically mention this and I rather doubt the advice would have been removed for the RO5.24 set.

I go back to Acorn A410 days with RISCOS 2 upgraded to 3 etc, but not to 5.

But I have never found a need in those days to unplug a module, so was not aware of the problem.

My latest upgrade worked well after I reinserted the SDFSfiler module first. Another lesson learned.

In which case John can check to see if the usb device has changed too with *usbdevices. If the usbdevice has changed it is possible that adding another USB drive has caused a usb disconnect.

I am still working on that one.

My latest upgrade worked well after I reinserted the SDFS module first. Another lesson learned.

It may be a better idea to rmkill SDFS in choices.boot.predesk instead of unpluging it. That way the order of roms won’t matter as you use the module’s name to kill it.

It may be a better idea to rmkill SDFSfiler in choices.boot.predesk instead of unpluging it. That way the order of roms won’t matter as you use the module’s name to kill it.

That sounds like a good idea. So, now implemented. Thank You.

It is possible that adding another USB drive has caused a USB disconnect.

I have not seen this again. I have been able to add another USB mSATA without the drive numbers being reallocated. So I assume my problems from a few days ago were caused by a USB disconnect.

Perhaps, this is confirmed by the fact that when it did happen the reallocations were instant and now it takes a few seconds for the System to display the new drive.