Offtopic: ubifs and best practice for supporting browser based firmware upgrades

[Artem Bityutskiy]

On Mon, 2012-09-03 at 18:45 +0800, Jaya Kumar wrote:
> Hi mtd friends,
> 
> Sorry, I have a somewhat offtopic question. I'm using ubifs, and I'm
> trying to figure out what would be a good way to handle browser based
> firmware upgrades. I've implemented the following:
> 
> - NAND is partitioned into bootloader, kernel, ubifs
> - system is running from ubifs
> - httpd with CGI is running from ubifs
> - user uploads firmware containing ubifs.img (150MB) using this CGI
> - during the upload, the CGI writes the temporary file (up to 150MB)
> to a fat partition on a empty microSD (a non-booting microSD has to be
> always present for this to work)
> - upon completion of the upload, the CGI unpacks the temporary file
> and validates checksums, this of course needs more space since now
> both the temporary file and unpacked results are present
> - then reboot since we can't ubiformat/reflash from the running ubifs
> partition and I can't detach from it for same reason.
> - upon reboot, u-boot script checks for the presence of the ubifs.img
> in the microSD fat partition, if it is there then it nand erases the
> ubifs partition, then does nandwrite of the ubifs.img
> - I realize this loses the erase counters since it is simplistic

If you use ubiformat for erasing, then the erasecounters are preserved.

> - system boots and then removes the upgrade files so that it doesn't
> repeat for each bootup

> This seems clunky and I recognize that if the upgrade is interrupted,
> the unit would be bricked. I was curious how other people implement
> this and what the best practices are. I was thinking whether I should
> have another partition for a small upgrade-only OS, so if u-boot
> detects ubifs.img or a user button press, it boots into the
> upgrade-only OS and then I can run ubiformat from there. I would
> welcome any advice/suggestions.

Well, if you use mSD, you may have space to save the contents of the
partitions which you are trying to update, which would allow to
roll-back to the old system should something go wrong.

Another approach people use is that they have "mirror" UBI volume of the
same size, like "ubifs-reserve". Then the update image is put to
ubifs-reserve, and after this you use the UBI volume rename feature and
rename "ubifs-reserve into" "ubifs". This will kill the old "ubifs"
volume. After this you may resize "ubifs" to something larger, and
create a new "ubifs-reserve" volume.

See "Volume update" here:
http://www.linux-mtd.infradead.org/doc/ubi.html

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120904/8f530ca8/attachment.sig>