headers
Artem B. Bityutskiy | 2 Apr 2006 12:51
Favicon

Re: [PATCH/RFC] MTD: Striping layer core

On Fri, 2006-03-31 at 11:49 -0500, Nicolas Pitre wrote:
> But... before going that far, is this something that really makes sense 
> in practice?
> IMHO striping NOR and NAND together simply makes no sense.  NOR and NAND 
> are fundamentally different things when it comes to writing to them, and 
> apart from evaluation boards where every possible peripheral can be 
> found you rarely will find both NOR and NAND in the same real life 
> design.
> 
> So why bother?
Err, I did not offer to do this, right? I should have used the
conjunctive mood (would, could be, etc) for that, sorry.

I don't at all think it is sane, I just wanted to say that there is no
fundamental reasons why this cannot work. The other question that this
seems to be a perversion, but it still can work, in theory. And if all
is done correctly, I should be able to stripe NAND and NOR, in theory.
But again, I emphasize, I do not offer to try this combination, or to
test it.

--

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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Artem B. Bityutskiy | 2 Apr 2006 13:22
Favicon

Re: [PATCH/RFC] MTD: Striping layer core

> I'm sorry but I must disagree with your assertion above.
NP :-), I just expressed my opinion, it of course does not have to be
correct!

> Yes the MTD interface might need a big revamp... but why would that be 
> related to stripe at all?
Note, I did not say: guys, I think you definitely must do that. I quote
myself: "And the best thing you can do is"... Well, probably I should
have said "And the best thing you *could do* is"? Please, remember, that
I don't have an excellent feeling of English language (yet, I hope :-))
so some things may sound tough while I do not mean this. Apologies.

I emphasize, I'm saying about how I think it would be better to do this.
If our Intel partners like my Ideas, they may make use of them. If they
don't, they surely don't have to. They may argue and show me that what
I'm talking about is insane. I understand that they may have no time to
re-work MTD.

> Why would a striped MTD device be different from, say, a partitioned MTD 
> device?
I opposite, I think they must look the same way for dumb applications.
But smart applications, which may want to use some stripe-specific
things, still have to have a way to figure out that this MTD device is a
striping device. I hope you don't object here. And I would extend this
statement: 

-- the MTD interface should be completely uniform, but there has to be a
uniform way to figure out the type of the underlying MTD device. Using
this type applications may start using some device-specific things, but
not via mtd_info, but using the corresponding MTD subsystem (NAND
(Continue reading)

Permalink | Reply | 0 comments |
headers
Artem B. Bityutskiy | 2 Apr 2006 14:11
Favicon

Re: [PATCH/RFC] MTD: Striping layer core

On Fri, 2006-03-31 at 12:14 -0500, Nicolas Pitre wrote:
> What needs to be exported is a flash _capability_, not a flash type.

> We don't care a single whit if the flash is NOR or NAND or bufferedNOR 
> or any other bastardized type that will come up in the future.
(/me kindly reminds that this is a sort of "theoretical" conversation,
the current reality is different. And this is a bit out of striping
context even.)

My statement is: applications have the right to know (if they do really
want) which type of device (a striped thing, NAND, NOR, etc) the MTD
device represents. So, mtd_info has to provide this information anyway.
And mtd->type is an excellent field for this.

So, "We don't care a single whit if the flash is NOR or NAND or ...",
unless we really want to, right?

> What MTD users like JFFS2 or mtdchar needs to know is:
> 
>  - what is the minimum write size
> 
>  - what is the optimal write size
> 
>  - can individual bits be cleared
> 
>  - can individual bits be set
This is what I call "the MTD device model". We define a set of
operations and metrics, and then represent any flash using this model.
We don't care that we loose some particular/peculiar features of some
flash types. We are rough. But we are generic. And there is still a way
(Continue reading)

Permalink | Reply | 0 comments |
headers
Artem B. Bityutskiy | 2 Apr 2006 14:34
Favicon

Re: [PATCH/RFC] MTD: Striping layer core

On Fri, 2006-03-31 at 12:19 -0500, Nicolas Pitre wrote:
> So in the end the flash type is redundent and purely informational.

Imagine you're writing a cool flash file system. You want to optimize it
for Sibley NOR. According to my views, you may want to look at
mtd->type, figure out you are working with Sibley NOR, then start
directly talking to the Sybley support subsystem, and realize that
"buffer size". I mean not the minimal I/O size, but that "optimal" I/O
size you mentioned before. So, your file system may be cool and try to
do Input/Out in a more optimal way.

So, for this cool flash file system flash type is an important field.

Of course, you may also use the feature unit I offered. You may, do
things like

if (mtd_feature_available(mtd, MTD_FEATURE_SINGLE_BIT_IO))
etc.

My picture looks very shiny for me :-)

--

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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pramod P K | 3 Apr 2006 05:48
Picon

Using CRAMFS

Hi,
Currently I am having rootfs on jffs2 file system. But I want to use
cramfs file system. Please give me idea/procedure how to do it?
regards,
--pramod

--

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 0 comments |
headers
Vitaly Wool | 3 Apr 2006 06:06

Re: [PATCH/RFC] MTD: Striping layer core

