Success using the IDE code (fwd)

Eugeny S. Mints Eugeny.Mints at oktet.ru
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 OARcorp.com> 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
extend.
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
appropriate)
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
c/src/lib/libcpu/myCPU
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.
Regards,
                        Eugeny
(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 imd-systems.de
> PGP public key available at: http://www.imd-
> systems.de/pgp_key.htm
>

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





More information about the users mailing list