Flashing UBIFS image to gluebi mtd

[Konstantin Tokarev]

01.11.2013, 13:43, "Ricard Wanderlof" <ricard.wanderlof at axis.com>:

>  On Fri, 1 Nov 2013, Konstantin Tokarev wrote:
>>>>    Btw, I'm more interested in finding out in what way my UBIFS volume can be
>>>>    broken in given scenario and how can I detect it (to reflash once again,
>>>>    using UBI-aware updater this time).
>>>   You didn't mention how you overwrote your UBI partition with new data. dd
>>>   ? nandwrite ?
>>   I write data to mtd device file (gluebi-based in this case) using write()
>>   function, one mtd eraseblock at a time. Effectively it's the same as dd.
>  How do you handle potential bad blocks in the flash ?

Bad blocks are detected using ioctl on mtd device (MEMGETBADBLOCK) and skipped,
though AFAIU gluebi mtd cannot have bad blocks.

>>>   Also I don't think you mentioned exactly your old setup. I'm assuming
>>>   squashfs on top of mtd, with no UBI involved, right?
>>   No, on top of UBI (to handle bad blocks and wear leveling).
>  Sorry, my bad, reading your post again I see that you explicitly stated
>  squashfs on top of gluebi ...
>>>   I'm getting the impression your problem is based on the fact
>>>   that when updating the firmware, you are using update firmware which is
>>>   not UBI aware, and you don't get UBI-awareness on the system until you've
>>>   done the update.
>>   Exactly.
>  ... which means that you've been running UBI all the time, but not ubifs.
>  (?)

Yes.

I guess that we should have written SquashFS images using UBI volume update
procedure as well, to UBI device instead of gluebi MTD. Code was written to
write filesystems like JFFS2 to raw MTD's and just reused here without second
thought.

>>>   A chicken-and-egg-situation. One solution in that case
>>>   would be to have an intermediate firmware which was identical to what was
>>>   in the device to start with but that had an UBI-aware upgrade application.
>>   Not a solution, because end user of device might skip this intermediate
>>   firmware accidentally.
>  I was afraid of that ... :-)
>>   It would be perfectly OK if rootfs failed to mount after update because
>>   it led to reflash once again with the same firmware. It would be possible
>>   to do any new consistency check, because initramfs software had already
>>   been upgraded.
>>
>>   The problem is that incorrectly flashed UBIFS mounts without error,
>>   all content is readable and has valid md5sums, and file write and
>>   mv operations also succeed.
>  But in your original post, the following line was present in the log:
>
>  UBIFS warning (pid 383): ubifs_ro_mode: switched to read-only mode, error
>  -5
>
>  indicating that writing had been switched off due to the errors detected.
>  Of course, this might be arbitrary depending on exactly which errors
>  happened to occur at that particular boot instance.

I've read code of gluebi_write in gluebi.c, vol_cdev_ioctl in cdev.c, and
ubi_start_update in upd.c - looks like the only difference between correct
update and what is done in my case is that volume is not wiped out before
writing new volume image here.

(I know that raw mtd on NAND should be erased as well, but this is not done
for gluebi MTD because our code erases MTD only if MTD type == MTD_NANDFLASH)

-- 
Regards,
Konstantin