Multi-Soc binary support for i.MX8M Mini/Nano/Plus/? in single boot firmware binary
sbabic at denx.de
Mon Jun 7 12:27:39 CEST 2021
On 27.05.21 17:41, Tim Harvey wrote:
> 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).
This could be a very nice feature that we had before with i.MX6.
> 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 b
Right - we have different DDR firmware, and this should be managed in
inary would have to use the minimum
> size ie 256K)
We had this also with i.MX6 - the multibinary approach should work with
the minimal OCRAM, as it was with MX6(Solo).
> - different ATF binaries
> - different ATF load address
> - different pinmux/padconf/inputsel registers
> - different clk config
Last twos can be solved via detection of CPus and loading different
setup and/or different DTs.
> 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.
Right - but the trick is to detect the right blob to be loaded. We get
offset / size in the fitImage for each blob, so we could just load the
relevant part in OCRAM. But I do not know how this matches with secure
boot, because HAB should verify the image before loading it.
> Does anyone agree this is doable or is there something they see that
> would be a show-stopper?
I think it is doable, not easy, and it will be a nice feature, and very
important for board vendors (as gateworks). I understand that most
custom projects (products) will chose just one variant, but there also
cases of real products that was delivered as "lite" and "pro", with
> I'm not all that familiar with the merits of binman fs FIT images... I
> think they were developed for different things.
I think so - I will tend to work with fitImage, and I think it suits for
these needs if the issues with the size of OCRAM are solved (like a
partial or selective load).
> 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?)
Someone from NXP should better explain this ;-)
> Best regards,
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
More information about the U-Boot