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

Mattijs Korpershoek
2026-01-29T10:09:21Z

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