building M-Sys DOC driver as a module

building M-Sys DOC driver as a module

[Matt Hortman]

Hi.

Does anyone know where (or if) I can find a patch to build the
M-Systems DOC driver as a kernel module?

thanks,

-Matt



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: building M-Sys DOC driver as a module

[Trevor Woolven]

Hi Matt,
Yes this can be and has been done.
There are effectively two ways to do this but we're trying to promote
the one that has M-Systems approval.

Contact Stuart Lynne at Lineo/Fireplug (sl@lineo.com or sl@fireplug.net)

for more details.

If you're unsuccessful, get back to me and I'll see about
'productionizing'
(yuk!) my hack for general release.

Cheers
Trevor.

Matt Hortman wrote:

> Hi.
>
> Does anyone know where (or if) I can find a patch to build the
> M-Systems DOC driver as a kernel module?
>
> thanks,
>
> -Matt
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

--
Zentropix Inc - a Lineo company

Tel: +44 (0)1273 234 647         Fax: +44 (0)1273 704 482

Visit http://www.zentropix.com/ for Real Time Linux Tools
Visit http://www.realtimelinux.org/ for Real Time Linux Information





To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: building M-Sys DOC driver as a module

[Adi Linden]

Hi,

I'd be quite interested in the modular DOC driver as well. So far I've
seen it talked about quite a bit but never seen it.

I produces a 2.2.14 kernel patch for the M-Systems DOC driver but that's
in violation of GPL for a production environment...

TTYL,
Adi



On Thu, 20 Jul 2000, Trevor Woolven wrote:

> Hi Matt,
> Yes this can be and has been done.
> There are effectively two ways to do this but we're trying to promote
> the one that has M-Systems approval.
> 
> Contact Stuart Lynne at Lineo/Fireplug (sl@lineo.com or sl@fireplug.net)
> 
> for more details.
> 
> If you're unsuccessful, get back to me and I'll see about
> 'productionizing'
> (yuk!) my hack for general release.
> 
> Cheers
> Trevor.
> 
> Matt Hortman wrote:
> 
> > Hi.
> >
> > Does anyone know where (or if) I can find a patch to build the
> > M-Systems DOC driver as a kernel module?
> >
> > thanks,
> >
> > -Matt
> >
> > To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
> 
> --
> Zentropix Inc - a Lineo company
> 
> Tel: +44 (0)1273 234 647         Fax: +44 (0)1273 704 482
> 
> Visit http://www.zentropix.com/ for Real Time Linux Tools
> Visit http://www.realtimelinux.org/ for Real Time Linux Information
> 
> 
> 
> 
> 
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
> 



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: building M-Sys DOC driver as a module

[David Woodhouse]

On Thu, 20 Jul 2000, Adi Linden wrote:

> I'd be quite interested in the modular DOC driver as well. So far I've
> seen it talked about quite a bit but never seen it.
> 
> I produces a 2.2.14 kernel patch for the M-Systems DOC driver but that's
> in violation of GPL for a production environment...

Modular drivers and initrd are a horrible waste of space in an embedded
system, IMO. Far better to cut out module support completely, and even
also block device support, putting JFFS on the DiskOnChip instead of NFTL.

The free driver isn't far off being usable in production - there's not a
lot to do, it's just that I haven't had time to do it. Patrick is close to
having ECC support, now we just need to properly thread the NFTL code and
make it deal correctly with bad blocks, and for better efficiency, stick
in the state handling for the individual flash chips, like I did for the
CFI chips.

Trevor - Did I miss something of the TODO list that we drew up?

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: building M-Sys DOC driver as a module

[Ollie Lho]

David Woodhouse wrote:
> Modular drivers and initrd are a horrible waste of space in an embedded
> system, IMO. Far better to cut out module support completely, and even
> also block device support, putting JFFS on the DiskOnChip instead of NFTL.
> 
> The free driver isn't far off being usable in production - there's not a
> lot to do, it's just that I haven't had time to do it. Patrick is close to
> having ECC support, now we just need to properly thread the NFTL code and
> make it deal correctly with bad blocks, and for better efficiency, stick
> in the state handling for the individual flash chips, like I did for the
> CFI chips.
> 
> Trevor - Did I miss something of the TODO list that we drew up?
> 

David,
	I think we will have ext2 on NFTL on DoC Millennium configuration
for LinuxBIOS project so I am also working on revisiting the nftl.c Could
you please send me your TODO list on NFTL stuff ??

Ollie


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: building M-Sys DOC driver as a module

[Trevor Woolven]

[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]

David Woodhouse wrote:

> On Thu, 20 Jul 2000, Adi Linden wrote:
>
> > I'd be quite interested in the modular DOC driver as well. So far I've
> > seen it talked about quite a bit but never seen it.
> >
> > I produces a 2.2.14 kernel patch for the M-Systems DOC driver but that's
> > in violation of GPL for a production environment...
>
> Modular drivers and initrd are a horrible waste of space in an embedded
> system, IMO. Far better to cut out module support completely, and even
> also block device support, putting JFFS on the DiskOnChip instead of NFTL.

Ok, IMHO using an initrd doesn't actually cost you too much, the bulk of it
is used to store the kernel which has to go somewhere, right? I haven't done
a comparison on the relative sizes of a kernel with the driver compiled in vs

one without to measure what the difference is but that would be quite a
simple
thing to do - especially if space was getting tight. I agree that there's a
bit of
a waste having a DOS partition on the DOC to boot syslinux from but neither
LILO nor GRUB are perfect either.

I agree that getting JFFS on DOC is a good thing but when will it happen?
I don't see the M-Systems driver being the driver of choice in the long run,
most people would much rather use a GPL one and that's where MTD wins big
time!

All I'm doing is a short-term fix for expediency.

>
>
> The free driver isn't far off being usable in production - there's not a
> lot to do, it's just that I haven't had time to do it. Patrick is close to
> having ECC support, now we just need to properly thread the NFTL code and
> make it deal correctly with bad blocks, and for better efficiency, stick
> in the state handling for the individual flash chips, like I did for the
> CFI chips.
>
> Trevor - Did I miss something of the TODO list that we drew up?
>

I'm a bit out of the loop on this one :-(
I haven't been following all the updates to the driver be sure.
I've attached the list we drew-up as a memory-jogger (bad pun intended!)

>
> --
> dwmw2
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

--
Zentropix Inc - a Lineo company

Tel: +44 (0)1273 234 647         Fax: +44 (0)1273 704 482

Visit http://www.zentropix.com/ for Real Time Linux Tools
Visit http://www.realtimelinux.org/ for Real Time Linux Information



[-- Attachment #2: mtd-todo-list.txt --]
[-- Type: text/plain, Size: 1841 bytes --]

>From - Mon May 22 15:54:41 2000
X-Mozilla-Status: 0001
Message-ID: <39094DF8.7BD43B12@zentropix.com>
Date: Fri, 28 Apr 2000 09:38:16 +0100
From: Trevor Woolven <trevw@zentropix.com>
Organization: Zentropix
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.2.13 i586)
MIME-Version: 1.0
To: MTD <mtd@infradead.org>
Subject: TODO List
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Everyone,

Dave Woodhouse and I had a meeting yesterday and we came up with the
following list of things that need doing to/fixing in the MTD code:

1	Write Support
	a	ECC
	b	Bad block handling (static)
	c	Bad block detection and handling (dynamic)
	d	Timing constraints
	e	Asynchronous writes

2	FTL fix

3	Support for NOR flash/PCMCIA

4	Support utilities
	a	Formatting
	b	Bad sector/block detection
	c	Consistency checking

5	Documentation
	a	Architectural description
	b	User Guide and API listing
	c	...

6	DOC Millenium support

7	Fix the character device memory copy to/from user space

8	JFFS/FFS2 support

9	GRUB
	a	Filesystem support (NFTL, JFFS etc)
	b	MTD support

10	Execute-in-place

We attempted to prioritize them as we saw fit with the following two
goals: 
	a)	submission to the main-stream linux kernel (2.4/2.5)
	b)	production of a fully GPL alternative to what M-Systems offer

Since Dave's still officially on holiday I agreed to post this to the
list. We're after your opinions and suggestions regarding the TODO list
and the two immediate goals for this work. We're also after volunteers
to take on various parts of the development. Please feel free to comment
upon the above.

Thanks,

Trevor.

--
Zentropix Inc - a Lineo company

Tel: +44 (0)1273 234 647	 Fax: +44 (0)1273 704 482

Visit http://www.zentropix.com/ for Real Time Linux Tools
Visit http://www.realtimelinux.org/ for Real Time Linux Information

Re: building M-Sys DOC driver as a module

[David Woodhouse]

On Fri, 21 Jul 2000, Ollie Lho wrote:

> David,
> 	I think we will have ext2 on NFTL on DoC Millennium configuration
> for LinuxBIOS project so I am also working on revisiting the nftl.c Could
> you please send me your TODO list on NFTL stuff ??

It was posted to the list a while ago. I think it's also on the web site
as part of the main TODO list. Basically, thread the NFTL code and the
DiskOnChip hardware driver, make it handle bad blocks correctly, and
finish ECC. Then fix the remaining bugs :)

I can give a more detailed answer next week when I get home.

--
dwmw2



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: building M-Sys DOC driver as a module

[David Woodhouse]

On Fri, 21 Jul 2000, Trevor Woolven wrote:

> Ok, IMHO using an initrd doesn't actually cost you too much, the bulk
> of it is used to store the kernel which has to go somewhere, right? I
> haven't done a comparison on the relative sizes of a kernel with the
> driver compiled in vs one without to measure what the difference is
> but that would be quite a simple thing to do - especially if space was
> getting tight.

initrd requires block deive support. I want to cut that entirely, too.

> I agree that there's a bit of a waste having a DOS
> partition on the DOC to boot syslinux from but neither LILO nor GRUB
> are perfect either.

LILO should be OK now, with the new bootloader protocol which prevents it
from stomping on the EBDA. Grub will hopefully be driving DoC directly,
very soon.

> 
> I agree that getting JFFS on DOC is a good thing but when will it
> happen? 

As far as I know, it should work now, but it doesn't use the ECC. You only
get the normal JFFS checksumming, and I haven't yet modified it to cut
down the number of writes.

> I don't see the M-Systems driver being the driver of choice in
> the long run, most people would much rather use a GPL one and that's
> where MTD wins big time!
> 
> All I'm doing is a short-term fix for expediency.

This is a very useful thing to do, I agree.

--
dwmw2



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: building M-Sys DOC driver as a module

[Stuart Lynne]

In article <39781EAE.58A56DA3@zentropix.com>,
Trevor Woolven <trevw@zentropix.com> wrote:
>This is a multi-part message in MIME format.
>--------------37FCF4E0556161DE8012872E
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>David Woodhouse wrote:
>
>> On Thu, 20 Jul 2000, Adi Linden wrote:
>>
>> > I'd be quite interested in the modular DOC driver as well. So far I've
>> > seen it talked about quite a bit but never seen it.
>> >
>> > I produces a 2.2.14 kernel patch for the M-Systems DOC driver but that's
>> > in violation of GPL for a production environment...
>>
>> Modular drivers and initrd are a horrible waste of space in an embedded
>> system, IMO. Far better to cut out module support completely, and even
>> also block device support, putting JFFS on the DiskOnChip instead of NFTL.
>
>Ok, IMHO using an initrd doesn't actually cost you too much, the bulk of it
>is used to store the kernel which has to go somewhere, right? I haven't done

The kernel is separate from the initrd file.

The overhead per module for loading it as a module instead of compiling it
in to the kernel is roughly about 2kb.

The initrd file must contain enough to load the module. In theory this means
a statically linked shell, statically linked insmod, a short script and your
modules. Gzipped this ends up around a coupld hundred kb.

It may be possible to used a stripped down busy box that knows enough 
to do this. 

>a comparison on the relative sizes of a kernel with the driver compiled in vs
>
>one without to measure what the difference is but that would be quite a
>simple
>thing to do - especially if space was getting tight. I agree that there's a
>bit of
>a waste having a DOS partition on the DOC to boot syslinux from but neither
>LILO nor GRUB are perfect either.
>
>I agree that getting JFFS on DOC is a good thing but when will it happen?
>I don't see the M-Systems driver being the driver of choice in the long run,
>most people would much rather use a GPL one and that's where MTD wins big
>time!

You also have to support booting from it..... If/when grub can be coaxed into
doing that reliably then it starts to sound interesting.

-- 
                                            __O 
Fireplug - a Lineo company                _-\<,_ 
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <sl@fireplug.net>       www.fireplug.net        604-461-7532


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: building M-Sys DOC driver as a module

[Stuart Lynne]

In article <Pine.LNX.4.21.0007211654230.22633-100000@alpha1.cygnus.co.uk>,
David Woodhouse <dwmw2@alpha1.cygnus.co.uk> wrote:
>On Fri, 21 Jul 2000, Trevor Woolven wrote:
>
>> Ok, IMHO using an initrd doesn't actually cost you too much, the bulk
>> of it is used to store the kernel which has to go somewhere, right? I
>> haven't done a comparison on the relative sizes of a kernel with the
>> driver compiled in vs one without to measure what the difference is
>> but that would be quite a simple thing to do - especially if space was
>> getting tight.
>
>initrd requires block deive support. I want to cut that entirely, too.

Hmmm... for what, are you thinking RAM Disk....

I hope to get the initrd support working against ramfs sometime this summer.

-- 
                                            __O 
Fireplug - a Lineo company                _-\<,_ 
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <sl@fireplug.net>       www.fireplug.net        604-461-7532


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org