Multi-Soc binary support for i.MX8M Mini/Nano/Plus/? in single boot firmware binary
Tim Harvey
tharvey at gateworks.com
Thu May 27 17:41:25 CEST 2021
Greetings,
I support various iMX8M PCB's via board/gateworks/venice that are SOM based
and we are starting to add SOM's that have different IMX8M variant SoC's on
them which for various reasons are not binary compatible. I'm very
interested in coming up with a way to make them binary compatible to reduce
the number of disk images and boot firmware binaries our users work with
(along with the confusion of which one they need to use).
>From what I see in working thus far with the IMX8M Mini, Nano, and Plus
boot firmware differs in the following ways:
- different primary image offsets
- different dram config (phy training blob, phy cfg, cfg; which total about
3KiB for each config which varies based on dram type, soc variant, dram
topology and bit-mapping)
- different OCRAM sizes (compat binary would have to use the minimum size
ie 256K)
- different ATF binaries
- different ATF load address
- different pinmux/padconf/inputsel registers
- different clk config
The primary image offsets should be able to be dealt with by placing jumps
at the various offsets and I believe the rest could be dealt with via
runtime code if the SPL could load soc-specific blobs including dram
config, ATF, binary firmware blobs from a nice indexed image such as FIT or
binman. Currently imx8m SPL's use FIT images that are loaded entirely into
OCRAM which becomes an issue when you have enough dram configs that they no
longer fit in the OCRAM.
Does anyone agree this is doable or is there something they see that would
be a show-stopper?
I'm not all that familiar with the merits of binman fs FIT images... I
think they were developed for different things. I'm not sure if either/both
are suited for what I'm talking about regarding having the SPL raw load
binary blobs vs having them tacked onto a FIT image.
I'm not sure if the imx8mq has enough in common to be able to do this with
either, in fact I'm not even clear with SoC that is (is it what NXP calls
i.MX 8M?)
Best regards,
Tim
More information about the U-Boot
mailing list