Re: HPA and failed opcode was: 0x37 ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello.

Steven Scholz wrote:

Hmm. Don't think so. Since the use of ioremap() I think the MMU treats the
area as none-cacheable, right?

Thats only the first half of the story. If you don't decode byte level
fetches in the FPGA or the code is doing something like

		read 16 bit value
		shift 8
		return half

for 8 bit reads you'll get wrong answers.

I have connected HDD's A[2..0] to CPU's A[3..1] and do something like

        for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
                hw.io_ports[i] = ide_virt_base + (i << 1);
        }

thus all HDD registers are accessed on a 16bit aligned address. Thus
ide_inb() should return the correct value.
And btw are things like identify driver use 8bit transfers?

No, 8-bit transfers are used only for taskfile access. The data register is accessed as 16-bit.

How could one then explain

current capacity is 78140160 sectors would be           0x000004A85300
native  capacity is 185074430006016 sectors would be    0xA852FFA85300

? First three bytes ok, then the other three bytes rubbish?

Note that they're not complete garbage but equal the value of the lower 3 bytes minus 1. What is clear is that Read Native Max Address Ext command must be mistreating the HOB bit... :-)

Steven

MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux