Success using the IDE code (fwd)

Eugeny S. Mints Eugeny.Mints at
Tue Sep 10 10:53:38 UTC 2002

On Tue, 10 Sep 2002, Thomas Doerfler wrote:

> Hello Joel, Hello Peter,
> sorry for the late reply, but my wife was on holidays for one
> week and I was pretty busy with the kids. =:->
> first of all: It's nice to hear, that the IDE driver and the
> whole FAT machinery is working fine on other boards aswell.
> > > Joel Sherrill <joel.sherrill at> wrote:
> > >
> > > >
> > > > Hi,
> > > >
> > > > I am having a brain lapse this morning.  Where is the source code for
> > > > the
> > > > IDE driver in the source tree currently?  I can't seem to find it. :(
> I got the same result when I looked for the code some time
> ago... So I think we intended to integrate the IDE driver as a
> specific driver for the MBX8xx BSP, but it has gone (or never
> been there?) in the CVS.
> In the long run a location in libchip would be fine, but this
> will require great modifications of the code due to the
> different way to access registers. And at least one BSP
> specific base function will be required to initialize the IDE
> hardware and specify the base address.

I've already sent the following but haven't heard any
comment :( but it still seems to me that proposed
architecture is apropriate enough:
(my old letter:)

Does the IDE driver work for the pc386 derivatives in the
current snapshot?

It doesn't - the implementation is hardcoded for powerpc.
But you can
port it to pc386 with minimum changes, I think. But
unfortunately current
IDE driver implementation have architecture which is hard to
We propose the following architecture:
generic ATA driver (chip and CPU independant; only
implementation of ATA
standart) locates in c/src/exec/libblock (although I'm not
absolute sure
about this - may be another directory may be more
generic IDE controllers driver and particular drivers for
standart ide
controller chips  locate in c/src/libchip/ide
if ide capacity is integrated into CPU then drivers for such
ide locate in
and if ide controller is somthing custom (for example on
FPGA) then
driver for it goes to c/src/lib/libbsp/myBSP
Such architecture allows, for example, simply start IDE on
any target board - just implement particular on-board IDE
controller driver and go on.
Currently I've done most part of the work. Because of this I
don't think that port of Linux driver is necessary now (but of course,
than more activities then better :)). Also license
difference need attention I think.
(end of old letter)

The implementation had been ready a month ago and we are
successfully using full (read/write) IDE acces on our
custom board based on SH4 CPU with custom IDE controller.
But last month I was on vacation and just returned. I think I'm in
the week from commitment of the code.

> One problem with such a solution would be performance: I don't
> think it is ok to actually perform function calls to acess any
> register, because in PIO mode (the only one supported now)
> there are several register accesses for each byte transferred
> and it would really slow down throughput.

For example, in my implementation I use single call for
transfer of the whole data block(sector or set of sectors in
case of READ/WRITE multiple commands). Anyway, speed of IDE
access doesn't seem to me too slow.

>On the other hand I
> don't think there is any IDE interface having gaps in the
> address map, so maybe performing direct accesses to the
> registers (at variable addresses, with variable Endianess)
> would be acceptable. What do you think, Joel?
> A third solution would be to define a bunch of pointers, each
> pointing to one dedicated IDE register. These pointers would
> have to be initialized once, and then the code to access the
> registers could really be embedded into the IDE driver, not
> using function calls for each access.
> Hm, having a closer look on what I have written right now this
> will not work, because it would only cover memory mapped
> peripherals, and not the I/O space of i386.
> Is there some way to make the preprocessor handle the
> distinction? Joel, do you have any idea on that?
> Still thinking about it....
> 	Thomas Doerfler.
> --------------------------------------------
> IMD Ingenieurbuero fuer Microcomputertechnik
> Thomas Doerfler           Herbststrasse 8
> D-82178 Puchheim          Germany
> email:    Thomas.Doerfler at
> PGP public key available at: http://www.imd-

Eugeny S. Mints
1 Ulianovskaya st., Petergof, St.Petersburg, 198904 Russia
Phone: +7(812)428-4384 Fax: +7(812)327-2246
mailto:Eugeny.Mints at

More information about the users mailing list