<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Benjamin Herrenschmidt wrote:
<blockquote cite="mid:1218492032.8041.11.camel@pasglop" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">1. IDE status read does not work. (But am I understand correctly
that IDE works well if IRQ is unspecified? Then this is hardly
an issue.)
2. IDE interrupt comes when it should not. I'd recommend to use
oscilloscope to find out what is happening there, that is, if
the drive actually deasserts its irq line after status read.
If so, than this could be a PIC problem.
What is the platform on which you're observing the issue, btw?
</pre>
</blockquote>
<pre wrap=""><!---->
Another possibility is that you got the wrong interrupt number
in the device-tree...
Ben.
</pre>
</blockquote>
<br>
<tt>The platform is the AMCC Sequoia board. We've built a little
adapter to connect a compact flash card to the processor bus. I
believe the interrupt selection in the device tree is correct, and I've
checked over the u-boot settings for the IRQ line (active high, level
sensitive). I've also tried edge-sensitive but it doesn't make a
difference.<br>
<br>
When u-boot queries the CF card, we see the IRQ pulse as expected, but
when the kernel runs, we see the IRQ go high and stay there, which the
kernel naturally treats as a stuck interrupt. The other oddity is that
we see a single diagnostic failure on startup:<br>
<br>
</tt>
<blockquote><tt>ata1.00: Drive reports diagnostics failure. This may
indicate a drive</tt><br>
<tt>ata1.00: fault or invalid emulation. Contact drive vendor for
information.</tt><br>
</blockquote>
<tt><br>
That is strange, because if we manually do the soft reset from u-boot,
we see the ATA "feature byte" return 0x01, which means success. When
the kernel does the soft reset, we see a 0x00, which means failure.
You would think it is timing related, but a logic analyzer trace shows
reasonable timing. We need to wire up a better test rig, so I don't
want folks on this list to waste any time on it. I'll report back if I
learn anything of general interest.<br>
<br>
With the interrupt disabled in the device tree, and ignoring the
diagnostics failure, the drive actually works. I'm able to mount a
filesystem, read files from it, etc. So, the drive is fully
functional, just without using interrupts. Therefore, I believe most
everything is correct - byte lanes, read/write signaling, timing, etc.
Curious.<br>
<br>
Steve<br>
<br>
</tt>
</body>
</html>