All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] dfu: dfu and UBI Volumes
Date: Mon, 27 May 2013 09:28:36 +0200	[thread overview]
Message-ID: <51A30B24.8080405@denx.de> (raw)
In-Reply-To: <20130527090254.5071e4fd@amdc308.digital.local>

Hello Lukasz,

Am 27.05.2013 09:02, schrieb Lukasz Majewski:
> Hi Heiko,
> 
>> Hello Tom,
>>
>> Am 24.05.2013 19:12, schrieb Tom Rini:
>>> On Fri, May 24, 2013 at 07:42:01PM +0300, Pantelis Antoniou wrote:
>>>> Hi Heiko,
>>>>
>>>> On May 24, 2013, at 7:39 PM, Heiko Schocher wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> just digging in DFU support in U-Boot for an upcoming board
>>>>> support based on an AM335x. This board support uses for example a
>>>>> rootfs in an UBI Volume on a NAND flash, and this should be
>>>>> updated with dfu ...
>>>>>
>>>>> How To do this? Current state on this board is to erase the rootfs
>>>>> mtd partition with a nand erase and write the new image using
>>>>> dfu_nand.c ... which calls in the end nand_write ... which is ...
>>>>> lets say ... not the prefered way on an UBI volume ...
>>>>>
>>>>> How to solve this? Any ideas?
>>>>
>>>> Well, what would you like ideally to do? Why is nand_write not
>>>> ideal for a UBI volume.
>>>>
>>>> Note that dfu will skip over the bad blocks... 
>>>
>>> Presumably because they want to replace say ubi0:rootfs (and leave
>>> ubi0:user-data and ubi0:u-boot-env and so forth alone) rather than
>>> write in a new ubi container of everything.
>>>
>>> I would suggest that, so long as our existing UBI infrastructure
>>> allows this, you add a new method, dfu_ubi which takes care of
>>> programming things.  This shouldn't be too bad to write as I've
>>> heard the existing infrastucture was easily expanded for SPI (and
>>> patches are pending a little more clean up prior to posting).
>>
>> This sounds easy ... but they have also raw nand partitions, for
>> example spl partitions on one nand flash ... for which dfu_nand.c
>> fits perfectly ... is it possible to use dfu_nand.c and another
>> dfu_xxx.c at the same time?
> 
> I'm not so familiar with nand devices handling, but in my opinion we
> shall create dfu_ubi.c file. 
> 
> I think that, nand part of dfu handling shall be separated from ubi,
> even if UBI itself is layed on nand.

Yes, I tend also to this .. but not as a separte "dfu interface .."
"dfu nand .." should stay, and each partition should know, if it
is a raw nand, or UBI, or jffs2?,... as like in dfu_mmc.c ... but
this should not be hardcoded in every dfu_xxx.c, instead it should
be something like a subinterface ... if it is possible.

> However, Tom and Pantelis shall give their opinion, since they spent a
> lot of time on forcing dfu_nand.c to work.

Yep, that would be great, as I am a dfu beginner ;-)

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

  reply	other threads:[~2013-05-27  7:28 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-24 16:39 [U-Boot] dfu: dfu and UBI Volumes Heiko Schocher
2013-05-24 16:42 ` Pantelis Antoniou
2013-05-24 17:12   ` Tom Rini
2013-05-26  7:09     ` Heiko Schocher
2013-05-27  7:02       ` Lukasz Majewski
2013-05-27  7:28         ` Heiko Schocher [this message]
2013-05-27  7:35           ` Pantelis Antoniou
2013-05-27  7:45             ` Heiko Schocher
2013-05-27 16:25               ` Wolfgang Denk
2013-05-27 16:29                 ` Pantelis Antoniou
2013-05-27 20:41                   ` Tom Rini
2013-05-27 21:25                     ` Wolfgang Denk
2013-05-27 23:37                       ` Tom Rini
2013-05-28  5:50                         ` Wolfgang Denk
2013-05-28 15:01                           ` Tom Rini
2013-05-28 15:05                             ` Pantelis Antoniou
2013-05-28 16:31                               ` Benoît Thébaudeau
2013-05-28 16:43                                 ` Pantelis Antoniou
2013-05-28 16:43                                   ` Benoît Thébaudeau
2013-05-28 16:53                                     ` Pantelis Antoniou
2013-05-28 17:23                                 ` Tom Rini
2013-05-28 21:01                                   ` Wolfgang Denk
2013-05-28 21:16                                     ` Tom Rini
2013-05-29  4:35                                       ` Heiko Schocher
2013-05-29 12:09                                         ` Tom Rini
2013-05-28  3:42                       ` Heiko Schocher
2013-05-28  5:55                         ` Wolfgang Denk
2013-05-28 15:35                           ` Tom Rini
2013-05-28  4:10                     ` Heiko Schocher
2013-05-27 19:21       ` Tom Rini
2013-05-28  4:04         ` Heiko Schocher
2013-05-28  5:58           ` Wolfgang Denk
2013-05-28  6:24             ` Heiko Schocher
2013-05-28 16:00               ` Tom Rini
2013-05-24 18:41   ` Wolfgang Denk

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=51A30B24.8080405@denx.de \
    --to=hs@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.