[PATCH v1 0/2] fastboot: mmc: fix bootloader offset

[PATCH v1 0/2] fastboot: mmc: fix bootloader offset

[Heiko Schocher]

Not for all SoCs the bootloader start at offset 0x0,
in a hardware partition of an emmc. So we need the possibility to
set the correct offset, where bootloader starts.

Example:

imx8qxp revision C0 emmc Partition layout

| eMMC block / partition | Offset     | Size  | Purpose                        |
| ---------------------- | ---------- | ----- | ------------------------------ |
| /dev/mmcblk0boot0      | 0x0        | 2MB   | imx-boot-container A           |
|                        | 0x00220000 | 128kB | secure boot signature rootfs A |
| /dev/mmcblk0boot1      | 0x0        | 2MB   | imx-boot-container B           |
|                        | 0x00200000 | 8kB   | U-Boot env 0                   |
|                        | 0x00202000 | 8kB   | U-Boot env 1                   |
|                        | 0x00220000 | 128kB | secure boot signature rootfs B |

imx8qxp rev B0 emmc Partition layout

| eMMC block / partition | Offset     | Size  | Purpose                        |
| ---------------------- | ---------- | ----- | ------------------------------ |
| /dev/mmcblk0boot0      | 0x00008000 | 2MB   | imx-boot-container A           |
|                        | 0x00220000 | 128kB | secure boot signature rootfs A |
| /dev/mmcblk0boot1      | 0x0        | 8kB   | U-Boot env 0                   |
|                        | 0x00002000 | 8kB   | U-Boot env 1                   |
|                        | 0x00008000 | 2MB   | imx-boot-container B           |

If we flash now the bootloader image flash.bin on a B0 revision with

uuu FB: flash bootloader flash.bin

we overwrite the environment and board does not boot at all, as offset
is wrong.

To prevent any API change in the above command we propose
the following implementation from this series:

We add a new weak function fb_mmc_get_boot_offset() in drivers/fastboot/fb_block.c
which returns 0 and call this function instead of passing 0 for
the offset where offset is used/passed.

In SoC specific code (currently for IMX8QXP only) we implement this function
that it returns on B0 SoCs the 32k offset and on other SoC revisions the
offset 0.

This is tested on B0 and C0 based boards from siemens.

This patch should have no effect for other SoCs.


Adrian Freihofer (2):
  fastboot: mmc: make boot partition offset configurable
  arch: imx8qxp: Override weak fb_mmc_get_boot_offset function

 arch/arm/mach-imx/imx8/cpu.c | 21 +++++++++++++++++++++
 drivers/fastboot/fb_block.c  | 15 +++++++++++----
 2 files changed, 32 insertions(+), 4 deletions(-)

Azure build (series is in a bunch of siemens patches sending
now to mainline):
https://dev.azure.com/hs0298/hs/_build/results?buildId=202&view=results


-- 
2.20.1

base-commit: 547e4ff610d72169a2a8c72ffe9741046abd1b2e

[PATCH v1 1/2] fastboot: mmc: make boot partition offset configurable

[Heiko Schocher]

From: Adrian Freihofer <adrian.freihofer@siemens.com>

Add a weak function fb_mmc_get_boot_offset() to allow to override
the default offset (0) when writing to eMMC boot partitions.
This enables support for devices with non-standard boot partition
layouts, such as those requiring an offset for correct bootloader
placement.

The imx8qxp processors are an example where older revisions need a
32kB offset.

Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Heiko Schocher <hs@nabladev.com>
---

 drivers/fastboot/fb_block.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/fastboot/fb_block.c b/drivers/fastboot/fb_block.c
index 2a7e47992f8..51d1abb18c7 100644
--- a/drivers/fastboot/fb_block.c
+++ b/drivers/fastboot/fb_block.c
@@ -28,6 +28,11 @@
  */
 #define FASTBOOT_MAX_BLOCKS_WRITE 65536
 
+__weak lbaint_t fb_mmc_get_boot_offset(void)
+{
+	return 0;
+}
+
 struct fb_block_sparse {
 	struct blk_desc	*dev_desc;
 };
