ADFS_IDEUserOp with 48-bit LBA addressing
Jon Abbott (1421) 2651 posts |
The following code on a RiscPC running RISC OS 5.29 (09-04-23 build to be exact) doesn’t do what I expect. It should read LBA 0 on the primary IDE drive, but instead returns Disc Error 22.
The documentation (which admittedly I updated based on the source code ) states that from ADFS 3.34, bit 3 of R0 indicates the parameter block is 11 bytes using 48-bit LBA addressing, but error 22 is something I’d expect when using a 7 byte parameter block and CHS addressing. Did I document ADFS_IDEUserOp incorrectly? |
Cameron Cawley (3514) 158 posts |
Is it possible that there’s a difference in behaviour with ADFS4 compared to the older ADFS used on the RiscPC and Iyonix? |
Jon Abbott (1421) 2651 posts |
That was my initial thought, but then I figured peer review would pick up the fact that ADFS4 would introduce an ADFS that behaves differently. If the documentation that accompanies the ADFS4 source is to be believed, I’m unsure how to determine if ADFS_IDEUserOp supports 48-bit LBA addressing…short of trying to read LBA 0 and seeing if it returns error 22. I suspect the documentation accompanying ADFS4 is wrong, hence my initial question. I think that where is says from ADFS 3.34 it should read from ADFS 4.00, although even that is dangerous as we then have two versions of ADFS ticking up to a collision at some point in the future. It would be okay if ADFS4 was backward compatible replacing earlier ADFS and in all builds, but it looks like it’s specific to one build or ATA implementation, but that doesn’t make any sense either as that’s what IDEFS is for…which again I would have expected to be been picked up by peer review. Perhaps the author could review the documentation and correct or clarify please? In particular clarify how to determine if bit 3 of R0 is supported? |
Rick Murray (539) 13850 posts |
Hmm… In the older ADFS it was simple, it just set the WinIDECmdFlag_48bit flag prior to doing an LBA command. At a brief rummage, it appears that all ADFS4 does is to set the size of the parameter block to be 11, which flags to the ATA driver (SATADriver module, something entirely different!) that it’s a 48 bit LBA command. Anyway, looks like the request is being signalled through. As for how to tell if it is supported? Well, it seems that the older ADFS has this function that doesn’t appear to be called by anything (searching the entire ADFS code for the function name returns only the function itself): WinIDESupports48bit ROUT ; ; Tests whether a drive supports 48-bit addressing ; ; Entry: ; WinIDEDriveNum = drive number ; ; Exit: ; R0 undefined ; EQ if supports 48-bit, NE otherwise Push "LR" LDRB LR,WinIDEDriveNum ; get drive number ADR R0,WinIDEDeviceNoIdFlags LDRB R0,[LR,R0] ; check it had Identify info TEQ R0,#0 Pull "PC",NE sbaddr R0,WinIDEDeviceIds ADD R0,R0,LR,LSL #9 LDR R0,[R0,#WinIDEIdCommandSets2] ; check magic "01" marker in word AND LR,R0,#&C000 TEQ LR,#&4000 Pull "PC",NE AND LR,R0,#IICS2_48bit TEQ LR,#IICS2_48bit Pull "PC" So older versions of ADFS do appear to support 48 bit LBA addressing, thus the 3.34 is correct. It appears that there may be some sort of flag to determine if a drive supports LBA48. Take a look at the source for HForm, it says: IF ((IDEid%!(83*2))AND&C400)=&4400 THEN IDEHasLBA48%=1 ELSE IDEHasLBA48%=0 Work out where it gets that information from and you’ll be able to determine if the drive supports it. |
Rick Murray (539) 13850 posts |
The ATA-6 spec says IDENTIFY DEVICE bit 10 word 83 indicates support for 48-bit addressing so that’ll be what HForm is looking at. |
Jon Abbott (1421) 2651 posts |
I believe I’ve figured it out. I’d mistakenly assumed that as bit 3 stipulates LBA addressing, it would set the LBA bit (bit 6) before passing the command on…in a similar way to what it does with the device bit (bit 4) from ADFS 4.00. So…the correct code should probably be:
I’ll add a note to the documentation to clarify. |
Cameron Cawley (3514) 158 posts |
Adding on to this, the mention of ADFS 3.34 does look reasonable at a glance, since that matches up with this commit that explicitly mentions adding support for 48-bit LBA.
As I understand it, the intention is to eventually use ADFS4 on all platforms with ATA hard drives instead of just the Titanium and OMAP 5 ports, it’s just that no one’s gotten around to adding support for PATA controllers and floppy drives yet. At the very least, the description of the Filing system improvements (step 3) bounty states “We are not expecting to maintain the assembler version of ADFS any longer”, which suggests that keeping it around for the RiscPC and Iyonix is just a stopgap measure. |