Hello Mattjis!
On 30.01.26 17:35, Mattijs Korpershoek wrote:
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.
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: [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
--
Nabla Software Engineering
HRB 40522 Augsburg
Phone: +49 821 45592596
E-Mail: [email protected]
Geschäftsführer : Stefano Babic