@@ -160,7 +165,8 @@ void fastboot_block_raw_erase_disk(struct blk_desc *dev_desc, const char *disk_n
 
 	debug("Start Erasing %s...\n", disk_name);
 
-	written = fb_block_write(dev_desc, 0, dev_desc->lba, NULL);
+	written = fb_block_write(dev_desc, fb_mmc_get_boot_offset(),
+				 dev_desc->lba, NULL);
 	if (written != dev_desc->lba) {
 		pr_err("Failed to erase %s\n", disk_name);
 		fastboot_response("FAIL", response, "Failed to erase %s", disk_name);
@@ -211,7 +217,8 @@ void fastboot_block_erase(const char *part_name, char *response)
 	if (fastboot_block_get_part_info(part_name, &dev_desc, &part_info, response) < 0)
 		return;
 
-	fastboot_block_raw_erase(dev_desc, &part_info, part_name, 0, response);
+	fastboot_block_raw_erase(dev_desc, &part_info, part_name,
+				 fb_mmc_get_boot_offset(), response);
 }
 
 void fastboot_block_write_raw_disk(struct blk_desc *dev_desc, const char *disk_name,
@@ -224,7 +231,7 @@ void fastboot_block_write_raw_disk(struct blk_desc *dev_desc, const char *disk_n
 	blkcnt = ((download_bytes + (dev_desc->blksz - 1)) & ~(dev_desc->blksz - 1));
 	blkcnt = lldiv(blkcnt, dev_desc->blksz);
 
-	if (blkcnt > dev_desc->lba) {
+	if ((blkcnt + fb_mmc_get_boot_offset()) > dev_desc->lba) {
 		pr_err("too large for disk: '%s'\n", disk_name);
 		fastboot_fail("too large for disk", response);
 		return;
@@ -232,7 +239,7 @@ void fastboot_block_write_raw_disk(struct blk_desc *dev_desc, const char *disk_n
 
 	printf("Flashing Raw Image\n");
 
-	blks = fb_block_write(dev_desc, 0, blkcnt, buffer);
+	blks = fb_block_write(dev_desc, fb_mmc_get_boot_offset(), blkcnt, buffer);
 
 	if (blks != blkcnt) {
 		pr_err("failed writing to %s\n", disk_name);
-- 
2.20.1

Re: [PATCH v1 1/2] fastboot: mmc: make boot partition offset configurable

[Peng Fan]

Hi Heiko,

On Sat, Jan 24, 2026 at 06:47:10AM +0100, Heiko Schocher wrote:
>From: Adrian Freihofer <adrian.freihofer@siemens.com>
>
>Add a weak function fb_mmc_get_boot_offset() to allow to override
>the default offset (0) when writing to eMMC boot partitions.

>This enables support for devices with non-standard boot partition
>layouts, such as those requiring an offset for correct bootloader
>placement.
>
>The imx8qxp processors are an example where older revisions need a
>32kB offset.
>
>Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
>Signed-off-by: Heiko Schocher <hs@nabladev.com>

I am thinking to write as below:

i.MX8QXP rev C.0 requires boot container stored at offset 0KB for eMMC,
while i.MX8QXP pre C.0 requires boot container stored at offset 32KB for eMMC.

To use one U-Boot binary to support different chip revisions, introduce
fb_mmc_get_boot_offset() to allow override the default offset when writting
to eMMC boot partitions.

This enables support for devices with non-standard boot partition
layouts, such as those requiring an offset for correct bootloader
placement.

Regards
Peng

Re: [PATCH v1 1/2] fastboot: mmc: make boot partition offset configurable

[Mattijs Korpershoek]

Hi Heiko,

Thank you for the patch.

On Sat, Jan 24, 2026 at 06:47, Heiko Schocher <hs@nabladev.com> wrote:

> From: Adrian Freihofer <adrian.freihofer@siemens.com>
>
> Add a weak function fb_mmc_get_boot_offset() to allow to override
> the default offset (0) when writing to eMMC boot partitions.
> This enables support for devices with non-standard boot partition
> layouts, such as those requiring an offset for correct bootloader
> placement.
>
> The imx8qxp processors are an example where older revisions need a
> 32kB offset.
>
> Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
> Signed-off-by: Heiko Schocher <hs@nabladev.com>

Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>

I'm fine with this commit message but I also like the one that Peng
suggested[1]

Up to you to decide if you want to respin to update.

[1] https://lore.kernel.org/all/aXbGZ22OTwTbbGEw@shlinux89/

> ---
>
>  drivers/fastboot/fb_block.c | 15 +++++++++++----
>  1 file changed, 11 insertions(+), 4 deletions(-)
>

[PATCH v1 2/2] arch: imx8qxp: Override weak fb_mmc_get_boot_offset function

[Heiko Schocher]

From: Adrian Freihofer <adrian.freihofer@siemens.com>

Add IMX8QXP SoCs specific implementation of fb_mmc_get_boot_offset()

This is needed as bootloader offset is different dependent on SoC
revision!

For revision B0 the bootloader starts at 32k offset. On offset
0x0 the bootloaders environment is stored.

On C0 revisions of the SoC bootloader image starts at offset 0x0

Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Heiko Schocher <hs@nabladev.com>
---

 arch/arm/mach-imx/imx8/cpu.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/mach-imx/imx8/cpu.c b/arch/arm/mach-imx/imx8/cpu.c
index 0e112af661c..27c431881b0 100644
--- a/arch/arm/mach-imx/imx8/cpu.c
+++ b/arch/arm/mach-imx/imx8/cpu.c
@@ -899,3 +899,24 @@ bool m4_parts_booted(void)
 
 	return false;
 }
+
+#ifdef CONFIG_IMX8QXP
+#include <blk.h>
+
+/*
+ * On B0 revision SoCs the bootloader is on 32k offset
+ * and at offset 0x0 is the U-Boot Environment stored
+ *
+ * So we cannot flash bootloader images to offset 0x0
+ *
+ * On C0 revisions of the SoC bootloader image starts
+ * at offset 0x0 ...
+ */
+lbaint_t fb_mmc_get_boot_offset(void)
+{
+	if ((get_cpu_rev() & 0xF) == CHIP_REV_C)
+		return 0;
+
+	return 0x40;
+}
+#endif
-- 
2.20.1

Re: [PATCH v1 2/2] arch: imx8qxp: Override weak fb_mmc_get_boot_offset function

[Peng Fan]

On Sat, Jan 24, 2026 at 06:47:11AM +0100, Heiko Schocher wrote:
>From: Adrian Freihofer <adrian.freihofer@siemens.com>
>
>Add IMX8QXP SoCs specific implementation of fb_mmc_get_boot_offset()
>
>This is needed as bootloader offset is different dependent on SoC
>revision!
>
>For revision B0 the bootloader starts at 32k offset. On offset
>0x0 the bootloaders environment is stored.
>
>On C0 revisions of the SoC bootloader image starts at offset 0x0
>
>Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
>Signed-off-by: Heiko Schocher <hs@nabladev.com>
>---
>
> arch/arm/mach-imx/imx8/cpu.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
>diff --git a/arch/arm/mach-imx/imx8/cpu.c b/arch/arm/mach-imx/imx8/cpu.c
>index 0e112af661c..27c431881b0 100644
>--- a/arch/arm/mach-imx/imx8/cpu.c
>+++ b/arch/arm/mach-imx/imx8/cpu.c
>@@ -899,3 +899,24 @@ bool m4_parts_booted(void)
> 
> 	return false;
> }
>+
>+#ifdef CONFIG_IMX8QXP
>+#include <blk.h>
>+
>+/*
>+ * On B0 revision SoCs the bootloader is on 32k offset
>+ * and at offset 0x0 is the U-Boot Environment stored
>+ *
>+ * So we cannot flash bootloader images to offset 0x0
>+ *
>+ * On C0 revisions of the SoC bootloader image starts
>+ * at offset 0x0 ...
>+ */
>+lbaint_t fb_mmc_get_boot_offset(void)
>+{
>+	if ((get_cpu_rev() & 0xF) == CHIP_REV_C)
>+		return 0;
>+
>+	return 0x40;

There maybe no new chip revisions saying CHIP_REV_D,
but in case.. So below would be better

lbaint_t fb_mmc_get_boot_offset(void)
{
	if ((get_cpu_rev() & 0xF) < CHIP_REV_C)
		return 0x40;

	return 0x0;
}

Regards
Peng
>+#endif
>-- 
>2.20.1
>

Re: [PATCH v1 2/2] arch: imx8qxp: Override weak fb_mmc_get_boot_offset function

[Mattijs Korpershoek]

Hi Heiko,

Thank you for the patch.

On Sat, Jan 24, 2026 at 06:47, Heiko Schocher <hs@nabladev.com> wrote:

> From: Adrian Freihofer <adrian.freihofer@siemens.com>
>
> Add IMX8QXP SoCs specific implementation of fb_mmc_get_boot_offset()
>
> This is needed as bootloader offset is different dependent on SoC
> revision!
>
> For revision B0 the bootloader starts at 32k offset. On offset
> 0x0 the bootloaders environment is stored.
>
> On C0 revisions of the SoC bootloader image starts at offset 0x0
>
> Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
> Signed-off-by: Heiko Schocher <hs@nabladev.com>

Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>

This looks good to me but please have a look at Peng's comment [1]

I can pick this up but I'll need an ACK from Stefano, Fabio or someone
from u-boot-imx@nxp.com

[1] https://lore.kernel.org/all/aXbHDnU+SpgnEt+Q@shlinux89/

> ---
>
>  arch/arm/mach-imx/imx8/cpu.c | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
>

Re: [PATCH v1 0/2] fastboot: mmc: fix bootloader offset

[Mattijs Korpershoek]

Hi Heiko,

Thank you for the patch.

On Sat, Jan 24, 2026 at 06:47, Heiko Schocher <hs@nabladev.com> wrote:

> Not for all SoCs the bootloader start at offset 0x0,
> in a hardware partition of an emmc. So we need the possibility to
> set the correct offset, where bootloader starts.
>
> Example:
>
> imx8qxp revision C0 emmc Partition layout
>
> | eMMC block / partition | Offset     | Size  | Purpose                        |
> | ---------------------- | ---------- | ----- | ------------------------------ |
> | /dev/mmcblk0boot0      | 0x0        | 2MB   | imx-boot-container A           |
> |                        | 0x00220000 | 128kB | secure boot signature rootfs A |
> | /dev/mmcblk0boot1      | 0x0        | 2MB   | imx-boot-container B           |
> |                        | 0x00200000 | 8kB   | U-Boot env 0                   |
> |                        | 0x00202000 | 8kB   | U-Boot env 1                   |
> |                        | 0x00220000 | 128kB | secure boot signature rootfs B |
>
> imx8qxp rev B0 emmc Partition layout
>
> | eMMC block / partition | Offset     | Size  | Purpose                        |
> | ---------------------- | ---------- | ----- | ------------------------------ |
> | /dev/mmcblk0boot0      | 0x00008000 | 2MB   | imx-boot-container A           |
> |                        | 0x00220000 | 128kB | secure boot signature rootfs A |
> | /dev/mmcblk0boot1      | 0x0        | 8kB   | U-Boot env 0                   |
> |                        | 0x00002000 | 8kB   | U-Boot env 1                   |
> |                        | 0x00008000 | 2MB   | imx-boot-container B           |
>

Why can't we use raw partition descriptors for this?

See:
https://docs.u-boot.org/en/latest/android/fastboot.html#raw-partition-descriptors

> If we flash now the bootloader image flash.bin on a B0 revision with
>
> uuu FB: flash bootloader flash.bin
>
> we overwrite the environment and board does not boot at all, as offset
> is wrong.
>
> To prevent any API change in the above command we propose
> the following implementation from this series:
>
> We add a new weak function fb_mmc_get_boot_offset() in drivers/fastboot/fb_block.c
> which returns 0 and call this function instead of passing 0 for
> the offset where offset is used/passed.
>
> In SoC specific code (currently for IMX8QXP only) we implement this function
> that it returns on B0 SoCs the 32k offset and on other SoC revisions the
> offset 0.
>
> This is tested on B0 and C0 based boards from siemens.
>
> This patch should have no effect for other SoCs.
>
>
> Adrian Freihofer (2):
>   fastboot: mmc: make boot partition offset configurable
>   arch: imx8qxp: Override weak fb_mmc_get_boot_offset function
>
>  arch/arm/mach-imx/imx8/cpu.c | 21 +++++++++++++++++++++
>  drivers/fastboot/fb_block.c  | 15 +++++++++++----
>  2 files changed, 32 insertions(+), 4 deletions(-)
>
> Azure build (series is in a bunch of siemens patches sending
> now to mainline):
> https://dev.azure.com/hs0298/hs/_build/results?buildId=202&view=results
>
>
> -- 
> 2.20.1
>
> base-commit: 547e4ff610d72169a2a8c72ffe9741046abd1b2e

Re: [PATCH v1 0/2] fastboot: mmc: fix bootloader offset

[Heiko Schocher]

Hello Mattijs,

On 26.01.26 10:48, Mattijs Korpershoek wrote:
> Hi Heiko,
> 
> Thank you for the patch.

You are welcome!

> 
> On Sat, Jan 24, 2026 at 06:47, Heiko Schocher <hs@nabladev.com> wrote:
> 
>> Not for all SoCs the bootloader start at offset 0x0,
>> in a hardware partition of an emmc. So we need the possibility to
>> set the correct offset, where bootloader starts.
>>
>> Example:
>>
>> imx8qxp revision C0 emmc Partition layout
>>
>> | eMMC block / partition | Offset     | Size  | Purpose                        |
>> | ---------------------- | ---------- | ----- | ------------------------------ |
>> | /dev/mmcblk0boot0      | 0x0        | 2MB   | imx-boot-container A           |
>> |                        | 0x00220000 | 128kB | secure boot signature rootfs A |
>> | /dev/mmcblk0boot1      | 0x0        | 2MB   | imx-boot-container B           |
>> |                        | 0x00200000 | 8kB   | U-Boot env 0                   |
>> |                        | 0x00202000 | 8kB   | U-Boot env 1                   |
>> |                        | 0x00220000 | 128kB | secure boot signature rootfs B |
>>
>> imx8qxp rev B0 emmc Partition layout
>>
>> | eMMC block / partition | Offset     | Size  | Purpose                        |
>> | ---------------------- | ---------- | ----- | ------------------------------ |
>> | /dev/mmcblk0boot0      | 0x00008000 | 2MB   | imx-boot-container A           |
>> |                        | 0x00220000 | 128kB | secure boot signature rootfs A |
>> | /dev/mmcblk0boot1      | 0x0        | 8kB   | U-Boot env 0                   |
>> |                        | 0x00002000 | 8kB   | U-Boot env 1                   |
>> |                        | 0x00008000 | 2MB   | imx-boot-container B           |
>>
> 
> Why can't we use raw partition descriptors for this?
> 
> See:
> https://docs.u-boot.org/en/latest/android/fastboot.html#raw-partition-descriptors

Thanks for this hint!

Possible yes ( I must try)... but this will lead in adding
complexity to scripts people use all over there and needs
to adapt CI setups, as siemens has B0 and C0 variants.

If we introduce this series, user has nothing to know about
offsets for different CPU modules as no change in API for
them...

bye,
Heiko
-- 
Nabla Software Engineering
HRB 40522 Augsburg
Phone: +49 821 45592596
E-Mail: office@nabladev.com
Geschäftsführer : Stefano Babic

Re: [PATCH v1 0/2] fastboot: mmc: fix bootloader offset

[Mattijs Korpershoek]

On Mon, Jan 26, 2026 at 16:46, Heiko Schocher <hs@nabladev.com> wrote:

> Hello Mattijs,
>
> On 26.01.26 10:48, Mattijs Korpershoek wrote:
>> Hi Heiko,
>> 
>> Thank you for the patch.
>
> You are welcome!
>
>> 
>> On Sat, Jan 24, 2026 at 06:47, Heiko Schocher <hs@nabladev.com> wrote:
>> 
>>> Not for all SoCs the bootloader start at offset 0x0,
>>> in a hardware partition of an emmc. So we need the possibility to
>>> set the correct offset, where bootloader starts.
>>>
>>> Example:
>>>
>>> imx8qxp revision C0 emmc Partition layout
>>>
>>> | eMMC block / partition | Offset     | Size  | Purpose                        |
>>> | ---------------------- | ---------- | ----- | ------------------------------ |
>>> | /dev/mmcblk0boot0      | 0x0        | 2MB   | imx-boot-container A           |
>>> |                        | 0x00220000 | 128kB | secure boot signature rootfs A |
>>> | /dev/mmcblk0boot1      | 0x0        | 2MB   | imx-boot-container B           |
>>> |                        | 0x00200000 | 8kB   | U-Boot env 0                   |
>>> |                        | 0x00202000 | 8kB   | U-Boot env 1                   |
>>> |                        | 0x00220000 | 128kB | secure boot signature rootfs B |
>>>
>>> imx8qxp rev B0 emmc Partition layout
>>>
>>> | eMMC block / partition | Offset     | Size  | Purpose                        |
>>> | ---------------------- | ---------- | ----- | ------------------------------ |
>>> | /dev/mmcblk0boot0      | 0x00008000 | 2MB   | imx-boot-container A           |
>>> |                        | 0x00220000 | 128kB | secure boot signature rootfs A |
>>> | /dev/mmcblk0boot1      | 0x0        | 8kB   | U-Boot env 0                   |
>>> |                        | 0x00002000 | 8kB   | U-Boot env 1                   |
>>> |                        | 0x00008000 | 2MB   | imx-boot-container B           |
>>>
>> 
>> Why can't we use raw partition descriptors for this?
>> 
>> See:
>> https://docs.u-boot.org/en/latest/android/fastboot.html#raw-partition-descriptors
>
> Thanks for this hint!
>
> Possible yes ( I must try)... but this will lead in adding
> complexity to scripts people use all over there and needs
> to adapt CI setups, as siemens has B0 and C0 variants.

If you try, please let me know.

Do the same boards (as in U-Boot board definition) have multiple SoC
variants (B0 and C0) ?

In that case I understand it's a pain to add more script complexity.

>
> If we introduce this series, user has nothing to know about
> offsets for different CPU modules as no change in API for
> them...

I understand, and I do like this approach as well. I just don't like
having 2 code paths/approaches for the "same thing".

I am not saying that this is a NAK, but i'd like to iterate a bit to see
if we can either deprecated raw partition descriptors (and migrate
existing boards) or use that everywhere.

I will try to use this series on VIM3 to see how it behaves. It will
take some time though.

Thanks
Mattijs

>
> bye,
> Heiko
> -- 
> Nabla Software Engineering
> HRB 40522 Augsburg
> Phone: +49 821 45592596
> E-Mail: office@nabladev.com
> Geschäftsführer : Stefano Babic

Re: [PATCH v1 0/2] fastboot: mmc: fix bootloader offset

[Heiko Schocher]

Hello Mattijs,

On 29.01.26 11:09, Mattijs Korpershoek wrote:
> On Mon, Jan 26, 2026 at 16:46, Heiko Schocher <hs@nabladev.com> wrote:
> 
>> Hello Mattijs,
>>
>> On 26.01.26 10:48, Mattijs Korpershoek wrote:
>>> Hi Heiko,
>>>
>>> Thank you for the patch.
>>
>> You are welcome!
>>
>>>
>>> On Sat, Jan 24, 2026 at 06:47, Heiko Schocher <hs@nabladev.com> wrote:
>>>
>>>> Not for all SoCs the bootloader start at offset 0x0,
>>>> in a hardware partition of an emmc. So we need the possibility to
>>>> set the correct offset, where bootloader starts.
>>>>
>>>> Example:
>>>>
>>>> imx8qxp revision C0 emmc Partition layout
>>>>
>>>> | eMMC block / partition | Offset     | Size  | Purpose                        |
>>>> | ---------------------- | ---------- | ----- | ------------------------------ |
>>>> | /dev/mmcblk0boot0      | 0x0        | 2MB   | imx-boot-container A           |
>>>> |                        | 0x00220000 | 128kB | secure boot signature rootfs A |
>>>> | /dev/mmcblk0boot1      | 0x0        | 2MB   | imx-boot-container B           |
>>>> |                        | 0x00200000 | 8kB   | U-Boot env 0                   |
>>>> |                        | 0x00202000 | 8kB   | U-Boot env 1                   |
>>>> |                        | 0x00220000 | 128kB | secure boot signature rootfs B |
>>>>
>>>> imx8qxp rev B0 emmc Partition layout
>>>>
>>>> | eMMC block / partition | Offset     | Size  | Purpose                        |
>>>> | ---------------------- | ---------- | ----- | ------------------------------ |
>>>> | /dev/mmcblk0boot0      | 0x00008000 | 2MB   | imx-boot-container A           |
>>>> |                        | 0x00220000 | 128kB | secure boot signature rootfs A |
>>>> | /dev/mmcblk0boot1      | 0x0        | 8kB   | U-Boot env 0                   |
>>>> |                        | 0x00002000 | 8kB   | U-Boot env 1                   |
>>>> |                        | 0x00008000 | 2MB   | imx-boot-container B           |
>>>>
>>>
>>> Why can't we use raw partition descriptors for this?
>>>
>>> See:
>>> https://docs.u-boot.org/en/latest/android/fastboot.html#raw-partition-descriptors
>>
>> Thanks for this hint!
>>
>> Possible yes ( I must try)... but this will lead in adding
>> complexity to scripts people use all over there and needs
>> to adapt CI setups, as siemens has B0 and C0 variants.
> 
> If you try, please let me know.

I am sorry, did not find time yet... sorry.

> Do the same boards (as in U-Boot board definition) have multiple SoC
> variants (B0 and C0) ?

Yes there is the capricorn board in U-Boot and it have different
variants (not all mainlined yet) with B0 and C0 variants...
number of boardvariants grown over the years, started even with A0 SoCs
(IIRC)...

> In that case I understand it's a pain to add more script complexity.

It is. and U-Boot could easily detect the SoC revision... and it is
fix ... so no need for having this configurable and making mistakes...

>> If we introduce this series, user has nothing to know about
>> offsets for different CPU modules as no change in API for
>> them...
> 
> I understand, and I do like this approach as well. I just don't like
> having 2 code paths/approaches for the "same thing".

Hmm... understandable...

> 
> I am not saying that this is a NAK, but i'd like to iterate a bit to see
> if we can either deprecated raw partition descriptors (and migrate
> existing boards) or use that everywhere.

No idea if this is possible for all boards?

May user want to write "some data" to an offset... which is not
SoC/board dependent...

"flash bootloader" is well defined -> flash the bootloader, so I argue
that this should simply burn the bootloader to the correct offset...

"raw" interface -> do what you think you need write to wherever you want...

> I will try to use this series on VIM3 to see how it behaves. It will
> take some time though.

VIM3 ? Is this a imx8qxp based hardware?

Thanks for your time!

bye,
Heiko
> 
> Thanks
> Mattijs
> 
>>
>> bye,
>> Heiko
>> -- 
>> Nabla Software Engineering
>> HRB 40522 Augsburg
>> Phone: +49 821 45592596
>> E-Mail: office@nabladev.com
>> Geschäftsführer : Stefano Babic

-- 
Nabla Software Engineering
HRB 40522 Augsburg
Phone: +49 821 45592596
E-Mail: office@nabladev.com
Geschäftsführer : Stefano Babic

Re: [PATCH v1 0/2] fastboot: mmc: fix bootloader offset

[Mattijs Korpershoek]

On Thu, Jan 29, 2026 at 11:41, Heiko Schocher <hs@nabladev.com> wrote:

> Hello Mattijs,
>
> On 29.01.26 11:09, Mattijs Korpershoek wrote:
>> On Mon, Jan 26, 2026 at 16:46, Heiko Schocher <hs@nabladev.com> wrote:
>> 
>>> Hello Mattijs,
>>>
>>> On 26.01.26 10:48, Mattijs Korpershoek wrote:
>>>> Hi Heiko,
>>>>
>>>> Thank you for the patch.
>>>
>>> You are welcome!
>>>
>>>>
>>>> On Sat, Jan 24, 2026 at 06:47, Heiko Schocher <hs@nabladev.com> wrote:
>>>>
>>>>> Not for all SoCs the bootloader start at offset 0x0,
>>>>> in a hardware partition of an emmc. So we need the possibility to
>>>>> set the correct offset, where bootloader starts.
>>>>>
>>>>> Example:
>>>>>
>>>>> imx8qxp revision C0 emmc Partition layout
>>>>>
>>>>> | eMMC block / partition | Offset     | Size  | Purpose                        |
>>>>> | ---------------------- | ---------- | ----- | ------------------------------ |
>>>>> | /dev/mmcblk0boot0      | 0x0        | 2MB   | imx-boot-container A           |
>>>>> |                        | 0x00220000 | 128kB | secure boot signature rootfs A |
>>>>> | /dev/mmcblk0boot1      | 0x0        | 2MB   | imx-boot-container B           |
>>>>> |                        | 0x00200000 | 8kB   | U-Boot env 0                   |
>>>>> |                        | 0x00202000 | 8kB   | U-Boot env 1                   |
>>>>> |                        | 0x00220000 | 128kB | secure boot signature rootfs B |
>>>>>
>>>>> imx8qxp rev B0 emmc Partition layout
>>>>>
>>>>> | eMMC block / partition | Offset     | Size  | Purpose                        |
>>>>> | ---------------------- | ---------- | ----- | ------------------------------ |
>>>>> | /dev/mmcblk0boot0      | 0x00008000 | 2MB   | imx-boot-container A           |
>>>>> |                        | 0x00220000 | 128kB | secure boot signature rootfs A |
>>>>> | /dev/mmcblk0boot1      | 0x0        | 8kB   | U-Boot env 0                   |
>>>>> |                        | 0x00002000 | 8kB   | U-Boot env 1                   |
>>>>> |                        | 0x00008000 | 2MB   | imx-boot-container B           |
>>>>>
>>>>
>>>> Why can't we use raw partition descriptors for this?
>>>>
>>>> See:
>>>> https://docs.u-boot.org/en/latest/android/fastboot.html#raw-partition-descriptors
>>>
>>> Thanks for this hint!
>>>
>>> Possible yes ( I must try)... but this will lead in adding
>>> complexity to scripts people use all over there and needs
>>> to adapt CI setups, as siemens has B0 and C0 variants.
>> 
>> If you try, please let me know.
>
> I am sorry, did not find time yet... sorry.
>
>> Do the same boards (as in U-Boot board definition) have multiple SoC
>> variants (B0 and C0) ?
>
> Yes there is the capricorn board in U-Boot and it have different
> variants (not all mainlined yet) with B0 and C0 variants...
> number of boardvariants grown over the years, started even with A0 SoCs
> (IIRC)...
>
>> In that case I understand it's a pain to add more script complexity.
>
> It is. and U-Boot could easily detect the SoC revision... and it is
> fix ... so no need for having this configurable and making mistakes...

I agree.

>
>>> If we introduce this series, user has nothing to know about
>>> offsets for different CPU modules as no change in API for
>>> them...
>> 
>> I understand, and I do like this approach as well. I just don't like
>> having 2 code paths/approaches for the "same thing".
>
> Hmm... understandable...
>
>> 
>> I am not saying that this is a NAK, but i'd like to iterate a bit to see
>> if we can either deprecated raw partition descriptors (and migrate
>> existing boards) or use that everywhere.
>
> No idea if this is possible for all boards?
>
> May user want to write "some data" to an offset... which is not
> SoC/board dependent...
>
> "flash bootloader" is well defined -> flash the bootloader, so I argue
> that this should simply burn the bootloader to the correct offset...
>
> "raw" interface -> do what you think you need write to wherever you want...
>
>> I will try to use this series on VIM3 to see how it behaves. It will
>> take some time though.
>
> VIM3 ? Is this a imx8qxp based hardware?

No VIM3 is a board made by Khadas that has an Amlogic SoC. But they use
the raw partition description for bootloader offset:

include/configs/khadas-vim3_android.h
52:     "fastboot_raw_partition_bootloader=0x1 0xfff mmcpart 1\0"     \
53:     "fastboot_raw_partition_bootenv=0x0 0xfff mmcpart 2\0"        \

So i'm wondering if this series can be useful to the VIM3 (so that we
could drop the fastboot_raw_partition_* from khadas-vim3_android.h)


>
> Thanks for your time!
>
> bye,
> Heiko
>> 
>> Thanks
>> Mattijs
>> 
>>>
>>> bye,
>>> Heiko
>>> -- 
>>> Nabla Software Engineering
>>> HRB 40522 Augsburg
>>> Phone: +49 821 45592596
>>> E-Mail: office@nabladev.com
>>> Geschäftsführer : Stefano Babic
>
> -- 
> Nabla Software Engineering
> HRB 40522 Augsburg
> Phone: +49 821 45592596
> E-Mail: office@nabladev.com
> Geschäftsführer : Stefano Babic

Re: [PATCH v1 0/2] fastboot: mmc: fix bootloader offset

[Mattijs Korpershoek]

Hey Heiko,

On Thu, Jan 29, 2026 at 15:09, Mattijs Korpershoek <mkorpershoek@kernel.org> wrote:

> On Thu, Jan 29, 2026 at 11:41, Heiko Schocher <hs@nabladev.com> wrote:
>
>> Hello Mattijs,
>>
>> On 29.01.26 11:09, Mattijs Korpershoek wrote:
>>> On Mon, Jan 26, 2026 at 16:46, Heiko Schocher <hs@nabladev.com> wrote:
>>> 
>>>> Hello Mattijs,
>>>>
>>>> On 26.01.26 10:48, Mattijs Korpershoek wrote:
>>>>> Hi Heiko,
>>>>>
>>>>> Thank you for the patch.
>>>>
>>>> You are welcome!
>>>>
>>>>>
>>>>> On Sat, Jan 24, 2026 at 06:47, Heiko Schocher <hs@nabladev.com> wrote:
>>>>>
>>>>>> Not for all SoCs the bootloader start at offset 0x0,
>>>>>> in a hardware partition of an emmc. So we need the possibility to
>>>>>> set the correct offset, where bootloader starts.
>>>>>>
>>>>>> Example:
>>>>>>
>>>>>> imx8qxp revision C0 emmc Partition layout
>>>>>>
>>>>>> | eMMC block / partition | Offset     | Size  | Purpose                        |
>>>>>> | ---------------------- | ---------- | ----- | ------------------------------ |
>>>>>> | /dev/mmcblk0boot0      | 0x0        | 2MB   | imx-boot-container A           |
>>>>>> |                        | 0x00220000 | 128kB | secure boot signature rootfs A |
>>>>>> | /dev/mmcblk0boot1      | 0x0        | 2MB   | imx-boot-container B           |
>>>>>> |                        | 0x00200000 | 8kB   | U-Boot env 0                   |
>>>>>> |                        | 0x00202000 | 8kB   | U-Boot env 1                   |
>>>>>> |                        | 0x00220000 | 128kB | secure boot signature rootfs B |
>>>>>>
>>>>>> imx8qxp rev B0 emmc Partition layout
>>>>>>
>>>>>> | eMMC block / partition | Offset     | Size  | Purpose                        |
>>>>>> | ---------------------- | ---------- | ----- | ------------------------------ |
>>>>>> | /dev/mmcblk0boot0      | 0x00008000 | 2MB   | imx-boot-container A           |
>>>>>> |                        | 0x00220000 | 128kB | secure boot signature rootfs A |
>>>>>> | /dev/mmcblk0boot1      | 0x0        | 8kB   | U-Boot env 0                   |
>>>>>> |                        | 0x00002000 | 8kB   | U-Boot env 1                   |
>>>>>> |                        | 0x00008000 | 2MB   | imx-boot-container B           |
>>>>>>
>>>>>
>>>>> Why can't we use raw partition descriptors for this?
>>>>>
>>>>> See:
>>>>> https://docs.u-boot.org/en/latest/android/fastboot.html#raw-partition-descriptors
>>>>
>>>> Thanks for this hint!
>>>>
>>>> Possible yes ( I must try)... but this will lead in adding
>>>> complexity to scripts people use all over there and needs
>>>> to adapt CI setups, as siemens has B0 and C0 variants.
>>> 
>>> If you try, please let me know.
>>
>> I am sorry, did not find time yet... sorry.
>>
>>> Do the same boards (as in U-Boot board definition) have multiple SoC
>>> variants (B0 and C0) ?
>>
>> Yes there is the capricorn board in U-Boot and it have different
>> variants (not all mainlined yet) with B0 and C0 variants...
>> number of boardvariants grown over the years, started even with A0 SoCs
>> (IIRC)...
>>
>>> In that case I understand it's a pain to add more script complexity.
>>
>> It is. and U-Boot could easily detect the SoC revision... and it is
>> fix ... so no need for having this configurable and making mistakes...
>
> I agree.
>
>>
>>>> If we introduce this series, user has nothing to know about
>>>> offsets for different CPU modules as no change in API for
>>>> them...
>>> 
>>> I understand, and I do like this approach as well. I just don't like
>>> having 2 code paths/approaches for the "same thing".
>>
>> Hmm... understandable...
>>
>>> 
>>> I am not saying that this is a NAK, but i'd like to iterate a bit to see
>>> if we can either deprecated raw partition descriptors (and migrate
>>> existing boards) or use that everywhere.
>>
>> No idea if this is possible for all boards?
>>
>> May user want to write "some data" to an offset... which is not
>> SoC/board dependent...
>>
>> "flash bootloader" is well defined -> flash the bootloader, so I argue
>> that this should simply burn the bootloader to the correct offset...
>>
>> "raw" interface -> do what you think you need write to wherever you want...
>>
>>> I will try to use this series on VIM3 to see how it behaves. It will
>>> take some time though.
>>
>> VIM3 ? Is this a imx8qxp based hardware?
>
> No VIM3 is a board made by Khadas that has an Amlogic SoC. But they use
> the raw partition description for bootloader offset:
>
> include/configs/khadas-vim3_android.h
> 52:     "fastboot_raw_partition_bootloader=0x1 0xfff mmcpart 1\0"     \
> 53:     "fastboot_raw_partition_bootenv=0x0 0xfff mmcpart 2\0"        \
>
> So i'm wondering if this series can be useful to the VIM3 (so that we
> could drop the fastboot_raw_partition_* from khadas-vim3_android.h)

With some hacking around, I could drop both above fastboot_raw_* from
the vim3 environment and use fb_mmc_get_boot_offset() instead.

The issue I have is that fb_mmc_get_boot_offset() will return the same
offset for both BOOT1 and BOOT2. I'd like to pass a struct blk_desc* to
fb_mmc_get_boot_offset() so that I can specify the offset based on
desc->hwpart.

Do you think that's reasonable?

I won't ask you to do this in this series. This will be work I'll do
after this is merged.

>
>
>>
>> Thanks for your time!
>>
>> bye,
>> Heiko
>>> 
>>> Thanks
>>> Mattijs
>>> 
>>>>
>>>> bye,
>>>> Heiko
>>>> -- 
>>>> Nabla Software Engineering
>>>> HRB 40522 Augsburg
>>>> Phone: +49 821 45592596
>>>> E-Mail: office@nabladev.com
>>>> Geschäftsführer : Stefano Babic
>>
>> -- 
>> Nabla Software Engineering
>> HRB 40522 Augsburg
>> Phone: +49 821 45592596
>> E-Mail: office@nabladev.com
>> Geschäftsführer : Stefano Babic

Re: [PATCH v1 0/2] fastboot: mmc: fix bootloader offset

[Heiko Schocher]

Hello Mattjis!

On 30.01.26 17:35, Mattijs Korpershoek wrote:
> Hey Heiko,
> 
> On Thu, Jan 29, 2026 at 15:09, Mattijs Korpershoek <mkorpershoek@kernel.org> wrote:
> 
>> On Thu, Jan 29, 2026 at 11:41, Heiko Schocher <hs@nabladev.com> wrote:
>>
>>> Hello Mattijs,
>>>
>>> On 29.01.26 11:09, Mattijs Korpershoek wrote:
>>>> On Mon, Jan 26, 2026 at 16:46, Heiko Schocher <hs@nabladev.com> wrote:
>>>>
>>>>> Hello Mattijs,
>>>>>
>>>>> On 26.01.26 10:48, Mattijs Korpershoek wrote:
>>>>>> Hi Heiko,
>>>>>>
>>>>>> Thank you for the patch.
>>>>>
>>>>> You are welcome!
>>>>>
>>>>>>
>>>>>> On Sat, Jan 24, 2026 at 06:47, Heiko Schocher <hs@nabladev.com> wrote:
>>>>>>
>>>>>>> Not for all SoCs the bootloader start at offset 0x0,
>>>>>>> in a hardware partition of an emmc. So we need the possibility to
>>>>>>> set the correct offset, where bootloader starts.
>>>>>>>
>>>>>>> Example:
>>>>>>>
>>>>>>> imx8qxp revision C0 emmc Partition layout
>>>>>>>
>>>>>>> | eMMC block / partition | Offset     | Size  | Purpose                        |
>>>>>>> | ---------------------- | ---------- | ----- | ------------------------------ |
>>>>>>> | /dev/mmcblk0boot0      | 0x0        | 2MB   | imx-boot-container A           |
>>>>>>> |                        | 0x00220000 | 128kB | secure boot signature rootfs A |
>>>>>>> | /dev/mmcblk0boot1      | 0x0        | 2MB   | imx-boot-container B           |
>>>>>>> |                        | 0x00200000 | 8kB   | U-Boot env 0                   |
>>>>>>> |                        | 0x00202000 | 8kB   | U-Boot env 1                   |
>>>>>>> |                        | 0x00220000 | 128kB | secure boot signature rootfs B |
>>>>>>>
>>>>>>> imx8qxp rev B0 emmc Partition layout
>>>>>>>
>>>>>>> | eMMC block / partition | Offset     | Size  | Purpose                        |
>>>>>>> | ---------------------- | ---------- | ----- | ------------------------------ |
>>>>>>> | /dev/mmcblk0boot0      | 0x00008000 | 2MB   | imx-boot-container A           |
>>>>>>> |                        | 0x00220000 | 128kB | secure boot signature rootfs A |
>>>>>>> | /dev/mmcblk0boot1      | 0x0        | 8kB   | U-Boot env 0                   |
>>>>>>> |                        | 0x00002000 | 8kB   | U-Boot env 1                   |
>>>>>>> |                        | 0x00008000 | 2MB   | imx-boot-container B           |
>>>>>>>
>>>>>>
>>>>>> Why can't we use raw partition descriptors for this?
>>>>>>
>>>>>> See:
>>>>>> https://docs.u-boot.org/en/latest/android/fastboot.html#raw-partition-descriptors
>>>>>
>>>>> Thanks for this hint!
>>>>>
>>>>> Possible yes ( I must try)... but this will lead in adding
>>>>> complexity to scripts people use all over there and needs
>>>>> to adapt CI setups, as siemens has B0 and C0 variants.
>>>>
>>>> If you try, please let me know.
>>>
>>> I am sorry, did not find time yet... sorry.
>>>
>>>> Do the same boards (as in U-Boot board definition) have multiple SoC
>>>> variants (B0 and C0) ?
>>>
>>> Yes there is the capricorn board in U-Boot and it have different
>>> variants (not all mainlined yet) with B0 and C0 variants...
>>> number of boardvariants grown over the years, started even with A0 SoCs
>>> (IIRC)...
>>>
>>>> In that case I understand it's a pain to add more script complexity.
>>>
>>> It is. and U-Boot could easily detect the SoC revision... and it is
>>> fix ... so no need for having this configurable and making mistakes...
>>
>> I agree.
>>
>>>
>>>>> If we introduce this series, user has nothing to know about
>>>>> offsets for different CPU modules as no change in API for
>>>>> them...
>>>>
>>>> I understand, and I do like this approach as well. I just don't like
>>>> having 2 code paths/approaches for the "same thing".
>>>
>>> Hmm... understandable...
>>>
>>>>
>>>> I am not saying that this is a NAK, but i'd like to iterate a bit to see
>>>> if we can either deprecated raw partition descriptors (and migrate
>>>> existing boards) or use that everywhere.
>>>
>>> No idea if this is possible for all boards?
>>>
>>> May user want to write "some data" to an offset... which is not
>>> SoC/board dependent...
>>>
>>> "flash bootloader" is well defined -> flash the bootloader, so I argue
>>> that this should simply burn the bootloader to the correct offset...
>>>
>>> "raw" interface -> do what you think you need write to wherever you want...
>>>
>>>> I will try to use this series on VIM3 to see how it behaves. It will
>>>> take some time though.
>>>
>>> VIM3 ? Is this a imx8qxp based hardware?
>>
>> No VIM3 is a board made by Khadas that has an Amlogic SoC. But they use
>> the raw partition description for bootloader offset:
>>
>> include/configs/khadas-vim3_android.h
>> 52:     "fastboot_raw_partition_bootloader=0x1 0xfff mmcpart 1\0"     \
>> 53:     "fastboot_raw_partition_bootenv=0x0 0xfff mmcpart 2\0"        \
>>
>> So i'm wondering if this series can be useful to the VIM3 (so that we
>> could drop the fastboot_raw_partition_* from khadas-vim3_android.h)
> 
> With some hacking around, I could drop both above fastboot_raw_* from
> the vim3 environment and use fb_mmc_get_boot_offset() instead.

Cool, thanks!

> 
> The issue I have is that fb_mmc_get_boot_offset() will return the same
> offset for both BOOT1 and BOOT2. I'd like to pass a struct blk_desc* to
> fb_mmc_get_boot_offset() so that I can specify the offset based on
> desc->hwpart.
> 
> Do you think that's reasonable?

Of course!

But I wonder, does this hardware boot from different offsets from
different hardwarepartitions? Sorry, if dummy question...

> I won't ask you to do this in this series. This will be work I'll do
> after this is merged.

Fine for me.

Thanks!

bye,
Heiko
> 
>>
>>
>>>
>>> Thanks for your time!
>>>
>>> bye,
>>> Heiko
>>>>
>>>> Thanks
>>>> Mattijs
>>>>
>>>>>
>>>>> bye,
>>>>> Heiko
>>>>> -- 
>>>>> Nabla Software Engineering
>>>>> HRB 40522 Augsburg
>>>>> Phone: +49 821 45592596
>>>>> E-Mail: office@nabladev.com
>>>>> Geschäftsführer : Stefano Babic
>>>
>>> -- 
>>> Nabla Software Engineering
>>> HRB 40522 Augsburg
>>> Phone: +49 821 45592596
>>> E-Mail: office@nabladev.com
>>> Geschäftsführer : Stefano Babic

-- 
Nabla Software Engineering
HRB 40522 Augsburg
Phone: +49 821 45592596
E-Mail: office@nabladev.com
Geschäftsführer : Stefano Babic

Re: [PATCH v1 0/2] fastboot: mmc: fix bootloader offset

[Mattijs Korpershoek]

On Mon, Feb 02, 2026 at 06:12, Heiko Schocher <hs@nabladev.com> wrote:

> Hello Mattjis!
>
> On 30.01.26 17:35, Mattijs Korpershoek wrote:
>> Hey Heiko,
>> 
>> On Thu, Jan 29, 2026 at 15:09, Mattijs Korpershoek <mkorpershoek@kernel.org> wrote:
>> 
>>> On Thu, Jan 29, 2026 at 11:41, Heiko Schocher <hs@nabladev.com> wrote:
>>>
>>>> Hello Mattijs,
>>>>
>>>> On 29.01.26 11:09, Mattijs Korpershoek wrote:
>>>>> On Mon, Jan 26, 2026 at 16:46, Heiko Schocher <hs@nabladev.com> wrote:
>>>>>
>>>>>> Hello Mattijs,
>>>>>>
>>>>>> On 26.01.26 10:48, Mattijs Korpershoek wrote:
>>>>>>> Hi Heiko,
>>>>>>>
>>>>>>> Thank you for the patch.
>>>>>>
>>>>>> You are welcome!
>>>>>>
>>>>>>>
>>>>>>> On Sat, Jan 24, 2026 at 06:47, Heiko Schocher <hs@nabladev.com> wrote:
>>>>>>>
>>>>>>>> Not for all SoCs the bootloader start at offset 0x0,
>>>>>>>> in a hardware partition of an emmc. So we need the possibility to
>>>>>>>> set the correct offset, where bootloader starts.
>>>>>>>>
>>>>>>>> Example:
>>>>>>>>
>>>>>>>> imx8qxp revision C0 emmc Partition layout
>>>>>>>>
>>>>>>>> | eMMC block / partition | Offset     | Size  | Purpose                        |
>>>>>>>> | ---------------------- | ---------- | ----- | ------------------------------ |
>>>>>>>> | /dev/mmcblk0boot0      | 0x0        | 2MB   | imx-boot-container A           |
>>>>>>>> |                        | 0x00220000 | 128kB | secure boot signature rootfs A |
>>>>>>>> | /dev/mmcblk0boot1      | 0x0        | 2MB   | imx-boot-container B           |
>>>>>>>> |                        | 0x00200000 | 8kB   | U-Boot env 0                   |
>>>>>>>> |                        | 0x00202000 | 8kB   | U-Boot env 1                   |
>>>>>>>> |                        | 0x00220000 | 128kB | secure boot signature rootfs B |
>>>>>>>>
>>>>>>>> imx8qxp rev B0 emmc Partition layout
>>>>>>>>
>>>>>>>> | eMMC block / partition | Offset     | Size  | Purpose                        |
>>>>>>>> | ---------------------- | ---------- | ----- | ------------------------------ |
>>>>>>>> | /dev/mmcblk0boot0      | 0x00008000 | 2MB   | imx-boot-container A           |
>>>>>>>> |                        | 0x00220000 | 128kB | secure boot signature rootfs A |
>>>>>>>> | /dev/mmcblk0boot1      | 0x0        | 8kB   | U-Boot env 0                   |
>>>>>>>> |                        | 0x00002000 | 8kB   | U-Boot env 1                   |
>>>>>>>> |                        | 0x00008000 | 2MB   | imx-boot-container B           |
>>>>>>>>
>>>>>>>
>>>>>>> Why can't we use raw partition descriptors for this?
>>>>>>>
>>>>>>> See:
>>>>>>> https://docs.u-boot.org/en/latest/android/fastboot.html#raw-partition-descriptors
>>>>>>
>>>>>> Thanks for this hint!
>>>>>>
>>>>>> Possible yes ( I must try)... but this will lead in adding
>>>>>> complexity to scripts people use all over there and needs
>>>>>> to adapt CI setups, as siemens has B0 and C0 variants.
>>>>>
>>>>> If you try, please let me know.
>>>>
>>>> I am sorry, did not find time yet... sorry.
>>>>
>>>>> Do the same boards (as in U-Boot board definition) have multiple SoC
>>>>> variants (B0 and C0) ?
>>>>
>>>> Yes there is the capricorn board in U-Boot and it have different
>>>> variants (not all mainlined yet) with B0 and C0 variants...
>>>> number of boardvariants grown over the years, started even with A0 SoCs
>>>> (IIRC)...
>>>>
>>>>> In that case I understand it's a pain to add more script complexity.
>>>>
>>>> It is. and U-Boot could easily detect the SoC revision... and it is
>>>> fix ... so no need for having this configurable and making mistakes...
>>>
>>> I agree.
>>>
>>>>
>>>>>> If we introduce this series, user has nothing to know about
>>>>>> offsets for different CPU modules as no change in API for
>>>>>> them...
>>>>>
>>>>> I understand, and I do like this approach as well. I just don't like
>>>>> having 2 code paths/approaches for the "same thing".
>>>>
>>>> Hmm... understandable...
>>>>
>>>>>
>>>>> I am not saying that this is a NAK, but i'd like to iterate a bit to see
>>>>> if we can either deprecated raw partition descriptors (and migrate
>>>>> existing boards) or use that everywhere.
>>>>
>>>> No idea if this is possible for all boards?
>>>>
>>>> May user want to write "some data" to an offset... which is not
>>>> SoC/board dependent...
>>>>
>>>> "flash bootloader" is well defined -> flash the bootloader, so I argue
>>>> that this should simply burn the bootloader to the correct offset...
>>>>
>>>> "raw" interface -> do what you think you need write to wherever you want...
>>>>
>>>>> I will try to use this series on VIM3 to see how it behaves. It will
>>>>> take some time though.
>>>>
>>>> VIM3 ? Is this a imx8qxp based hardware?
>>>
>>> No VIM3 is a board made by Khadas that has an Amlogic SoC. But they use
>>> the raw partition description for bootloader offset:
>>>
>>> include/configs/khadas-vim3_android.h
>>> 52:     "fastboot_raw_partition_bootloader=0x1 0xfff mmcpart 1\0"     \
>>> 53:     "fastboot_raw_partition_bootenv=0x0 0xfff mmcpart 2\0"        \
>>>
>>> So i'm wondering if this series can be useful to the VIM3 (so that we
>>> could drop the fastboot_raw_partition_* from khadas-vim3_android.h)
>> 
>> With some hacking around, I could drop both above fastboot_raw_* from
>> the vim3 environment and use fb_mmc_get_boot_offset() instead.
>
> Cool, thanks!
>
>> 
>> The issue I have is that fb_mmc_get_boot_offset() will return the same
>> offset for both BOOT1 and BOOT2. I'd like to pass a struct blk_desc* to
>> fb_mmc_get_boot_offset() so that I can specify the offset based on
>> desc->hwpart.
>> 
>> Do you think that's reasonable?
>
> Of course!

Great, thank you. I'll go ahead and do a more formal review of your
series and will build on top once this is merged.

>
> But I wonder, does this hardware boot from different offsets from
> different hardwarepartitions? Sorry, if dummy question...

It's not a dumb question.

Yes, the boot rom expects the bootloader to be at an offset.
To quote the docs:

"""
On GXL and newer boards it expects to find the FIP binary in sector 1, 512 bytes offset from the start.
"""

Also see:
https://docs.u-boot.org/en/latest/board/amlogic/boot-flow.html#boot-modes
https://github.com/LibreELEC/amlogic-boot-fip/pull/8

>
>> I won't ask you to do this in this series. This will be work I'll do
>> after this is merged.
>
> Fine for me.
>
> Thanks!
>
> bye,
> Heiko
>> 
>>>
>>>
>>>>
>>>> Thanks for your time!
>>>>
>>>> bye,
>>>> Heiko
>>>>>
>>>>> Thanks
>>>>> Mattijs
>>>>>
>>>>>>
>>>>>> bye,
>>>>>> Heiko
>>>>>> -- 
>>>>>> Nabla Software Engineering
>>>>>> HRB 40522 Augsburg
>>>>>> Phone: +49 821 45592596
>>>>>> E-Mail: office@nabladev.com
>>>>>> Geschäftsführer : Stefano Babic
>>>>
>>>> -- 
>>>> Nabla Software Engineering
>>>> HRB 40522 Augsburg
>>>> Phone: +49 821 45592596
>>>> E-Mail: office@nabladev.com
>>>> Geschäftsführer : Stefano Babic
>
> -- 
> Nabla Software Engineering
> HRB 40522 Augsburg
> Phone: +49 821 45592596
> E-Mail: office@nabladev.com
> Geschäftsführer : Stefano Babic