Drive startup mode - PIO write problems from FPGA

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage,comp.arch.fpga (More info?)

I'm working on an fpga program to write to hard drives and so far I've
been pretty successful with the exception of a drive in the class I
want to use.

The project involves high speed data storage upwards of 30-40 MB/s per
drive. Currently I have PIO transfer working on 3 out of 4 drives. An
old 730mb (ata2 compatible I think), a 4.3gb (ata 3 compatible), a
6.4gb (ata 5 compatible), and a newer WD 80gb (ata 6 compatible).

Problem is all the drives will recieve the data when I check sectors
except the 80gb drive. Does anyone know if this is because the drive
might be starting up in a udma mode and not accepting PIO commands?
Only the DIOR, DIOW, CS, DA, and lower 8 bits are connected to the fpga
- so could the 80gb be looking for another single or something? Any
ideas?

Thank you,
Keith

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage,comp.arch.fpga (More info?)

<Terradestroyer@gmail.com> wrote in message news:1124894447.988350.229270@g43g2000cwa.googlegroups.com
> I'm working on an fpga program to write to hard drives and so far I've
> been pretty successful with the exception of a drive in the class I
> want to use.
>
> The project involves high speed data storage upwards of 30-40 MB/s per
> drive. Currently I have PIO transfer working on 3 out of 4 drives. An
> old 730mb (ata2 compatible I think), a 4.3gb (ata 3 compatible), a
> 6.4gb (ata 5 compatible), and a newer WD 80gb (ata 6 compatible).
>
> Problem is all the drives will recieve the data when I check sectors
> except the 80gb drive. Does anyone know if this is because the drive
> might be starting up in a udma mode and not accepting PIO commands?
> Only the DIOR, DIOW, CS, DA, and lower 8 bits are connected to the fpga
> - so could the 80gb be looking for another single or something? Any
> ideas?

You did off course check that the above signals don't have alternate functions
in UDMA mode, right?

>
> Thank you,
> Keith

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage,comp.arch.fpga (More info?)

I figured I should still be in the default PIO mode and signals don't
get changed unless dmack is asserted in response dmarq and I'm sending
a PIO only command so Dmarq isn't asserted. This is what threw me off.
Register timings are pretty much work 100% and they work with the drive
because I can tell it to go to idle and standby without problem but
when I load the registers and send a command to write data it won't
accept.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage,comp.arch.fpga (More info?)

I am assuming it is starting up in any PIO mode from 0 - 2. I've been
going through the ata-6 specs and it doesn't say anything about the
mode the drive should start up in

Right know my program is very "basic" to say the least. It really just
tries to transfer data no matter what right know. So I actually have to
add in checking the error register, but thats a good idea, it might be
throwing me back something that could be a very good clue.

Thanks

Keith

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage,comp.arch.fpga (More info?)

<Terradestroyer@gmail.com> wrote in message news:1124999660.402695.301780@g47g2000cwa.googlegroups.com...
> I figured I should still be in the default PIO mode

What default PIO mode?
The one in Set Transfer Mode or the one it comes up in?

> and signals don't get changed unless dmack is asserted in response
> dmarq and I'm sending a PIO only command so Dmarq isn't asserted.
> This is what threw me off.
> Register timings are pretty much work 100% and they work with the
> drive because I can tell it to go to idle and standby without problem

> but when I load the registers and send a command to write data it won't
> accept.

Any clues in the error bits?

>