> ---- Le dim., 07 févr. 2021 13:02:58 -0500 Paul Dufresne > <dufres...@zoho.com> écrit ---- > > > I suspect CAP.SAM was 0 in previous versions... did not check. > > But that most computers now have CAP.SAM to 1, so that GHC.AE should be > written, even if already to 1, to "wake up" the device. > > I suspect current implementation of AHCI in Mach does not it. > > > I guess I was confused there. > CAP.SAM means Supports AHCI mode only. > So if CAP.SAM=1, GHC.AhciEnable is read-only, and always to 1. > If CAP.SAM is 0, GHC.AhciEnable is writable, and 0 'by default'. Meaning no > commands should be sent to AHCI before putting it to 1. > > BTW my main computer have no option to disable AHCI in firmware... but does > show the phy device offline error. > But don't know if CAP.SAM is really 1. > I did not write any new code yet. Still reading the doc... the more I read it the more it make sense.
I have confirmed that my system have an HBA (HBA is an acronym for “host bus adapter”. A host bus adapter refers to the silicon that implements the AHCI specification to communicate between system memory and Serial ATA devices.) which have CAP.SAM to 1: (On Linux) paul@jacko:~/hurd8fev$ sudo dmesg| grep ahci [ 0.618248] ahci 0000:00:17.0: version 3.0 [ 0.629098] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 4 ports 6 Gbps 0xf impl SATA mode [ 0.629099] ahci 0000:00:17.0: flags: 64bit ncq sntf led clo only pio slum part ems deso sadm sds apst the only flag is CAP.SAM... as can be seen from at the end of this patch: https://patchwork.ozlabs.org/project/linux-ide/patch/4ab6b487.3010...@gmail.com/ and seeing in the file:///home/paul/T%C3%A9l%C3%A9chargements/serial-ata-ahci-spec-rev1-3-1.pdf at 3.1.1 that bit 18 "only in Linux" is really CAP.SAM in the AHCI documentation: "A value of '0' indicates that in addition to the native AHCI mechanism (via ABAR), the SATA controller implements a legacy, task-file based register interface such as SFF-8038i" So my HBA does not support SFF-8038i: http://www.freedoors.org/idework/specs/8038-r01.pdf (1994) which I believe correspond to IDE as shown: https://wiki.osdev.org/PCI_IDE_Controller So... it shows that the problem is not just that we need to set CAP.AE before using other registers than the Generic Host Control (section 3.1), because on my HBA, it is always on (and read-only). So I guess this is more related to the need of: Setting PxCMD.ICC (Px means the register of the Port x, Interface Communication Control (ICC):This field isused to control power management statesof the interface. to 1 meaning Active (rather than some sleeping). See 3.3.7 for the register details. And 8.3.1.2 for more information... but 8.3.1.1 seems to suggest that "By default, a device that supports initiating interface power management states has the capability disabled" ... so maybe this is not necessary. Did not really check if Mach AHCI driver cares about that. And if it scan through GHC.PI (Ports Implemented by the BIOS), to only use the one permitted by the BIOS. Somehow, I begin to prefer to use specificaton terms, like CAP.SAM... that often have other name in the AHCI driver of Mach (in the Linux part of it). But maybe, as it is in the Linux part, I should kept the term they use.
