All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC][DFU] Unification of dfu_alt_info alt settings description + command execution
Date: Thu, 18 Jul 2013 17:10:05 +0200	[thread overview]
Message-ID: <201307181710.05980.marex@denx.de> (raw)
In-Reply-To: <20130718080926.27474380DF1@gemini.denx.de>

Hi,

> Dear Heiko Schocher,
> 
> In message <51E77A1D.90403@denx.de> you wrote:
> > > Try "nand write.trimffs" to write UBI images produced with ubinize .
> > 
> > This solves not the erasecounter problem, or?
> > 
> > For UBI we need something like this:
> > http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo
> > 
> > But I am not an UBI expert. It is possible I overlook something
> > obvious ...
> 
> No, you don't.  Devices managed by UBI should never be erased by
> other, non-UBI-aware tools.

I based my reply on the following commit in U-Boot and the fact that 
write.trimffs is used to flash UBI images. Maybe I was wrong?

commit c9494866df835bcee68e17339aec1090faa704da
Author: Ben Gardiner <bengardiner@nanometrics.ca>
Date:   Tue Jun 14 16:35:07 2011 -0400

    cmd_nand: add nand write.trimffs command
    
    Add another nand write. variant, trimffs. This command will request of
    nand_write_skip_bad() that all trailing all-0xff pages will be
    dropped from eraseblocks when they are written to flash as-per the
    reccommended behaviour of the UBI FAQ [1].
    
    The function that implements this timming is the drop_ffs() function
    by Artem Bityutskiy, ported from the mtd-utils tree.
    
    [1] http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo

Best regards,
Marek Vasut

  reply	other threads:[~2013-07-18 15:10 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-16 15:35 [U-Boot] [RFC][DFU] Unification of dfu_alt_info alt settings description + command execution Lukasz Majewski
2013-07-16 21:27 ` Tormod Volden
2013-07-16 21:46   ` Lukasz Majewski
2013-07-17 10:26 ` Heiko Schocher
2013-07-17 14:34   ` Lukasz Majewski
2013-07-17 17:32     ` Tormod Volden
2013-07-18  5:36     ` Heiko Schocher
2013-07-18  7:13       ` Lukasz Majewski
2013-07-18  4:17   ` Marek Vasut
2013-07-18  5:16     ` Heiko Schocher
2013-07-18  8:09       ` Wolfgang Denk
2013-07-18 15:10         ` Marek Vasut [this message]
2013-07-19  4:45           ` Heiko Schocher
2013-07-19 13:55             ` Marek Vasut
2013-07-18 16:39 ` Tom Rini
2013-07-18 17:30   ` Michael Cashwell
2013-07-18 20:17     ` Lukasz Majewski
2013-07-18 22:33       ` Tom Rini
2013-08-23 10:07     ` Lukasz Majewski
2013-10-31 17:25 ` Lukasz Majewski
2013-10-31 20:32   ` Wolfgang Denk
2013-10-31 21:20     ` Lukasz Majewski
2013-10-31 23:11       ` Wolfgang Denk
2013-11-04  6:52         ` Lukasz Majewski
2013-11-01  6:15   ` Heiko Schocher

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=201307181710.05980.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.