Handling ubinized image flashed on not erased flash space

[Rafał Miłecki]

Déjà vu? Yes! Check:
[PATCH RFC 2/2] ubi: add support for UBI_EC_FLAG_ERASE_FROM_HERE
https://patchwork.ozlabs.org/project/linux-mtd/patch/20161230171151.13448-2-zajec5@gmail.com/


My problem is that some bootloaders don't erase flash partition before
writing a new firmware image. UBI won't like such flash garbage:

ubi0: attaching mtd2
ubi0 error: ubi_attach: bad image sequence number 1646161998 in PEB 119, expected 524503983
Erase counter header dump:
         magic          0x55424923
         version        1
         ec             1
         vid_hdr_offset 2048
         data_offset    4096
         image_seq      1646161998
         hdr_crc        0x1eb28994
erase counter header hexdump:
ubi0 error: ubi_attach_mtd_dev: failed to attach mtd2, error -22
UBI error: cannot attach mtd2


This problem affects e.g. Broadcom's CFE bootloader. There is no always
a way to workaround that or it may require some user-unavailable tricks
(not every user has a serial console to start with).


OpenWrt handles that by:
1. Appending EOF marker to the ubinized image
2. Modifying UBI kernel code to erase everything past EOF marker


I'm looking for a Buildroot solution now. Last time I was told that
upstream kernel is no place for such hacks. It was suggested to use
initramfs with user-space tool to deal with it instead.

My question is: how to do that? I need to erase flash partition starting
with some middle block (the first after ubinized image). I need to get
that offset somehow.

I *can't* scan block after block looking for the first one without a
matching EC magic. That wouldn't work with the same ubinized image
flashed twice.

Reading volumes table, each volume size, trying to calculate ubinized
image size on that data - sounds like overkill for user-space app.

Any suggestions, please?