[U-Boot] dfu: dfu and UBI Volumes

[Heiko Schocher <hs@denx.de>]

Hello,

Am 27.05.2013 09:35, schrieb Pantelis Antoniou:
> Hi Guys,
> 
> On May 27, 2013, at 10:28 AM, Heiko Schocher wrote:
> 
>> 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.
>>
> 
> I'm not completely up to speed with UBI, but dfu_ubi seems to be the way
> to go for me.

But how to handle a raw nand partition and a ubi partition on one
nand?

If ubi is a new dfu interface, somebody must start dfu on u-boot
with "dfu nand .." or "dfu ubi .." dependent on which partition
has to be updated ... before using dfu-util on the host side ...
and start dfu-util for the correct partition...

This seems not really userfriendly to me ... if I have to use the
u-boot shell, why using dfu-util on a host pc instead executing tftp
and update my images within u-boot?

Is ubi really a "interface" as nand or mmc ... ?

> Looks like it's simple enough; erase (but don't step over the wear counters)
> , write (but skip over the wear counters).

Yep, or load the complete image in ram, and write it with "ubi write ..."

> I don't know how smart you have to be with UBI version; be very careful
> when the binary format of UBI changes.

Thanks!

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