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

Heiko Schocher
2026-01-29T10:41:35Z

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