Identifying UBI volume instance / storing UBI volume metadata

[Rafał Miłecki]

Hi,

I'm Linux developer involved in OpenWrt & buildroot projects. I work
on building firmware images for home routers but I need to work with
existing designs. I don't work for Broadcom (or any other
manufacturer) and so I can't change how firmware images are handled by
original software.

I'm dealing right now with BCM4908 platform that uses UBI and I need some help.

By Broadcom's design BCM4908 uses two relevant UBI volumes:
1. bootfs
2. rootfs

Every firmware file (accepted by bootloader & original firmware UI)
contains two images: bootfs (with kernel & DTBs) and rootfs. Flashing
firmware (through bootloader of original UI) is a process of simply
writing firmware-contained "bootfs" and "rootfs" images to
corresponding UBI volumes.


My problem is making OpenWrt's design fit that BCM4908 case. OpenWrt
uses two *rootfs* volumes:
1. rootfs: squashfs RO
2. overlay: ubifs overlay

As you can see "overlay" needs to be created by OpenWrt's user space.
It can't be part of flashed firmware file.

My problem is /linking/ "overlay" with currently running firmware. Let
m explain:
Whenever a new flashing happens the OLD "overlay" needs to be
recognized and wiped.
It's required to make sure newly flashed firmware doesn't use non-own data.


My ideas I have for solving that:

1. Getting "bootfs" / "rootfs" volume per-flashing unique number and
writing it in "overlay" ubifs. Then wipe "overlay" on mismatch.
Unfortunately I can't see anything flashing-specific number in UBI
volume header.
Image sequence does never change in my case as UBI doesn't get reformatted.
I'm not sure if sqnum is unique but it seems it can change anyway when
UBI needs to handle with flash wearing.

2. Generating random number and writing it in some metadata of RO
"bootfs" or "rootfs" AND in "overlay" ubifs. Then wipe "overlay" on
mismatch.
That I think would require adding a custom field in the
"ubi_vtbl_record" struct. I'm not sure if upstream UBI can be extended
like that and I don't want such heavy downstream (OpenWrt) hacks.


Any adivces, please?

-- 
Rafał