From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Pintu Agarwal <pintu.ping@gmail.com>
Cc: Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-mtd <linux-mtd@lists.infradead.org>,
chengzhihao1@huawei.com,
open list <linux-kernel@vger.kernel.org>
Subject: Re: Block based OTA update needs mtdblock
Date: Tue, 03 Dec 2024 15:17:06 +0100 [thread overview]
Message-ID: <87ldww4zrx.fsf@bootlin.com> (raw)
In-Reply-To: <CAOuPNLhhWzoBQH85zEd95LbONtrknq+b7tfcze50VPa9bEnXzw@mail.gmail.com> (Pintu Agarwal's message of "Wed, 20 Nov 2024 12:52:57 +0530")
Hello,
On 20/11/2024 at 12:52:57 +0530, Pintu Agarwal <pintu.ping@gmail.com> wrote:
> Hi,
>
> On Mon, 4 Nov 2024 at 21:31, Pintu Agarwal <pintu.ping@gmail.com> wrote:
>>
>> Hi All,
>>
>> For one of our automotive products we have the following configuration:
>> QC chipset, arm64, Kernel-5.15, NAND Flash 1GB, A/B system, UBI
>> volumes (squashfs, ubifs), DM-verity for rootfs (squashfs), simple
>> busybox platform.
>>
>> For OTA updates we have a strong dependency with MTD_BLOCK.
>>
>> Till now, we were using ubiblock for mounting squashfs volumes and
>> completely got rid of mtd_block by configuring it as a loadable
>> module.
>> But, we also need to support OTA updates (Full, Incremental) on A/B
>> volumes using the same Android OTA framework.
>> https://source.android.com/docs/core/ota/nonab/block
>>
>> OTA update will be applied to the B (inactive) partition.
>> OTA updates prefer block based update over file based especially for
>> dm-verity enabled devices.
>>
>> Now, the problem is, on MTD we only have 2 options for block based
>> updates; ubi_block or mtd_block.
>> We cannot use ubiblock for OTA updates as it is read only.
>> For full update volume, we can use "ubiupdatevol" interface to
>> completely replace the volume content, but for partial or incremental
>> update we need to update only specific blocks and not entire
>> partitions.
>> Thus, we have to use the MTD_BLOCK (/dev/mtdblock) interface to
>> support block based OTA updates on UBI volumes.
>> Thus, during ota updates (only) we need to install the mtdblock
>> module, perform the update and then uninstall the module.
>>
>> That means, we cannot completely get rid of MTD_BLOCK from our product
>> especially for OTA use cases.
>>
>> Is this the only way, or do we have any other option to support OTA
>> updates over UBI volumes ?
>>
> Restarting this thread again...
> Any further comment on this ?
>
> Did anybody used block based OTA update NAND A/B system without using
> mtd_block ?
Not on my side, it is actually a good question. Richard, any ideas?
> Since ubiblock is read-only, it seems there is no other way to perform
> OTA update, if mtd_block is disabled.
> Or, we need to make ubiblock also as read/write.
Doesn't sound possible/a good idea.
I'm sorry for this unhelpful answer :-)
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Pintu Agarwal <pintu.ping@gmail.com>
Cc: Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-mtd <linux-mtd@lists.infradead.org>,
chengzhihao1@huawei.com,
open list <linux-kernel@vger.kernel.org>
Subject: Re: Block based OTA update needs mtdblock
Date: Tue, 03 Dec 2024 15:17:06 +0100 [thread overview]
Message-ID: <87ldww4zrx.fsf@bootlin.com> (raw)
In-Reply-To: <CAOuPNLhhWzoBQH85zEd95LbONtrknq+b7tfcze50VPa9bEnXzw@mail.gmail.com> (Pintu Agarwal's message of "Wed, 20 Nov 2024 12:52:57 +0530")
Hello,
On 20/11/2024 at 12:52:57 +0530, Pintu Agarwal <pintu.ping@gmail.com> wrote:
> Hi,
>
> On Mon, 4 Nov 2024 at 21:31, Pintu Agarwal <pintu.ping@gmail.com> wrote:
>>
>> Hi All,
>>
>> For one of our automotive products we have the following configuration:
>> QC chipset, arm64, Kernel-5.15, NAND Flash 1GB, A/B system, UBI
>> volumes (squashfs, ubifs), DM-verity for rootfs (squashfs), simple
>> busybox platform.
>>
>> For OTA updates we have a strong dependency with MTD_BLOCK.
>>
>> Till now, we were using ubiblock for mounting squashfs volumes and
>> completely got rid of mtd_block by configuring it as a loadable
>> module.
>> But, we also need to support OTA updates (Full, Incremental) on A/B
>> volumes using the same Android OTA framework.
>> https://source.android.com/docs/core/ota/nonab/block
>>
>> OTA update will be applied to the B (inactive) partition.
>> OTA updates prefer block based update over file based especially for
>> dm-verity enabled devices.
>>
>> Now, the problem is, on MTD we only have 2 options for block based
>> updates; ubi_block or mtd_block.
>> We cannot use ubiblock for OTA updates as it is read only.
>> For full update volume, we can use "ubiupdatevol" interface to
>> completely replace the volume content, but for partial or incremental
>> update we need to update only specific blocks and not entire
>> partitions.
>> Thus, we have to use the MTD_BLOCK (/dev/mtdblock) interface to
>> support block based OTA updates on UBI volumes.
>> Thus, during ota updates (only) we need to install the mtdblock
>> module, perform the update and then uninstall the module.
>>
>> That means, we cannot completely get rid of MTD_BLOCK from our product
>> especially for OTA use cases.
>>
>> Is this the only way, or do we have any other option to support OTA
>> updates over UBI volumes ?
>>
> Restarting this thread again...
> Any further comment on this ?
>
> Did anybody used block based OTA update NAND A/B system without using
> mtd_block ?
Not on my side, it is actually a good question. Richard, any ideas?
> Since ubiblock is read-only, it seems there is no other way to perform
> OTA update, if mtd_block is disabled.
> Or, we need to make ubiblock also as read/write.
Doesn't sound possible/a good idea.
I'm sorry for this unhelpful answer :-)
Miquèl
next prev parent reply other threads:[~2024-12-03 15:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-04 16:01 Block based OTA update needs mtdblock Pintu Agarwal
2024-11-05 2:15 ` Zhihao Cheng
2024-11-05 7:01 ` Pintu Agarwal
2024-11-20 7:22 ` Pintu Agarwal
2024-11-20 7:22 ` Pintu Agarwal
2024-12-03 14:17 ` Miquel Raynal [this message]
2024-12-03 14:17 ` Miquel Raynal
2024-12-03 16:08 ` Richard Weinberger
2024-12-03 16:08 ` Richard Weinberger
2024-12-04 9:58 ` Pintu Agarwal
2024-12-04 9:58 ` Pintu Agarwal
2024-12-04 10:16 ` Richard Weinberger
2024-12-04 10:16 ` Richard Weinberger
2024-12-05 7:43 ` Pintu Agarwal
2024-12-05 7:43 ` Pintu Agarwal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ldww4zrx.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=chengzhihao1@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=pintu.ping@gmail.com \
--cc=richard@nod.at \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.