Flashing UBIFS image to gluebi mtd

Ricard Wanderlof ricard.wanderlof at axis.com
Fri Nov 1 05:43:23 EDT 2013


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 ?

>> 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. 
(?)

>> 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.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30



More information about the linux-mtd mailing list