Hey Heiko, On Thu, Jan 29, 2026 at 15:09, Mattijs Korpershoek <[email protected]> wrote:
> On Thu, Jan 29, 2026 at 11:41, Heiko Schocher <[email protected]> wrote: > >> Hello Mattijs, >> >> On 29.01.26 11:09, Mattijs Korpershoek wrote: >>> On Mon, Jan 26, 2026 at 16:46, Heiko Schocher <[email protected]> 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 <[email protected]> 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. 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? I won't ask you to do this in this series. This will be work I'll do after this is merged. > > >> >> Thanks for your time! >> >> bye, >> Heiko >>> >>> Thanks >>> Mattijs >>> >>>> >>>> bye, >>>> Heiko >>>> -- >>>> Nabla Software Engineering >>>> HRB 40522 Augsburg >>>> Phone: +49 821 45592596 >>>> E-Mail: [email protected] >>>> Geschäftsführer : Stefano Babic >> >> -- >> Nabla Software Engineering >> HRB 40522 Augsburg >> Phone: +49 821 45592596 >> E-Mail: [email protected] >> Geschäftsführer : Stefano Babic
