Query mtd-utils v1.4.9 : flash_erase.c

Query mtd-utils v1.4.9 : flash_erase.c

[Kushwaha Prabhakar-B32579]

Hi,

 I checked latest mtd-utils ver 1.4.9 for file flash_erase.c. 

It usage MEMGETOOBSEL ioctl to get OOB information from the driver. But this ioctl may returns error for big NAND chips. 
The reason of failure would be the following condition at linux/driver/mtd/mtdchar.c
 if (mtd->ecclayout->eccbytes > ARRAY_SIZE(oi.eccpos))

MEMGETOOBSEL has been obsolete. then Why mtd-utils still using it.

Also, I don't think flash_erase.c supports MTD_OOB_AUTO. Although its support is already part of Linux kernel. 

Regards,
Prabhakar

Re: Query mtd-utils v1.4.9 : flash_erase.c

[Brian Norris]

On Thu, Apr 5, 2012 at 2:21 AM, Kushwaha Prabhakar-B32579
<B32579@freescale.com> wrote:
>  I checked latest mtd-utils ver 1.4.9 for file flash_erase.c.
>
> It usage MEMGETOOBSEL ioctl to get OOB information from the driver. But this ioctl may returns error for big NAND chips.
> The reason of failure would be the following condition at linux/driver/mtd/mtdchar.c
>  if (mtd->ecclayout->eccbytes > ARRAY_SIZE(oi.eccpos))
>
> MEMGETOOBSEL has been obsolete. then Why mtd-utils still using it.

A few reasons:
(1) There is no replacement interface and there is no plan for a
replacement AFAIK (unless you count MTD_OOB_AUTO within the kernel, as
you mention).
(2) It's only used for the legacy option JFFS2 format option (-j or
--jffs2). JFFS2 isn't supported much anymore, and it probably is not
worth using on "big NAND chips." On some systems, ECC does not even
leave enough room in OOB for JFFS2.

> Also, I don't think flash_erase.c supports MTD_OOB_AUTO. Although its support is already part of Linux kernel.

What do you mean by "support MTD_OOB_AUTO" (this is actually renamed
MTD_OPS_AUTO_OOB, btw)? If you're speaking of the -j option still,
then it's probably because nobody has bothered supporting old features
on new userspace tools with new (large-OOB) chips. This would require
a developer who cares about JFFS2 to compare the various versions of
"autoplace." It wouldn't be too hard to make this use
MTD_OPS_AUTO_OOB; I just haven't studied auto/jffs2 much...

Also, aside from -j, flash_erase is only an *erase* tool, not a
formatting tool, so maybe the -j option is misplaced.

Brian

RE: Query mtd-utils v1.4.9 : flash_erase.c

[Kushwaha Prabhakar-B32579]

Thanks Brian for the clarification.

Please find few more queries in-lined.


> -----Original Message-----
> From: Brian Norris [mailto:computersforpeace@gmail.com]
> Sent: Friday, April 06, 2012 2:28 AM
> To: Kushwaha Prabhakar-B32579
> Cc: Wood Scott-B07421; linux-mtd@lists.infradead.org
> Subject: Re: Query mtd-utils v1.4.9 : flash_erase.c
> 
> On Thu, Apr 5, 2012 at 2:21 AM, Kushwaha Prabhakar-B32579
> <B32579@freescale.com> wrote:
> >  I checked latest mtd-utils ver 1.4.9 for file flash_erase.c.
> >
> > It usage MEMGETOOBSEL ioctl to get OOB information from the driver. But
> this ioctl may returns error for big NAND chips.
> > The reason of failure would be the following condition at
> > linux/driver/mtd/mtdchar.c
> >  if (mtd->ecclayout->eccbytes > ARRAY_SIZE(oi.eccpos))
> >
> > MEMGETOOBSEL has been obsolete. then Why mtd-utils still using it.
> 
> A few reasons:
> (1) There is no replacement interface and there is no plan for a
> replacement AFAIK (unless you count MTD_OOB_AUTO within the kernel, as
> you mention).
> (2) It's only used for the legacy option JFFS2 format option (-j or --
> jffs2). JFFS2 isn't supported much anymore, and it probably is not worth
> using on "big NAND chips." On some systems, ECC does not even leave
> enough room in OOB for JFFS2.

Looks like mtd-utils is no more interested in supporting jffs2 for big NAND chips.

Going forward,  ubifs is the File system for NAND chips supported by mtd-utils??


