All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Pintu Agarwal <pintu.ping@gmail.com>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	 linux-mtd <linux-mtd@lists.infradead.org>,
	 chengzhihao1 <chengzhihao1@huawei.com>,
	 linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Block based OTA update needs mtdblock
Date: Tue, 3 Dec 2024 17:08:14 +0100 (CET)	[thread overview]
Message-ID: <342000380.28770675.1733242094522.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <87ldww4zrx.fsf@bootlin.com>

----- Ursprüngliche Mail -----
> Von: "Miquel Raynal" <miquel.raynal@bootlin.com>
> An: "Pintu Agarwal" <pintu.ping@gmail.com>
> CC: "richard" <richard@nod.at>, "Vignesh Raghavendra" <vigneshr@ti.com>, "linux-mtd" <linux-mtd@lists.infradead.org>,
> "chengzhihao1" <chengzhihao1@huawei.com>, "linux-kernel" <linux-kernel@vger.kernel.org>
> Gesendet: Dienstag, 3. Dezember 2024 15:17:06
> Betreff: Re: Block based OTA update needs mtdblock

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

What about using ubiupdatevol?

Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Pintu Agarwal <pintu.ping@gmail.com>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	 linux-mtd <linux-mtd@lists.infradead.org>,
	 chengzhihao1 <chengzhihao1@huawei.com>,
	 linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Block based OTA update needs mtdblock
Date: Tue, 3 Dec 2024 17:08:14 +0100 (CET)	[thread overview]
Message-ID: <342000380.28770675.1733242094522.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <87ldww4zrx.fsf@bootlin.com>

----- Ursprüngliche Mail -----
> Von: "Miquel Raynal" <miquel.raynal@bootlin.com>
> An: "Pintu Agarwal" <pintu.ping@gmail.com>
> CC: "richard" <richard@nod.at>, "Vignesh Raghavendra" <vigneshr@ti.com>, "linux-mtd" <linux-mtd@lists.infradead.org>,
> "chengzhihao1" <chengzhihao1@huawei.com>, "linux-kernel" <linux-kernel@vger.kernel.org>
> Gesendet: Dienstag, 3. Dezember 2024 15:17:06
> Betreff: Re: Block based OTA update needs mtdblock

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

What about using ubiupdatevol?

Thanks,
//richard

  reply	other threads:[~2024-12-03 16:08 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
2024-12-03 14:17     ` Miquel Raynal
2024-12-03 16:08     ` Richard Weinberger [this message]
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=342000380.28770675.1733242094522.JavaMail.zimbra@nod.at \
    --to=richard@nod.at \
    --cc=chengzhihao1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=pintu.ping@gmail.com \
    --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.