[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Success using the IDE code (fwd)
- Date: Tue, 10 Sep 2002 14:53:38 +0400 (MSD)
- From: Eugeny.Mints at oktet.ru (Eugeny S. Mints)
- Subject: Success using the IDE code (fwd)
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
It doesn't - the implementation is hardcoded for powerpc.
But you can
port it to pc386 with minimum changes, I think. But
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
about this - may be another directory may be more
generic IDE controllers driver and particular drivers for
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
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 imd-systems.de
> 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 oktet.ru