NAND simulator

NAND simulator

[Artem B. Bityutskiy]

Hello,

I'm going to rework NAND simulator (nandsim, drivers/mtd/nand/nandsim.c) 
to add the following functionality:

1. Emulation of devices larger then 128MB
2. Possibility to manually specify any page size/eraseblock size/flash size.

I am going to remove flash delays emulation as it appears to be 
unusable. No objections?

If there are some additional offers, please, provide.

-- 
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.

Re: NAND simulator

[Charles Manning]

On Friday 09 December 2005 01:07, Artem B. Bityutskiy wrote:
> Hello,
>
> I'm going to rework NAND simulator (nandsim, drivers/mtd/nand/nandsim.c)
> to add the following functionality:
>
> 1. Emulation of devices larger then 128MB
Yes please.
> 2. Possibility to manually specify any page size/eraseblock size/flash
> size.
Double yes please! The current way of doing things is very hard to use 
effectively and you need to hack quite a few places to make a useful 
simulation. 

The current approach of simulating a physical device is probably good for 
testing nand.c, but it is not so great for testing file systems. If I want to 
test, for example, a file system on an arrangement of say 350MB then I have 
to go through some crazy steps like making up a fake device id and fake the 
chip id to give what I want. I think a more direct approach of just inserting 
a set of size parameters is far better.

>
> I am going to remove flash delays emulation as it appears to be
> unusable. No objections?

Yup, I don't see much point in trying to simulate the timing. In reality 
nandsim is only really there for algorithmic testing and not time 
simulations.

>
> If there are some additional offers, please, provide.

I assume you mean requests :-). If so, I have a question/request.

Can nandsim simulate storage larger than physical RAM (just swapping out) or 
would this need special support (eg. add some block device support? We're 
getting people in YAFFSland who are working with 8Gbytes of flash (and it 
will only get bigger!) and I expect you'd want large emulations to stress 
JFFS3. Being able to simulate areas up to, say, 16Gbytes for now would be a 
nice thing.

A way of simulating a failure (bit flip, write error) would also be handy for 
testing fs and ecc error handling.


Tell me if you need a guinea pig.

-- Charles

Re: NAND simulator

[Artem B. Bityutskiy]

Charles Manning wrote:
> Yes please.
Uhh, will pospone this for now, will try to repair JFFS2 which doesn't 
work after the last month's commits. Crud! Not sure whom to blame so far.

> Can nandsim simulate storage larger than physical RAM (just swapping out) or 
> would this need special support (eg. add some block device support? We're 
> getting people in YAFFSland who are working with 8Gbytes of flash (and it 
> will only get bigger!) and I expect you'd want large emulations to stress 
> JFFS3. Being able to simulate areas up to, say, 16Gbytes for now would be a 
> nice thing.
Well, did not plan it. But we probably may add this functionality. We 
may borrow it from mtd2blk ...

> A way of simulating a failure (bit flip, write error) would also be handy for 
> testing fs and ecc error handling.
Yeah, good feature. But I'm not sure how to implement an interface for 
this. It is probably easier to hack nandsim and add this manually...

-- 
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.

Re: NAND simulator

[Charles Manning]

On Monday 12 December 2005 02:46, Artem B. Bityutskiy wrote:
> Charles Manning wrote:
> > Yes please.
>
> Uhh, will pospone this for now, will try to repair JFFS2 which doesn't
> work after the last month's commits. Crud! Not sure whom to blame so far.
>
> > Can nandsim simulate storage larger than physical RAM (just swapping out)
> > or would this need special support (eg. add some block device support?
> > We're getting people in YAFFSland who are working with 8Gbytes of flash
> > (and it will only get bigger!) and I expect you'd want large emulations
> > to stress JFFS3. Being able to simulate areas up to, say, 16Gbytes for
> > now would be a nice thing.
>
> Well, did not plan it. But we probably may add this functionality. We
> may borrow it from mtd2blk ...
>
> > A way of simulating a failure (bit flip, write error) would also be handy
> > for testing fs and ecc error handling.
>
> Yeah, good feature. But I'm not sure how to implement an interface for
> this. It is probably easier to hack nandsim and add this manually...

Manual hacking does work. I have done stuff like that in the past. Perhaps 
dynamic hacking could be done via procfs? 
eg, perhaps somethiong like
echo "flip 12345 400 1" > /procfs/nandsim   # flip bit 1 in byte 400, page 
12345

Re: NAND simulator

[Josh Boyer]

On 12/11/05, Charles Manning <manningc2@actrix.gen.nz> wrote:
> On Monday 12 December 2005 02:46, Artem B. Bityutskiy wrote:
> > Charles Manning wrote:
> > > Yes please.
> >
> > Uhh, will pospone this for now, will try to repair JFFS2 which doesn't
> > work after the last month's commits. Crud! Not sure whom to blame so far.
> >
> > > Can nandsim simulate storage larger than physical RAM (just swapping out)
> > > or would this need special support (eg. add some block device support?
> > > We're getting people in YAFFSland who are working with 8Gbytes of flash
> > > (and it will only get bigger!) and I expect you'd want large emulations
> > > to stress JFFS3. Being able to simulate areas up to, say, 16Gbytes for
> > > now would be a nice thing.
> >
> > Well, did not plan it. But we probably may add this functionality. We
> > may borrow it from mtd2blk ...
> >
> > > A way of simulating a failure (bit flip, write error) would also be handy
> > > for testing fs and ecc error handling.
> >
> > Yeah, good feature. But I'm not sure how to implement an interface for
> > this. It is probably easier to hack nandsim and add this manually...
>
> Manual hacking does work. I have done stuff like that in the past. Perhaps
> dynamic hacking could be done via procfs?
> eg, perhaps somethiong like
> echo "flip 12345 400 1" > /procfs/nandsim   # flip bit 1 in byte 400, page
> 12345

Sysfs would be better.  Or debugfs if you really want to be "Right
(tm)".  But the general idea is good.

josh