flash_erase vs flash_eraseall

flash_erase vs flash_eraseall

[Mike Frysinger]

while looking to extend the erase ioctl abi to take a flags argument,
i needed updated utils to test my work.  reviewing the flash_erase and
flash_eraseall code bases makes me wonder why there are even two tools
in the first place.  "eraseall" sounds like it should simply be an
option to the "erase" util.  so why does it warrant its own code base
for a mere option ?

also in looking at these utils, flash_erase does not support the
extended 64bit api as it is doing ioctls directly nor does it use
getopt.  flash_eraseall however is using the common libmtd api (so it
gets the extend api support for free), and it is cleanly using getopt
cleanly.  which leads to a simple conclusion from my side ...

let's punt the current flash_erase code, rename flash_eraseall to
flash_erase, and then extend its options to support the minor
functionality of flash_erase.  doesnt look like it'll be hard at all
to do this.  but before i undertake the task, i want to make sure the
idea isnt simply going to be rejected due to some concern about
retaining backwards compatibility.

running `flash_erase /dev/mtd#` (no arguments) will make it erase the
first block.  this seems kind of useless to me.

so i'd make the arguments:
flash_erase [options] <mtd> <start> [count]
Options:
  -N, --erasebad
  -j, --jffs2
  -u, --unlock
  -q, --quiet
        --silent

for the "all" functionality, we can have a value of "-1" or "0" for
the count mean "all", or make people type "all".
-mike

RE: flash_erase vs flash_eraseall

[Jon Povey]

linux-mtd-bounces@lists.infradead.org wrote:
> while looking to extend the erase ioctl abi to take a flags argument,
> i needed updated utils to test my work.  reviewing the flash_erase and
> flash_eraseall code bases makes me wonder why there are even two tools
> in the first place.

I was there too recently, I assume it's historical crufty reasons.

I needed more control knobs than mtd-utils supported, I ended up writing
my own "flashtool" combining flash_erase and flash_write features. I don't
know if I can publish the source, but it does things like optionally erase
blocks as it goes along writing, just as many as it needs, option to skip
or fail on bad blocks, absolute maximum offset limit, UBI image writing
mode (skip trailing all-FF pages in a block) and a couple of other things.

It can also do software-generated ECC, rearrange the data/OOB and write
raw (to write layouts not supported by MTD) but that's very device-specific.

More power to you if you want to spruce up some of those utilities, they
seem like they could use some love.

--
Jon Povey
jon.povey@racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network

Re: flash_erase vs flash_eraseall

[Mike Frysinger]

On Wed, Sep 22, 2010 at 21:57, Jon Povey wrote:
> I needed more control knobs than mtd-utils supported, I ended up writing
> my own "flashtool" combining flash_erase and flash_write features. I don't
> know if I can publish the source, but it does things like optionally erase
> blocks as it goes along writing, just as many as it needs, option to skip
> or fail on bad blocks, absolute maximum offset limit, UBI image writing
> mode (skip trailing all-FF pages in a block) and a couple of other things.
>
> It can also do software-generated ECC, rearrange the data/OOB and write
> raw (to write layouts not supported by MTD) but that's very device-specific.

usually for upgrade cycles, i let the kernel do the erase+write for me
(/dev/mtdblock#).  but i know some people would rather have a tool to
do it for them.

in the case of the OOB, i did come across a case there too where it
would be useful if could be transparently generated and overlaid on
the fly ...
-mike

RE: flash_erase vs flash_eraseall

[Jon Povey]

Mike Frysinger wrote:
> On Wed, Sep 22, 2010 at 21:57, Jon Povey wrote:
>> I needed more control knobs than mtd-utils supported, I ended up
>> writing my own "flashtool" combining flash_erase and flash_write
>> features. I don't know if I can publish the source, but it does
>> things like optionally erase blocks as it goes along writing, just
>> as many as it needs, option to skip or fail on bad blocks, absolute
>> maximum offset limit, UBI image writing mode (skip trailing all-FF
>> pages in a block) and a couple of other things.
>>
>> It can also do software-generated ECC, rearrange the data/OOB and
>> write raw (to write layouts not supported by MTD) but that's very
>> device-specific.
>
> usually for upgrade cycles, i let the kernel do the erase+write for me
> (/dev/mtdblock#).  but i know some people would rather have a tool to
> do it for them.

Oh, I'm not very familiar with mtdblock, didn't think of it. Maybe I
could have saved some effort.
How does it handle bad blocks, I wonder out loud to the list?
I have to fail if I hit a bad block in some situations, writing images
for a tiny bootloader that can't skip bad blocks.

> in the case of the OOB, i did come across a case there too where it
> would be useful if could be transparently generated and overlaid on
> the fly ... -mike

The MTD side is pretty easy. Figuring out the inverse of the layout
transformation and implementing the ECC algorithm in software, bakes
your noodle.

--
Jon Povey
jon.povey@racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network

Re: flash_erase vs flash_eraseall

[Mike Frysinger]

On Wed, Sep 22, 2010 at 22:12, Jon Povey wrote:
> Mike Frysinger wrote:
>> On Wed, Sep 22, 2010 at 21:57, Jon Povey wrote:
>>> I needed more control knobs than mtd-utils supported, I ended up
>>> writing my own "flashtool" combining flash_erase and flash_write
>>> features. I don't know if I can publish the source, but it does
>>> things like optionally erase blocks as it goes along writing, just
>>> as many as it needs, option to skip or fail on bad blocks, absolute
>>> maximum offset limit, UBI image writing mode (skip trailing all-FF
>>> pages in a block) and a couple of other things.
>>>
>>> It can also do software-generated ECC, rearrange the data/OOB and
>>> write raw (to write layouts not supported by MTD) but that's very
>>> device-specific.
>>
>> usually for upgrade cycles, i let the kernel do the erase+write for me
>> (/dev/mtdblock#).  but i know some people would rather have a tool to
>> do it for them.
>
> Oh, I'm not very familiar with mtdblock, didn't think of it. Maybe I
> could have saved some effort.
> How does it handle bad blocks, I wonder out loud to the list?
> I have to fail if I hit a bad block in some situations, writing images
> for a tiny bootloader that can't skip bad blocks.

good point ... i dont think it does.  i typically focus more on NOR
(parallel & SPI), so bad blocks arent usually a problem for me.
-mike

Re: flash_erase vs flash_eraseall

[Artem Bityutskiy]

On Wed, 2010-09-22 at 00:35 -0400, Mike Frysinger wrote:
> while looking to extend the erase ioctl abi to take a flags argument,
> i needed updated utils to test my work.  reviewing the flash_erase and
> flash_eraseall code bases makes me wonder why there are even two tools
> in the first place.  "eraseall" sounds like it should simply be an
> option to the "erase" util.  so why does it warrant its own code base
> for a mere option ?

I have no idea, this is historical.

> 
> also in looking at these utils, flash_erase does not support the
> extended 64bit api as it is doing ioctls directly nor does it use
> getopt.  flash_eraseall however is using the common libmtd api (so it
> gets the extend api support for free), and it is cleanly using getopt
> cleanly.  which leads to a simple conclusion from my side ...
> 
> let's punt the current flash_erase code, rename flash_eraseall to
> flash_erase, and then extend its options to support the minor
> functionality of flash_erase.  doesnt look like it'll be hard at all
> to do this.  but before i undertake the task, i want to make sure the
> idea isnt simply going to be rejected due to some concern about
> retaining backwards compatibility.
> 
> running `flash_erase /dev/mtd#` (no arguments) will make it erase the
> first block.  this seems kind of useless to me.
> 
> so i'd make the arguments:
> flash_erase [options] <mtd> <start> [count]
> Options:
>   -N, --erasebad
>   -j, --jffs2
>   -u, --unlock
>   -q, --quiet
>         --silent
> 
> for the "all" functionality, we can have a value of "-1" or "0" for
> the count mean "all", or make people type "all".
> -mike

I'm perfectly fine with getting rid of one of these, this would be a
very good clean-up. May be additionally we could create a
flashe_eraseall shell script which will just run flash_erase <mtd> 0 -1
<other flags>.

But also, it need a careful look to make sure all flash_eraseall
functionality is also in flash_erase.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

Re: flash_erase vs flash_eraseall

[Mike Frysinger]

On Thu, Sep 23, 2010 at 07:24, Artem Bityutskiy wrote:
> On Wed, 2010-09-22 at 00:35 -0400, Mike Frysinger wrote:
>> also in looking at these utils, flash_erase does not support the
>> extended 64bit api as it is doing ioctls directly nor does it use
>> getopt.  flash_eraseall however is using the common libmtd api (so it
>> gets the extend api support for free), and it is cleanly using getopt
>> cleanly.  which leads to a simple conclusion from my side ...
>>
>> let's punt the current flash_erase code, rename flash_eraseall to
>> flash_erase, and then extend its options to support the minor
>> functionality of flash_erase.  doesnt look like it'll be hard at all
>> to do this.  but before i undertake the task, i want to make sure the
>> idea isnt simply going to be rejected due to some concern about
>> retaining backwards compatibility.
>>
>> running `flash_erase /dev/mtd#` (no arguments) will make it erase the
>> first block.  this seems kind of useless to me.
>>
>> so i'd make the arguments:
>> flash_erase [options] <mtd> <start> [count]
>> Options:
>>   -N, --erasebad
>>   -j, --jffs2
>>   -u, --unlock
>>   -q, --quiet
>>         --silent
>>
>> for the "all" functionality, we can have a value of "-1" or "0" for
>> the count mean "all", or make people type "all".
>
> I'm perfectly fine with getting rid of one of these, this would be a
> very good clean-up. May be additionally we could create a
> flashe_eraseall shell script which will just run flash_erase <mtd> 0 -1
> <other flags>.

OK, i'll get going on this then

> But also, it need a careful look to make sure all flash_eraseall
> functionality is also in flash_erase.

shouldnt be too hard :)
-mike