Hi Tim,
On 27.05.21 17:41, Tim Harvey wrote:
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).
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
some way.
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
different SOCs.
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,
Stefano
Best regards,
Tim
--
=====================================================================
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: sba...@denx.de
=====================================================================
