libata extension

libata extension

[Vitaliyi]

Good Day

Say i want to implement extended set of ATA commands available to
userspace for building diagnostic tools.
I need 0x40 -- read verify and 0x32 -- write long with error handling,
for example. I was trying ide driver through ioctl's, but seems it
lack of functionality and full of gotchas. Furthermore it oopses
sometimes.

Is it possible to use libata for such purpose or i need to write
separate IDE driver ?
By the way, i'm sure it should be done in kernel space since i'm going
to deal with some hdd manufacturer commands.

P.S. I was looking through libata and ide sources and documentation
but still dont have broad picture.


Thanks

Re: libata extension

[Bartlomiej Zolnierkiewicz]

Hi,

On Sunday 11 March 2007, Vitaliyi wrote:
> Good Day
> 
> Say i want to implement extended set of ATA commands available to
> userspace for building diagnostic tools.
> I need 0x40 -- read verify and 0x32 -- write long with error handling,

Mark Lord is working on READ/WRITE_LONG support for libata,
he has posted draft patch recently on linux-ide mailing list.

[ Please consider reading/joining linux-ide@vger.kernel.org ML,
  it is where Linux ATA discussion happens... ]

> for example. I was trying ide driver through ioctl's, but seems it
> lack of functionality and full of gotchas. Furthermore it oopses
> sometimes.

READ/WRITE_LONG is unsupported and as you've already noticed
TASKFILE ioctls are full of gotchas...

> Is it possible to use libata for such purpose or i need to write
> separate IDE driver ?

It should be possible using ATA pass-through, some libata changes
may be required but it is the right way to go IMO.

Bart

Re: libata extension

[Mark Lord]

Vitaliyi wrote:
> Good Day
> 
> Say i want to implement extended set of ATA commands available to
> userspace for building diagnostic tools.
> I need 0x40 -- read verify and 0x32 -- write long with error handling,
> for example. I was trying ide driver through ioctl's, but seems it
> lack of functionality and full of gotchas. Furthermore it oopses
> sometimes.

Use the SCSI SG_IO ioctl() with opcode=ATA_16,
which gives you access to the ATA Passthrough mechanism.
This will work for most ATA commands.

I already use it in hdparm and in some other utilities
for scanning/repairing drives.

A notable exeception are the READ/WRITE LONG opcodes,
which require an extra kernel patch from me,
awaiting merge into libata some year.

Cheers

-ml

Fwd: libata extension

[Vitaliyi]

---------- Forwarded message ----------
From: Vitaliyi <imgrey@gmail.com>
Date: Mar 12, 2007 7:03 PM
Subject: Re: libata extension
To: Mark Lord <lkml@rtr.ca>


> Use the SCSI SG_IO ioctl() with opcode=ATA_16,
> which gives you access to the ATA Passthrough mechanism.
> This will work for most ATA commands.

How about soft-reset, is it possible to reach Device Control Register ?
Seems not. I was thinking about patch to libata which allow to use
Control Register.
In the perfect case i would like to be able to execute vendor command
set (reverse engineered).

Is it possible to control timeouts in user space precisely enough and
get rid of unnecessary kernel error messages without touching
syslogd/klogd?

By the way, how to make libata to not probe some ide channel or drive ?

> I already use it in hdparm and in some other utilities
> for scanning/repairing drives.
>
> A notable exeception are the READ/WRITE LONG opcodes,
> which require an extra kernel patch from me,
> awaiting merge into libata some year.

Could you please send me this patch once it's ready ?


Thank you

Re: Fwd: libata extension

[Vitaliyi]

> Why is the access to Control register needed?

To execute soft reset for example.

> > In the perfect case i would like to be able to execute vendor command
> > set (reverse engineered).
>
> Sounds interesting. :-)
>
> Could you give some more details on what are you going to implement?

Reading/writing service area, uploading, downloading modules, working
with flash etc.

Re: Fwd: libata extension

[Jeff Garzik]

Vitaliyi wrote:
>> Why is the access to Control register needed?
> 
> To execute soft reset for example.
> 
>> > In the perfect case i would like to be able to execute vendor command
>> > set (reverse engineered).
>>
>> Sounds interesting. :-)
>>
>> Could you give some more details on what are you going to implement?
> 
> Reading/writing service area, uploading, downloading modules, working
> with flash etc.

SAT (aka ATA passthru) defines how to do soft-reset.

SG_IO supports the ATA_12 and ATA_16 commands which permit soft-reset 
and similar tasks.  libata supports this interface, but does not yet 
support soft-reset and similar non-comment-oriented tasks.  This would 
be the best area to add such features, though.

	Jeff

Re: libata extension

[Robert Hancock]

Vitaliyi wrote:
> Good Day
> 
> Say i want to implement extended set of ATA commands available to
> userspace for building diagnostic tools.
> I need 0x40 -- read verify and 0x32 -- write long with error handling,
> for example. I was trying ide driver through ioctl's, but seems it
> lack of functionality and full of gotchas. Furthermore it oopses
> sometimes.
> 
> Is it possible to use libata for such purpose or i need to write
> separate IDE driver ?
> By the way, i'm sure it should be done in kernel space since i'm going
> to deal with some hdd manufacturer commands.
> 
> P.S. I was looking through libata and ide sources and documentation
> but still dont have broad picture.

I believe you should be able to do this by sending ATA pass-through SCSI 
commands into the device using SG_IO, without any kernel changes. It's 
really the mechanism that's meant for this..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: libata extension

[Alan Cox]

> I believe you should be able to do this by sending ATA pass-through SCSI 
> commands into the device using SG_IO, without any kernel changes. It's 
> really the mechanism that's meant for this..

It should work, but Mark Lord reported some problems with READ_LONG on
PIIX/ICH intel chipsets. I don't know if he ever resolved them but if not
I have a patch that ought to.

Alan