Now I wanted to implement ATA PIO and ATA DMA (PCI bus mastering) drivers. I read the OSdev wiki pages for them and after a whole day of messing around with it I finally understood a lot about ATA drives but the articles got me asking questions after reading some parts:
1)In the IDENTIFY section it talks about how ATAPI and SATA abort the IDENTIFY command and fill 0x1f4 and 0x1f5 with identification bytes, someone told me that this is wrong for SATA drives I need clarification on this.
2)Is the detection of drive types in the PIO page still the same if I want to use the DMA instead?
3)According to the osdev ATA DMA page:
The "address" of the Bus Master Register is stored in BAR4, in the PCI Configuration Space of the disk controller. The Bus Master Register is generally a set of 16 sequential IO ports. It can also be a 16 byte memory mapped space.
Please if anyone can explain that section as deeply as possible and also clarify it's authenticity I'd be really glad.
If it's a SATA drive then it has to be connected to a SATA controller; and:
a) If the SATA controller is in "legacy (parallel) ATA controller emulation" mode; then the entire point is that it emulates old hardware so that old operating systems (that don't support SATA) still work, so you have to expect that it works the same.
b) The SATA controller is in some other mode (native mode, RAID mode) and isn't emulating a legacy (parallel) ATA controller; and your legacy (parallel) ATA controller driver won't work at all. Note that (because Windows has supported SATA/AHCI for 15+ years) this is the most likely case for computers that are still in use today.
Yes.
More specifically; you IDENTIFY the drive's capabilities and see what it supports; and determine what the disk controller supports, what the cable supports (see note) and know what your driver supports; and then your driver auto-selects whatever is the fastest option that is supported by all 4 things (drive, cable, controller and driver). You don't try to make a wrong decision "I'm going to use UDMA mode 2 regardless of what the hardware supports" and then expect the hardware to magically grow new support for your decision.
Note: back in the 1990s, parallel ATA hit a performance barrier caused by cross-talk between wires in the parallel cable; so to allow faster transfer speeds they upgraded the old 40-conductor cable to an 80-conductor cable (with an extra ground wire between each "used" wire to reduce the cross-talk). This means that the drive may say it supports faster PIO and DMA modes (and the controller may support them); but the cable is an old 40-conductor cable and attempting to use faster transfer modes will cause data to be corrupted by the cable. I can't remember how you detect the cable type (I think there's some kind of "sense" pin you check but..).
The "BAR" registers in PCI configuration space have a few bits that tell you if the area is memory mapped IO (in the physical address space) or IO ports; and some of the bits (used for "address") are hard-wired to zero so that you can detect the size of the area (by writing 0xFFFFFFFFF to the BAR and reading it back to determine how many bits where hard-wired to zero).
Note that this information (which memory area/s and which IO ports the device uses) probably should be done by PCI bus enumeration before any PCI driver is started. More specifically; when your driver is started something should tell it which IO ports and which memory mapped areas it needs to use (possibly after kernel is told to configure IOMMU and IO port permission maps to allow your driver to use those areas); and your device driver should have no reason to care if that information originally came from PCI configuration space or from ISA Plug and Play or from a configuration script, or from some other type of bus (EISA, MCA, ...).
Most OSdev wiki pages were written by hobbyists with no prior experience, who tried reading the relevant specs, possibly misread/misunderstood some things and possibly weren't interested in various parts of the spec at all, then wrote down stuff to help (possibly without updating it when hardware changes later).
The correct way to use this information is to read the OSdev wiki pages to gain some familiarity/make it easier to read the specs yourself; then read the specs; then go back and fix all the mistakes in the wiki pages. Most people skip the last part. Some people skip the first part.
Do not assume that you can write a driver from the wiki page/s alone. They are not a substitute for the actual specs.