From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Steven Scholz <steven.scholz@imc-berlin.de>
Cc: Alan <alan@lxorguk.ukuu.org.uk>, linux-ide@vger.kernel.org
Subject: Re: HPA and failed opcode was: 0x37 ?
Date: Tue, 30 Jan 2007 21:32:19 +0300 [thread overview]
Message-ID: <45BF8F33.3070008@ru.mvista.com> (raw)
In-Reply-To: <45BF88B9.3050802@imc-berlin.de>
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
next prev parent reply other threads:[~2007-01-30 18:32 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-30 14:02 HPA and failed opcode was: 0x37 ? Steven Scholz
2007-01-30 14:07 ` Steven Scholz
2007-01-30 15:44 ` Eric D. Mudama
2007-01-30 15:50 ` Eric D. Mudama
2007-01-30 15:54 ` Steven Scholz
2007-01-30 15:53 ` Steven Scholz
2007-01-30 16:44 ` Alan
2007-01-30 16:46 ` Steven Scholz
2007-01-30 17:26 ` Alan
2007-01-30 17:19 ` Steven Scholz
2007-01-30 18:07 ` Alan
2007-01-30 18:04 ` Steven Scholz
2007-01-30 18:23 ` Eric D. Mudama
2007-01-30 18:32 ` Sergei Shtylyov [this message]
2007-01-30 19:56 ` Eric D. Mudama
2007-01-30 20:01 ` Eric D. Mudama
2007-01-31 8:29 ` Steven Scholz
2007-01-31 12:54 ` Sergei Shtylyov
2007-01-31 13:08 ` Steven Scholz
2007-01-31 13:12 ` Sergei Shtylyov
2007-01-31 13:38 ` Steven Scholz
2007-01-31 9:51 ` Steven Scholz
2007-01-31 12:50 ` Sergei Shtylyov
2007-01-31 13:04 ` Steven Scholz
2007-01-31 13:33 ` Alan
2007-01-31 13:26 ` Steven Scholz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45BF8F33.3070008@ru.mvista.com \
--to=sshtylyov@ru.mvista.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-ide@vger.kernel.org \
--cc=steven.scholz@imc-berlin.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.