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

[Mattijs Korpershoek <mkorpershoek@kernel.org>]

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