Re[2]: RFC: kernel-based PCMCIA ...

Re[2]: RFC: kernel-based PCMCIA ...

[Mike Kilburn]

David Woodhouse <David.Woodhouse@mvhi.com> wrote:
> 
> My main concern at the moment is producing a standalone driver for the
> DoC2000,
> with FTL built-in to it, for embedded systems using the 2.0 kernel. As soon
> as
> I've done that, I'll be turning back to the generic subsystem design, and
> producing a DoC2000 driver for the new system.

Is there any beta code available for this. We have a PC104 with a 4M boot
flash from M-Systems. The vendor of the PC104 wont give us any hardware 
details on accessing the Flash and they say they are working with M-Systems
to have a driver in a month or so. We dont want to be dependent on them for
a driver.

> 
> As an aside - we may have patent problems with using FTL on anything other 
> than PCMCIA devices. Our position on this is as yet undecided. 
> I've suggested that perhaps the flags for each low-level device should
> include
> a PCMCIA/ NON-PCMCIA bit, and the default configuration of the FTL driver
> should refuse to work with non-PCMCIA devices. I don't really know what else
> we
> can do.

Why would a PCMICA be any different than a Flash on a PC104 cpu card?



To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk

Re: RFC: kernel-based PCMCIA ...

[David Woodhouse]

< Followup to a post to linux-kernel, archived at 
	http://www.deja.com/getdoc.xp?AN=479544719&fmt=text >

Hello Werner,

almesber@lrc.di.epfl.ch said:
> ... for getting access to storage cards in early stages of porting,
> where user space development is still difficult. (E.g. because there's
> no libc port, no distribution, etc.)
> 
> This patch is vs. 2.3.3. Documentation is included.
>
>  Comments ? 

Not only 'in early stages of porting', but for root filesystems on embedded 
devices, where initrd is a blatant waste of space.

I've been looking at this for some time, on and off, and have produced a 
generic 'memory technology device' layer which will allow simple hardware 
drivers to be interfaced to a more generic upper layer which covers such 
things as the FTL filesystem.

My code borrowed very heavily from David Hinds' existing such code in the 
PCMCIA distribution.

Also, Alexander Larsson has produced some code very similar in principle to 
these. 

I have recently started a mailing list (mtd@imladris.demon.co.uk,
majordomo-managed) for discussion of this. It might be useful if you could join
us there. 

The tentative conclusion that (I think) we've reached so far is that we will
use Alexander's version of the code as a basis for further work. 

We will attempt to make this provide all the functionality required by the
existing MTD layer in the PCMCIA code, with a view to including it in the 2.3
kernels, and converting the PCMCIA code to use it (when present).

I'm actively working on drivers for the Disk-On-Chip 2000 from M-systems. We 
already have drivers for CFI-compliant flash memories, and for the ISA flash 
cards from M-Systems. There is also a driver to use uncacheable main memory as 
a memory device, which I've used mainly for testing.

My main concern at the moment is producing a standalone driver for the DoC2000,
with FTL built-in to it, for embedded systems using the 2.0 kernel. As soon as
I've done that, I'll be turning back to the generic subsystem design, and
producing a DoC2000 driver for the new system.

I suppose that we should start by taking Alexander's code and merging in all
the functionality required by the PCMCIA system, at which point we can look at
making it presentable to Linus for 2.3.soon. New memory hardware drivers can be
added as and when they're completed.

My main criterion for this 'merge' (and I'm sure that David Hinds will back me
up on this one) is that it should be simple for the PCMCIA code to switch 
between the two subsystems, preferably with no more than a few #ifdefs in a 
single header file.

As an aside - we may have patent problems with using FTL on anything other 
than PCMCIA devices. Our position on this is as yet undecided. 
I've suggested that perhaps the flags for each low-level device should include
a PCMCIA/ NON-PCMCIA bit, and the default configuration of the FTL driver
should refuse to work with non-PCMCIA devices. I don't really know what else we
can do.

Anyway, I hope that I've wittered for long enough to spark some productive 
debate on the subject. As soon as we have some conclusions, I'll put up a web 
site for the project, too, on http://imladris.mvhi.com/mtd/ 

I'd like to set up a list archive, too - but I'm busy on trying to hack the 
Disk-On-Chip. Any volunteers for the task, please contact me and I'll give you 
an account to play with.


----                                 ----                                 ----
David Woodhouse        David.Woodhouse@mvhi.com       Office: (+44) 1223 810302
 Project Leader,     Process Information Systems      Mobile: (+44) 976 658355
    Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
             finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.




To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk

Re: Re[2]: RFC: kernel-based PCMCIA ...

[David Woodhouse]

mkilburn@ftel.net said:
>  Is there any beta code available for this. We have a PC104 with a 4M
> boot flash from M-Systems. The vendor of the PC104 wont give us any
> hardware  details on accessing the Flash and they say they are working
> with M-Systems to have a driver in a month or so. We dont want to be
> dependent on them for a driver.

There's some very preliminary stuff, which isn't anywhere near working at the
moment. 

I've tried a few approaches - I've disassembled the entire binary Linux driver,
and looked at how it deals with the device. I've also traced the BIOS startup
code on the device, including converting parts of it into C code and running 
them. I'm about to start with Dosemu, getting it to log all accesses to the 
device - I don't have a bus analyser or I'd do it that way.

Often with things like this, you'll see bits of how it works, and understand
what they were thinking when they designed it - and you'll be able to make 
(correct) assumptions about how it all goes together. The DoC2000 seems to be 
a product of a warped imagination, though - I have no clue what it's doing 
most of the time.

It doesn't look like it ever actually maps the flash in the CPU's memory map, 
though - it may well only allow sequential cpu-driven reads of individual 
bytes, which would explain the extremely poor performance of the thing.

I'm currently trying to tidy up the notes I do have, and will post them to the 
list later this afternoon, to see if anyone else has any more insight into the 
thing than I have.

> > As an aside - we may have patent problems with using FTL on anything
> > other than PCMCIA devices. 

> Why would a PCMICA be any different than a Flash on a PC104 cpu card?

>From a technical viewpoint - no reason at all. However, M-Systems apparently
own the patent, and have granted free use of it with PCMCIA devices. Using it 
on non-PCMCIA devices doesn't come under that blanket permission, so approval 
would have to be obtained from them.



----                                 ----                                 ----
David Woodhouse        David.Woodhouse@mvhi.com       Office: (+44) 1223 810302
 Project Leader,     Process Information Systems      Mobile: (+44) 976 658355
    Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
             finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.




To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk

Re: RFC: kernel-based PCMCIA ...

[Jason Gunthorpe]

On Thu, 20 May 1999, David Woodhouse wrote:

> We will attempt to make this provide all the functionality required by the
> existing MTD layer in the PCMCIA code, with a view to including it in the 2.3
> kernels, and converting the PCMCIA code to use it (when present).

Has there been an talk of a FFS driver for linux? Also, has anyone done
any work on writing drivers for ordinary flash chips (ie on embedded
systems) 

Thanks,
Jason



To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk