writing new BBRAM driver

writing new BBRAM driver

[Alex Pavloff]

Hi there folks.  I've written the struct mtd_info functions for a 128KB
BBRAM driver for my companies new board.  It's horribly simple, as most of
it is actually done by a gate array on the board, so from kernel land its
just poking ioports.  Easy stuff.

Anyway, at this point, I've got that written, but I'm a little hazy as to
what I do next.  Insmod the driver, and then....?

How do I get a drive to mount?

Also, what FS should I use for this BBRAM?

Thanks!

Alex Pavloff - apavloff@eason.com
Eason Technology -- www.eason.com
 

Re: writing new BBRAM driver

[Tobias Otto-Adamczak]

Alex Pavloff, 2002-12-13, 15:45h:

> Hi there folks.  I've written the struct mtd_info functions for a 128KB
> BBRAM driver for my companies new board.  It's horribly simple, as most of
> it is actually done by a gate array on the board, so from kernel land its
> just poking ioports.  Easy stuff.
>
> Anyway, at this point, I've got that written, but I'm a little hazy as to
> what I do next.  Insmod the driver, and then....?

[I am no expert, but anyway ...]

I think you need at least the mtdcore and mtdblock/mtdblock_ro modules,
too (if you want to have a FS in the BBRAM). When you did the insmod,
have a look at /proc/mtd. If your driver registered okay with the mtd
subsystem, it should appear there. Lets say you find it there as mtd0,
you should then be able to access it as a block device under
/dev/mtdblock0. Then you can do everything with it what you would do
with an unformatted hard disk partition (format it, mount it, use it)

> How do I get a drive to mount?

a) Format you block device or copy a pre-formatted image to the BBRAM.
The latter you can do with a simple
	cat <my_preformatted_image >/dev/mtd0
assuming that your BBRAM is registered as mtd0 partition (check with
"cat /proc/mtd") and you have loaded the mtdchar module.

then do a normal mount, e.g.
	mount -o sync -t minix /dev/mtdblock0 /mnt/bbram

> Also, what FS should I use for this BBRAM?

That depends on your hardware and your applications needs. You may want
to try minix. How much (KB) is your BBRAM, anyway ? Maybe you need no FS
at all ?

Ciao
Tobias

Re: writing new BBRAM driver

[Geoffroy Stevenne]

Hi,

On Mon, 16 Dec 2002 11:14:41 +0100 (MET)
Tobias Otto-Adamczak <toa@indakom.de> wrote:

> Alex Pavloff, 2002-12-13, 15:45h:
> 
> > Hi there folks.  I've written the struct mtd_info functions for a
> > 128KB BBRAM driver for my companies new board.  It's horribly
> > simple, as most of it is actually done by a gate array on the board,
> > so from kernel land its just poking ioports.  Easy stuff.

Great! If it works with the versalogic board it will be tested
here with a 512KB BBRAM.  Of course I'll provide maximum feedback
(maybe patches if any required). Thanks!

--
Geoffroy

RE: writing new BBRAM driver

[Alex Pavloff]

> That depends on your hardware and your applications needs. 
> You may want to try minix. How much (KB) is your BBRAM, anyway ? Maybe you

> need no FS at all ?

Alright, I've got most of that stuff done, and the device is there.  It just
reboots when I mount the bbram. :-)  Got some work to do.

I want to use a file system to provide the abstraction layer so that I can
go to a hard drive if needed.  Makes my life easier too, especially on
testing.   My previous product had a 128KB BBRAM that was mapped to a DOS
floppy drive by the bios and formatted with FAT12, and that worked well.
Does the minix fs have a small overhead like FAT12?   Could I use FAT12 if I
was willing to stick with 8.3?  (Which wouldn't be a bad idea anyway, for
other reasons in my project).

Alright, one more question:  What should the erasesize be for BBRAM?
Obviously I'm not worried about wear, so should it be zero or one or
something else?

Thanks!

Alex Pavloff - apavloff@eason.com
Eason Technology -- www.eason.com
 

Re: writing new BBRAM driver

[Jörn Engel]

On Mon, 16 December 2002 14:33:41 -0800, Alex Pavloff wrote:
> 
> Alright, one more question:  What should the erasesize be for BBRAM?
> Obviously I'm not worried about wear, so should it be zero or one or
> something else?

Depends. :-)
For jffs2, you need 5 free blocks for operation. But every used block
eats up ~150Byte roughly, depending on data and compression. Bigger
blocks eat memory, more blocks eat memory, minimum is somewhere in the
middle, you do the math.
For minix, fat, ext2/3 etc., this doesn't really matter. I'd pick 4k,
as that is pagesize on most machines, but even 1byte might work - with
lots of overhead.

Jörn

-- 
But this is not to say that the main benefit of Linux and other GPL
software is lower-cost. Control is the main benefit--cost is secondary.
-- Bruce Perens

RE: writing new BBRAM driver

[Tobias Otto-Adamczak]

Alex Pavloff, 2002-12-16, 14:33h:

> Does the minix fs have a small overhead like FAT12?   Could I use FAT12 if I
> was willing to stick with 8.3?  (Which wouldn't be a bad idea anyway, for
> other reasons in my project).

Of course you can use FAT12 if that suits your needs.

> Alright, one more question:  What should the erasesize be for BBRAM?

I set it to 0 for my project. I read in other messages here that
blocksize=erasesize but for erasesize=0 this is definitely not the case
:-) I did no modifications to the slram code and the sizes are:

erasesize=0 byte
sectorsize=512 byte
blocksize=1024 byte

Be careful to use fresh mtd code when you try this (in the latest
slram.c, it is predefined with 0 anyway). I run into problems with old
releases.

Tobias

Re: writing new BBRAM driver

[Alex Pavloff]

Sorry, repost with a proper header... grr...

> Date: Mon, 16 Dec 2002 13:54:14 +0100
> From: Geoffroy Stevenne <geof@hellea.com>
> To: linux-mtd@lists.infradead.org
> Subject: Re: writing new BBRAM driver
> Organization: Hellea SPRl
> 
> 
> Hi,
> 
> On Mon, 16 Dec 2002 11:14:41 +0100 (MET)
> Tobias Otto-Adamczak <toa@indakom.de> wrote:
> 
> > Alex Pavloff, 2002-12-13, 15:45h:
> > 
> > > Hi there folks.  I've written the struct mtd_info functions for a
> > > 128KB BBRAM driver for my companies new board.  It's horribly
> > > simple, as most of it is actually done by a gate array on 
> the board,
> > > so from kernel land its just poking ioports.  Easy stuff.
> 
> Great! If it works with the versalogic board it will be tested
> here with a 512KB BBRAM.  Of course I'll provide maximum feedback
> (maybe patches if any required). Thanks!

Sadly, its an integrated piece of hardware that goes onto a
power/touchscreen/bbram mezzanine board that fits directly on top of a geode
"biscuit" SBC board and connects via PC104.  I'll make the source available,
but I really don't think it'll be useful to anyone else as something other
than an example.

I'm still trying to figure out some stuff.

The BBRAM formats to 122KB, which is fine.  I can copy files to & from it.
Since my device can be powered down at any second, I'm might want to use a
journalling filesystem, but, well, I don't need any sort of wear levelling,
so I think jffs/2 is overkill.  Shall I just run minix and just fsck the
drive on powerup or us there some sort of small non-wear-levelling yet
journalling filesystem that I could use?

Secondly:  erasesize.  I have to define a "erase" function (like that of the
test RAM device) and define MTD_ERASEABLE and I've got the erasesize set to
0.  Is this ok?  Will this be called?  Should I make erase size larger for
some reason?

And lastly, while I've got you here, does anyone have any info on why
certain CompactFlash pieces don't work properly in IDE mode without file
corruption?

A range of possible theories have been proposed
 1)  Slow write speed of flash falling out of IDE spec
 2)  Crappy controller chips with IDE code that isn't up to spec
 3)  Linux affinity for SanDisk only, require the =flash option boot

I don't have any flash that does this, but its out there.  All thoughts
appreciated.

Thanks for the great subsystem.

Alex Pavloff - apavloff@eason.com
Eason Technology -- www.eason.com