linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Mike Crowe <mac@mcrowe.com>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: goliath <david.oberhollenzer@sigma-star.at>,
	linux-mtd@lists.infradead.org,
	Richard Weinberger <richard@nod.at>
Subject: Re: [PATCH 0/2] Support skipping bad blocks when seeking to start address
Date: Thu, 5 Jan 2017 15:04:02 +0000	[thread overview]
Message-ID: <20170105150402.GA3931@mcrowe.com> (raw)
In-Reply-To: <20170105154824.5c9e97ee@bbrezillon>

On Thursday 05 January 2017 at 15:48:24 +0100, Boris Brezillon wrote:
> On Thu, 5 Jan 2017 14:18:34 +0000
> Mike Crowe <mac@mcrowe.com> wrote:
> > On Thursday 05 January 2017 at 14:38:23 +0100, goliath wrote:
> > > If your boot loader seeks to a specific erase block by counting
> > > only good blocks (to load the kernel or some second stage?), what
> > > happens if another block in between goes bad? Does that just brick
> > > your board or do you have to move the data around all the time to
> > > account for that?  
> > 
> > The blocks in-between don't get written so they can't be marked bad.
> 
> Maybe not the block in between, but the first block used to store your
> 2nd stage bootloader (or whatever your store at this offset) might
> become bad, which means your data will be moved to the next block (or
> possibly farther).

In our case we always write the remainder of the partition so any bad
blocks that develop will shift everything else down too. You're correct
that this would be a problem if we attempted to write in the middle though.

> I think this request is acceptable (even if I don't like the option
> name :-)), but I'll let Richard and David decide what to do with this
> patch.

I'm not particularly attached to the option name. I chose
"--skip-bad-blocks-to-start" in the hope of being as clear as possible, but
I agree that it is a mouthful! The confusion over the meaning of the option
was also one of the reasons why I originally implemented the feature using
a separate offset.

Thanks for the review.

Mike.

  reply	other threads:[~2017-01-05 15:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-04 14:18 [PATCH 0/2] Support skipping bad blocks when seeking to start address Mike Crowe
2017-01-04 14:18 ` [PATCH 1/2] nandwrite: Add --skip-bad-blocks-to-start option Mike Crowe
2017-01-04 14:18 ` [PATCH 2/2] nanddump: " Mike Crowe
2017-01-05 13:38 ` [PATCH 0/2] Support skipping bad blocks when seeking to start address goliath
2017-01-05 14:18   ` Mike Crowe
2017-01-05 14:48     ` Boris Brezillon
2017-01-05 15:04       ` Mike Crowe [this message]
2017-01-09 12:18         ` David Oberhollenzer
2017-01-09 14:51           ` Mike Crowe
2017-01-11 16:22             ` Mike Crowe
  -- strict thread matches above, loose matches on Subject: below --
2017-01-17 11:54 Mike Crowe
2017-01-23  6:47 ` David Oberhollenzer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170105150402.GA3931@mcrowe.com \
    --to=mac@mcrowe.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=david.oberhollenzer@sigma-star.at \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).