Hi Tim, On Thu, 27 May 2021 at 09:41, Tim Harvey <thar...@gateworks.com> 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). > > 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?
It is possible so long as you don't mind a larger image. > > 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. Either or both. Binman lets you access the location of things without any parsing overhead in SPL but once you get to U-Boot proper, you might be better off with FIT. In any case, binman can produce the final 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?) You might also consider whether you want to produce one image for each variant, but with the U-Boot binaries the same in all cases. So the same SPL binary could work on all boards, accessing things it needs via binman or FIT. Then at least you have a packaging problem, rather than a build problem. Another option is to have multiple SPLs and a single U-Boot. It is a shame that there are multiple TF-A binaries. The inability to take advantage of common features is one of the many things I dislike about binaries. We have this problem in spades on the Intel side. Regards, Simon
