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...
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?
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
