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

[Mattijs Korpershoek <mkorpershoek@kernel.org>]

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