Re: Cannot read blocks using AHCI
Posted: Thu Jan 25, 2024 4:07 am
Yes, I aligned the virtual addresses too, but nothing changedOctocontrabass wrote:Are the virtual addresses aligned too?
The Place to Start for Operating System Developers
http://f.osdev.org/
Yes, I aligned the virtual addresses too, but nothing changedOctocontrabass wrote:Are the virtual addresses aligned too?
Do you mean the error field contains the value 0x7F, or the entire register contains 0x7F? If it's the entire register, the drive hasn't sent a status update since the controller was reset.WinExperements wrote:i got error 0x7f from PxTFD register before issusing new command
You're receiving IRQ11. You've configured the PICs to map IRQ11 to interrupt vector 0x2B.WinExperements wrote:Also after enabling the interrupts i got continuislly the interrupt from IRQ 0x2b, but the PCI device interrupt line reports that the IRQ is 0x10b,
PCI IRQs are level-triggered. If you send an EOI without acknowledging the IRQ in the AHCI HBA, you will immediately receive another interrupt.WinExperements wrote:can the interrupts caused by non handled previously interrupts from the controller?
PxTFD indicates you sent a FIS to the drive and the HBA is waiting for the drive to respond. PxSERR doesn't show any errors, but it does say the SATA link state changed since the last time it was cleared.WinExperements wrote:Also runned on real hardware, got port hung error and some wierd(for me) values of port registers: serr - 0x4050000, tfd - 0x80
Understood, thanksOctocontrabass wrote:If you send an EOI without acknowledging the IRQ in the AHCI HBA, you will immediately receive another interrupt.
can it be caused by non handled interruptions from HBA and what I should do in this situation?Octocontrabass wrote:the drive doesn't think it needs to respond to the FIS you're sending.
Code: Select all
info->abar->ghc = (uint32_t ) (1 << 31);
info->abar->ghc = (uint32_t ) (1 << 0);
info->abar->ghc = (uint32_t) (1 << 31);
info->abar->ghc = (uint32_t) (1 << 1);
AHCI is supposed to process commands completely automatically, so an unhandled interrupt shouldn't get in the way of command processing. There's probably still something wrong somewhere, but I've looked through your code a few times and haven't found the problem.WinExperements wrote:can it be caused by non handled interruptions from HBA and what I should do in this situation?
Usually that status means no drive is connected, but you may also see strange values if you're using DMA and not reading the status registers in the correct order. The PCI IDE specifications explain how your driver is expected to work with the hardware, although the explanations assume you're already familiar with legacy ISA IDE.WinExperements wrote:on my notebook that use SATA controller IDE mode I got the IRQ10 interrupt and if I read the first successfully detected drive status register I got 0x7f.
Without more information, it's impossible to say where the interrupts are coming from.WinExperements wrote:So did anyone know why I got there interrupts and how correctly process there interrupts?
If you send an EOI to the interrupt controller before you acknowledge the PCI device, you will receive another interrupt. If you never acknowledge the PCI device, you will receive interrupts from it continuously.WinExperements wrote:Also i got there interrupts continuosly
The interrupt is to tell you the drive is done processing the command. Read the drive's status register to acknowledge the interrupt and see what you need to do next.WinExperements wrote:the interrupts fired from the SATA controller itself(or IDE controller because it’s in IDE mode) after sending IDENTIFY command.
Okay, my interrupt handler reads the status register, and this register is 0x58, and error register is zero, what I should do with this(because I really don’t get it). Writing back the status register doesn’t help, I still get the interruptOctocontrabass wrote: Read the drive's status register to acknowledge the interrupt and see what you need to do next.
There are no errors and the drive is ready for you to transfer data. Since you used the IDENTIFY DEVICE command, the drive is expecting you to read 512 bytes.WinExperements wrote:Okay, my interrupt handler reads the status register, and this register is 0x58
Did you read the status register before or after the EOI? You must read the status register before the EOI.WinExperements wrote:I still get the interrupt
After checking each PCI device IRQ line, the first IDE PCI device IRQ line used also by Signal Processing Unit and second PCI IDE device. So how I can correctly add the interrupt handler or what I must do in this situation?Octocontrabass wrote:Is another PCI device using the same IRQ?