USB bug in 5.28

When using the CM4 on the RPi IO board or on the Waveshare IO board, I get two errors from RISC OS 5.28:
Abort on data transfer at &2000447C (offset &5A8 from the start of RTSupport workspace in the module area)
Also the mouse pointer disappears or freezes after booting completes.

These can be worked around on the RPi IO board by fitting a USB board to the PCI Express slot but that means it is no longer available for fast storage.

Is there a simple tweak I can do to the sources to cure this bug? Linux works fine.

Some progress using a 4GB/WiFi/32GB CM4 on a Waveshare ‘IO board mini B’ (which is in stock for next day delivery from Amazon) although the compute modules themselves seem be rather rarely in stock. Fortunately I got some at the end of 2021.

RISC OS 5.28 throws an error just after (about 0.5s) showing the Supervisor prompt – as shown below:

but if I then type

run SCSI::RISCOSpi.$.!Boot

One start up in four, the mouse pointer shows correctly and it all appears to be working apart from being able to read the eMMc from which the board (but not the RISC OS desktop) has booted.

With the error on start up there’s no point in setting the CMOS to boot from SCSI drive 1.

On the RPi IO board I have done that (using a Rpi4B to set the correct CMOS setting [filesystem scsi and drive 0] and then copying the file ‘CMOS’ to the eMMc using Linux – which can see the FAT partitions and the eMMc) and it boots up fine (still can’t read the eMMc though).

Test set up can be viewed here. Underneath the Waveshare IO board is a m.2 NVMe slot for fast storage. I have a drive on order and will let you know whether it works under RISC OS when it arrives next week.

So far as I can see this setup is roughly what RISC OS Developments/R-Comp were talking about for a custom PCB for the CM4.

Further info on the USB bug on CM4:

Sometimes at an early stage of start up I get abort on data transfer at FC200C2C (offset 5B6C in USB Driver RISC OS 5.28)

