Unaligned STM in FileCore30

And the programmer even kindly commented its reliance on unaligned STM’s working.

I’ve just seen a FileCore Abort caused by an STM in FileCore30 at line 1402 that fails on ARMv7, due to its reliance on STM ignoring bits 0 and 1 of Rd.

EDIT: A possible fix is to change:

ADR     R0, ConvDiscErr+NewDiscErrorBit
STMIA   R0, {R2, R4, LR}
Pull    "R2-R4"

to

ADR     R0, ConvDiscErr+NewDiscErrorBit
BIC     R3, R0, #3
STMIA   R3, {R2, R4, LR}
Pull    "R2-R4"

And there’s another reliance on unaligned LDM behaviour in adfs20 at line 312

Possibly fix via changing:

ASSERT  NewDiscErrorBit < bit2
LDMIA   R0, {R1,R2,R3}

to

ASSERT  NewDiscErrorBit < bit2
BIC     R3, R0, #3
LDMIA   R3, {R1,R2,R3}

I should have stated that these issues are caused by the new style sector error returned by FileCore_DiscOp

This issue could also potentially affect any software that doesn’t clear bits 0/1 of the error pointer returned, either due to it not expecting a new style error or as in RISCOS, relies on an unaligned LDM to work.

Are there any plans to implement unaligned STM/LDM in the RISCOS Abort handler?

I’ve just seen a FileCore Abort caused by an STM in FileCore30 at line 1402 that fails on ARMv7, due to its reliance on STM ignoring bits 0 and 1 of Rd.

Out of interest, what filing system were you using at the time? The code path you’ve highlighted only applies when the FS doesn’t support the new style error scheme.

A possible fix is

I think the cunning ADR and STM with no writeback is to ensure we exit the function with a new style disc error pointer in R0. So we need to keep bit 0 set overall. An aligned ADR/STM/ORR looks like it’d achieve that.

Out of interest, what filing system were you using at the time?

ADFS – legacy software accessing floppies, checking for disc protection.

An aligned ADR/STM/ORR looks like it’d achieve that.

It would indeed.

Out of interest, what filing system were you using at the time? The code path you’ve highlighted only applies when the FS doesn’t support the new style error scheme.

ADFS – legacy software accessing floppies, checking for disc protection.

Now I’m even more baffled, since ADFS registers with FileCore_Create with the NewErrorBit set in its flags word. Plus, the only platforms supporting floppies are the Iyonix (ARMv5) and Risc PC/A7k/A7k+ (ARMv3 or 4) none of which would trigger the unaligned fault.

Or have I missed something obvious?

The software raising the floppy request is 26bit running under ADFFS and expects old style errors. ADFS doesn’t come with the Pi build as you’ve noted, so a shim ADFS Module is loaded by ADFFS to match the expected behaviour of RO3.1