[PATCH v1 0/2] fastboot: mmc: fix bootloader offset
Heiko Schocher
hs at nabladev.com
Mon Feb 2 06:12:34 CET 2026
Hello Mattjis!
On 30.01.26 17:35, Mattijs Korpershoek wrote:
> Hey Heiko,
>
> On Thu, Jan 29, 2026 at 15:09, Mattijs Korpershoek <mkorpershoek at kernel.org> wrote:
>
>> On Thu, Jan 29, 2026 at 11:41, Heiko Schocher <hs at 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 at 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 at 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 at nabladev.com
>>>>> Geschäftsführer : Stefano Babic
>>>
>>> --
>>> Nabla Software Engineering
>>> HRB 40522 Augsburg
>>> Phone: +49 821 45592596
>>> E-Mail: office at nabladev.com
>>> Geschäftsführer : Stefano Babic
--
Nabla Software Engineering
HRB 40522 Augsburg
Phone: +49 821 45592596
E-Mail: office at nabladev.com
Geschäftsführer : Stefano Babic
More information about the U-Boot
mailing list