*memoryi fc200c00
FC200C00 : ..Pã : E3500000 : CMP     R0,#0
FC200C04 : .. . : 13A00006 : MOVNE   R0,#6
FC200C08 : ð¨.. : 191BA8F0 : LDMNEDB R11,{R4-R7,R11,R13,PC}
FC200C0C : @0Ôå : E5D43040 : LDRB    R3,[R4,#64]
FC200C10 : .pӌ : E594700C : LDR     R7,[R4,#12]
FC200C14 :  ..ã : E3130020 : TST     R3,#&20            ; =" "
FC200C18 : .... : 1A00000E : BNE     &FC200C58
FC200C1C : ..Wã : E3570000 : CMP     R7,#0
FC200C20 : .... : 0A00000C : BEQ     &FC200C58
FC200C24 : . •å : E5952004 : LDR     R2,[R5,#4]
FC200C28 : .. á : E1A01006 : MOV     R1,R6
FC200C2C : .0’å : E5923000 : LDR     R3,[R2,#0]
FC200C30 : .  á : E1A02007 : MOV     R2,R7
FC200C34 : .. á : E1A00003 : MOV     R0,R3
FC200C38 : 00“å : E5933030 : LDR     R3,[R3,#48]
FC200C3C : .à á : E1A0E00F : MOV     R14,PC
FC200C40 : .ð“å : E593F00C : LDR     PC,[R3,#12]
FC200C44 : ..Pã : E3500000 : CMP     R0,#0
FC200C48 : ð¨.. : 191BA8F0 : LDMNEDB R11,{R4-R7,R11,R13,PC}
FC200C4C : @.Ôå : E5D41040 : LDRB    R1,[R4,#64]
FC200C50 : . ã : E3812010 : ORR     R2,R1,#&10         ; =16
FC200C54 : @ Äå : E5C42040 : STRB    R2,[R4,#64]
FC200C58 : ´.Ôá : E1D411B4 : LDRH    R1,[R4,#20]
FC200C5C : ...ã : E3110001 : TST     R1,#1
*

Then I get the error aodt at &2000447C (in RTSupport workspace)

*memoryi 20004450
20004450 : .@²% : 25B24004 : LDRCS   R4,[R2,#4]!
20004454 : $P”% : 25945024 : LDRCS   R5,[R4,#36]
20004458 : ..5! : 21350006 : TEQCS   R5,R6
2000445C : ,€„. : 0584802C : STREQ   R8,[R4,#44]
20004460 : $p„. : 05847024 : STREQ   R7,[R4,#36]
20004464 : .0S" : 22533001 : SUBCSS  R3,R3,#1
20004468 : øÿÿ* : 2AFFFFF8 : BCS     &20004450
2000446C : ü.½è : E8BD01FC : LDMIA   R13!,{R2-R8}
20004470 : .ð!á : E121F009 : MSR     CPSR_c,R9
20004474 : ”‘.å : E51F9194 : LDR     R9,&200042E8
20004478 : .ð á : E1A0F00E : MOV     PC,R14
2000447C : .ð.õ : F57FF01F : CLREX                      ; ARMv6K or later
20004480 : -. á : E1A00A2D : MOV     R0,R13,LSR #20
20004484 < þ@Zé : E95A40FE : LDMDB   R10,{R1-R7,R14}^
20004488 : .. á : E1A00A00 : MOV     R0,R0,LSL #20
2000448C :   Jâ : E24AA020 : SUB     R10,R10,#&20       ; =" "
20004490 : þ.€è : E88000FE : STMIA   R0,{R1-R7}
20004494 : ñG.é : E91A47F1 : LDMDB   R10,{R0,R4-R10,R14}
20004498 : ’ð!ã : E321F092 : MSR     CPSR_c,#&92        ; ="’"
2000449C : ..°å : E5B01018 : LDR     R1,[R0,#24]!
200044A0 : .ðoá : E16FF001 : MSR     SPSR_cxsf,R1
200044A4 : .àå : E590E008 : LDR     R14,[R0,#8]
200044A8 : ’. ã : E3A01092 : MOV     R1,#&92            ; ="’"
200044AC : ..ی : E5801000 : STR     R1,[R0,#0]
*

Hope this helps.

With a PCI Ex USB board fitted, and CMOS set to SCSI drive 0 boot, RISC OS boots up correctly with no error (but the major benefit of the PCI Ex for fast storage is lost).

With the PCI slot empty and CMOS set to SCSI drive 0 boot, then the AODT error occurs at the Supervisor prompt and thereafter there is a ‘Filecore in use’ error.

With the PCI slot empty and CMOS set to default SDFS boot (the eMMc is seen as empty) then the AODT error comes up at the supervisor prompt and a manual boot works OK.

These errors do not occur if a PCI Express USB board is fitted.

On the Waveshare IO board, with SDFS boot set, manual boot into SCSI after the AODT error, ignore the ‘not set up’ error, all appears to work although on 70% of start ups the mouse pointer remains invisible. So .. on 30% of the start ups all is well.

So if I can find a tweak to the sources so that the error at 2000447C does not occur at start up, then that would be a major step forward.

Further to the above, it seems that so long as I have something plugged in to the PCI Express slot on the Rasp Pi IO board (whether a USB board or a PCI to M.2 connector with a m.2 drive in it) or something plugged in to the MVMe M.2 slot on the Waveshare IO board, the error does not come up. So RISC OS boots up with no error.

Clearly RISC OS expects certain behaviour from devices it ‘knows’ to be provided on the PCI Express bus (on the Pi 4B this is the two USB 3 sockets) and throws an error when the non-fitting causes unexpected results.

However RISC OS cannot read the m.2 drive – it does not show up in USBdevices and the XHCIDriver module is dormant. Doing a RMReInit XHCIDriver causes the error ‘No XHCI controllers spare’.

Any suggestions please?

I can confirm that, after Chris’s discovery that any old PCIe device enabled the CM4 to boot RISC OS (I thought it needed to be a PCIe device with the Pi 4’s USB 3 chipset), I have now set up a Waveshare Mini-IO-board (mine is pre the A or B models) to dual boot both RISC OS and Linux without the need for USB drives.

As Chris says, the NVMe drive is invisible to RISC OS, but hey ho! Linux can see it and run nicely from it.

Yes, using the Lite CM4 board, RISC OS can use the SD card and Linux can use the NVMe drive so there is no need for USB drives. Fitting the NVMe drive is enough to ensure the XHCI driver remains dormant on RISC OS and does not generate errors for missing hardware.

It is unfortunate that the only Lite CM4 I have is only 1GB RAM.

After a bit of a struggle, I now have a CM4 dual-booting from eMMc either into Linux (on the attached nvme m.2 drive) or into RISC OS (on a USB stick). The dual boot is controlled by a switch between pins 29 and 30 of the 40 pin header. The nvme image only takes up 32GB of the 500GB on the nvme drive until I work out how to make it use the whoile drive…