> 
> > Also, I don't think flash_erase.c supports MTD_OOB_AUTO. Although its
> support is already part of Linux kernel.
> 
> What do you mean by "support MTD_OOB_AUTO" (this is actually renamed
> MTD_OPS_AUTO_OOB, btw)? If you're speaking of the -j option still, then
> it's probably because nobody has bothered supporting old features on new
> userspace tools with new (large-OOB) chips. This would require a
> developer who cares about JFFS2 to compare the various versions of
> "autoplace." It wouldn't be too hard to make this use MTD_OPS_AUTO_OOB; I
> just haven't studied auto/jffs2 much...
> 

Means, If I want to use, I have to make local changes in mtd-utils :(
Is there any plan to support MTD_OPS_AUTO_OOB in future in-case somebody send patch?

--Prabhakar

Re: Query mtd-utils v1.4.9 : flash_erase.c

[Brian Norris]

On Thu, Apr 5, 2012 at 5:44 PM, Kushwaha Prabhakar-B32579
<B32579@freescale.com> wrote:
>> -----Original Message-----
>> From: Brian Norris [mailto:computersforpeace@gmail.com]
>>
>> On Thu, Apr 5, 2012 at 2:21 AM, Kushwaha Prabhakar-B32579 <B32579@freescale.com> wrote:
>> >  I checked latest mtd-utils ver 1.4.9 for file flash_erase.c.
>> >
>> > It usage MEMGETOOBSEL ioctl to get OOB information from the driver. But
>> this ioctl may returns error for big NAND chips.
>> > The reason of failure would be the following condition at
>> > linux/driver/mtd/mtdchar.c
>> >  if (mtd->ecclayout->eccbytes > ARRAY_SIZE(oi.eccpos))
>> >
>> > MEMGETOOBSEL has been obsolete. then Why mtd-utils still using it.
>>
>> A few reasons:
>> (1) There is no replacement interface and there is no plan for a
>> replacement AFAIK (unless you count MTD_OOB_AUTO within the kernel, as
>> you mention).
>> (2) It's only used for the legacy option JFFS2 format option (-j or --
>> jffs2). JFFS2 isn't supported much anymore, and it probably is not worth
>> using on "big NAND chips." On some systems, ECC does not even leave
>> enough room in OOB for JFFS2.
>
> Looks like mtd-utils is no more interested in supporting jffs2 for big NAND chips.
>
> Going forward,  ubifs is the File system for NAND chips supported by mtd-utils??

Personally, I only work with UBIFS.