Nicolas Pitre wrote:
> IMHO striping NOR and NAND together simply makes no sense.  NOR and NAND 
> are fundamentally different things when it comes to writing to them, and 
> apart from evaluation boards where every possible peripheral can be 
> found you rarely will find both NOR and NAND in the same real life 
> design.
>   
Oh really? What about MP3 player-oriented design with NAND flash as a 
main storage and NOR flash for kernel/userspace XIP etc?

Vitaly

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 6 comments |
headers
Thomas Gleixner | 3 Apr 2006 08:04
Picon

Re: [PATCH/RFC] MTD: Striping layer core

On Mon, 2006-04-03 at 08:06 +0400, Vitaly Wool wrote:
> Nicolas Pitre wrote:
> > IMHO striping NOR and NAND together simply makes no sense.  NOR and NAND 
> > are fundamentally different things when it comes to writing to them, and 
> > apart from evaluation boards where every possible peripheral can be 
> > found you rarely will find both NOR and NAND in the same real life 
> > design.
> >   
> Oh really? What about MP3 player-oriented design with NAND flash as a 
> main storage and NOR flash for kernel/userspace XIP etc?

Granted, but you can not mix the usage of those chips.

Functions like concat or striping can only be used with FLASH of the
same type. NAND and NOR are so fundamentally different it wont work
without some ugly hack around. There is no point to even think about
that.

Also striping on NAND is a seperate topic. Most new hardware designs
have NAND controllers included which provide e.g. hardware based ECC.
Most of the controllers I'm aware of are not really suitable for
striping due to their design. Also striping would require a fundamental
change to the NAND code, as it currently serializes the access to shared
hardware controllers. This seralization needs to be carefully redesigned
to allow striping and even then it depends on the controller and the
overall hardware design (most designs have OR-wired ready/busy pins)
whether it's possible or not.

I have not looked at the patch closely - and I will not until it is in
an acceptable form - but I have the feeling that the striping support
(Continue reading)

Permalink | Reply | 4 comments |
headers
Vitaly Wool | 3 Apr 2006 08:14

Re: [PATCH/RFC] MTD: Striping layer core

Thomas Gleixner wrote:
> Functions like concat or striping can only be used with FLASH of the
> same type. NAND and NOR are so fundamentally different it wont work
> without some ugly hack around. There is no point to even think about
> that.
>   
I'm afraid I can't object against that ;)
> Also striping on NAND is a seperate topic. Most new hardware designs
> have NAND controllers included which provide e.g. hardware based ECC.
> Most of the controllers I'm aware of are not really suitable for
> striping due to their design. Also striping would require a fundamental
> change to the NAND code, as it currently serializes the access to shared
> hardware controllers. This seralization needs to be carefully redesigned
> to allow striping and even then it depends on the controller and the
> overall hardware design (most designs have OR-wired ready/busy pins)
> whether it's possible or not.
>
>   
Given that some modern NAND controllers have the ability to generate 
interrupt when they're done, I would think about complete redesign of 
the MTD NAND layer. I'd like to see the fully asynchronous base model 
here (i. e. mtd->send_write_cmd/send_read_cmd or something similar) and 
synchronous interface on top of that, just like, say, the current SPI 
core works.
This would allow to be more flexible in waiting for completion and also 
would IMO make striping implementation for NAND more straightforward. 
Does that make sense?

Vitaly
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thomas Gleixner | 3 Apr 2006 08:21
Picon

Re: [PATCH/RFC] MTD: Striping layer core

On Mon, 2006-04-03 at 10:14 +0400, Vitaly Wool wrote:
> Given that some modern NAND controllers have the ability to generate 
> interrupt when they're done, I would think about complete redesign of 
> the MTD NAND layer. I'd like to see the fully asynchronous base model 
> here (i. e. mtd->send_write_cmd/send_read_cmd or something similar) and 
> synchronous interface on top of that, just like, say, the current SPI 
> core works.
> This would allow to be more flexible in waiting for completion and also 
> would IMO make striping implementation for NAND more straightforward. 
> Does that make sense?

In general yes, but it does not solve the problem, where you have _ONE_
shared line for ready/busy -> interrupt for all chips connected to the
hardware controller, nor does it solve the general serialization
requirements to access the controller.

	tglx

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 0 comments |
headers
Artem B. Bityutskiy | 3 Apr 2006 08:59
Picon
Favicon

Re: [PATCH/RFC] MTD: Striping layer core

Thomas Gleixner wrote:
> Functions like concat or striping can only be used with FLASH of the
> same type. NAND and NOR are so fundamentally different it wont work
> without some ugly hack around. There is no point to even think about
> that.

Striping different flash type is an utterly insane perversion indeed.

But still, I imagine 2 MTD devices, one NAND, one NOR. Both can read and 
write. We select the correct eraseblock size and the minimal I/O unit of 
the resulting striped flash (probably much space will be wasted). We 
direct writes to different threads in correspondence to the interleave 
size. And this ugly monster should work in theory! :-)

So, conversely, this ugliness will work if all is done in a generic 
manner and there are *no* ugly hacks! Funny :-) But anyway, let's drop 
the subject.

--

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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Permalink | Reply | 0 comments |

Gmane