>> > Also, I don't think flash_erase.c supports MTD_OOB_AUTO. Although its
>> support is already part of Linux kernel.
>>
>> What do you mean by "support MTD_OOB_AUTO" (this is actually renamed
>> MTD_OPS_AUTO_OOB, btw)? If you're speaking of the -j option still, then
>> it's probably because nobody has bothered supporting old features on new
>> userspace tools with new (large-OOB) chips. This would require a
>> developer who cares about JFFS2 to compare the various versions of
>> "autoplace." It wouldn't be too hard to make this use MTD_OPS_AUTO_OOB; I
>> just haven't studied auto/jffs2 much...
>
> Means, If I want to use, I have to make local changes in mtd-utils :(

Not exactly. If you are such a developer who cares about JFFS2 and
will do a little bit of necessary work, then we can integrate your
"local changes" into mtd-utils (provided, of course, they pass some
amount of review). This is open source! As I said, I could probably
write such patches, but I'm not testing JFFS2.

> Is there any plan to support MTD_OPS_AUTO_OOB in future in-case somebody send patch?

At this point, I'd hope others might speak up. Personally, I don't see
why we couldn't accept patch(es) if they are reviewed and tested
properly. I don't know of a "plan."

Brian

Re: Query mtd-utils v1.4.9 : flash_erase.c

[Mike Frysinger]

On Fri, Apr 6, 2012 at 20:52, Brian Norris wrote:
> On Thu, Apr 5, 2012 at 5:44 PM, Kushwaha Prabhakar-B32579 wrote:
>> Is there any plan to support MTD_OPS_AUTO_OOB in future in-case somebody send patch?
>
> At this point, I'd hope others might speak up. Personally, I don't see
> why we couldn't accept patch(es) if they are reviewed and tested
> properly. I don't know of a "plan."

if you cc-ed me in case of a plan, then i don't know of any ;)

mtd (kernel and user) has always seemed like it moves forward as
people have needs and send [good] patches to fulfill those needs
-mike

RE: Query mtd-utils v1.4.9 : flash_erase.c

[Kushwaha Prabhakar-B32579]

Thanks Mike for the reply!!

> -----Original Message-----
> From: Mike Frysinger [mailto:vapier.adi@gmail.com]
> Sent: Saturday, April 07, 2012 10:32 PM
> To: Brian Norris
> Cc: Kushwaha Prabhakar-B32579; Wood Scott-B07421; linux-
> mtd@lists.infradead.org; Artem Bityutskiy
> Subject: Re: Query mtd-utils v1.4.9 : flash_erase.c
> 
> On Fri, Apr 6, 2012 at 20:52, Brian Norris wrote:
> > On Thu, Apr 5, 2012 at 5:44 PM, Kushwaha Prabhakar-B32579 wrote:
> >> Is there any plan to support MTD_OPS_AUTO_OOB in future in-case
> somebody send patch?
> >
> > At this point, I'd hope others might speak up. Personally, I don't see
> > why we couldn't accept patch(es) if they are reviewed and tested
> > properly. I don't know of a "plan."
> 
> if you cc-ed me in case of a plan, then i don't know of any ;)
> 
> mtd (kernel and user) has always seemed like it moves forward as people
> have needs and send [good] patches to fulfill those needs -mike

Yes I am fully agree. I have a question about few patches send long back by "Stanley Miao".
They are as follows:

http://patchwork.ozlabs.org/patch/56261/
http://patchwork.ozlabs.org/patch/56262/
http://patchwork.ozlabs.org/patch/56263/

These patches were never delegated/applied as state are still "New". 

These patches can become a good base for new patches.  

Do anyone has any idea; why were these never applied/delegated?

--Prabhakar

Re: Query mtd-utils v1.4.9 : flash_erase.c

[Mike Frysinger]

On Sun, Apr 8, 2012 at 23:55, Kushwaha Prabhakar-B32579 wrote:
> Yes I am fully agree. I have a question about few patches send long back by "Stanley Miao".
> They are as follows:
>
> http://patchwork.ozlabs.org/patch/56261/
> http://patchwork.ozlabs.org/patch/56262/
> http://patchwork.ozlabs.org/patch/56263/
>
> These patches were never delegated/applied as state are still "New".
>
> These patches can become a good base for new patches.
>
> Do anyone has any idea; why were these never applied/delegated?

they'll certainly need rebasing now as the code has changed, and i can
see some issues that need addressing, but fundamentally, those seem
like a good idea
-mike

RE: Query mtd-utils v1.4.9 : flash_erase.c

[Kushwaha Prabhakar-B32579]

> -----Original Message-----
> From: Mike Frysinger [mailto:vapier.adi@gmail.com]
> Sent: Monday, April 09, 2012 11:04 AM
> To: Kushwaha Prabhakar-B32579
> Cc: Brian Norris; Wood Scott-B07421; linux-mtd@lists.infradead.org; Artem
> Bityutskiy; stanley.miao@windriver.com
> Subject: Re: Query mtd-utils v1.4.9 : flash_erase.c
> 
> On Sun, Apr 8, 2012 at 23:55, Kushwaha Prabhakar-B32579 wrote:
> > Yes I am fully agree. I have a question about few patches send long
> back by "Stanley Miao".
> > They are as follows:
> >
> > http://patchwork.ozlabs.org/patch/56261/
> > http://patchwork.ozlabs.org/patch/56262/
> > http://patchwork.ozlabs.org/patch/56263/
> >
> > These patches were never delegated/applied as state are still "New".
> >
> > These patches can become a good base for new patches.
> >
> > Do anyone has any idea; why were these never applied/delegated?
> 
> they'll certainly need rebasing now as the code has changed, and i can
> see some issues that need addressing, but fundamentally, those seem like
> a good idea

Got your point :)

A general question why these type of patches are not coming in mtd-utils.
Is it because going forward UBIFS is the next file system and nobody wants to focus jffs2.

or

unfortunately developer doesn’t have time. 

--Prabhakar

RE: Query mtd-utils v1.4.9 : flash_erase.c

[Artem Bityutskiy]

On Mon, 2012-04-09 at 06:53 +0000, Kushwaha Prabhakar-B32579 wrote:
> A general question why these type of patches are not coming in mtd-utils.
> Is it because going forward UBIFS is the next file system and nobody wants to focus jffs2.

No one would reject good patches which make JFFS2 and related tools work
on modern flashes. Feel free to submit. WRT to the links you posted -
this was long time ago and I do not remember why they were not merged.
But it looks like Stanley wanted to send a new version but never did
that. Please, read the discussion here:

http://thread.gmane.org/gmane.linux.drivers.mtd/30476/focus=31352

BTW, I agree with Mike that -j option is misplaced and it wold be
cleaner to create a separate jffs2format tool.

Artem.