Multi-Soc binary support for i.MX8M Mini/Nano/Plus/? in single boot firmware binary

Multi-Soc binary support for i.MX8M Mini/Nano/Plus/? in single boot firmware binary

[Tim Harvey]

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

Re: Multi-Soc binary support for i.MX8M Mini/Nano/Plus/? in single boot firmware binary

[Simon Glass]

Hi Tim,

On Thu, 27 May 2021 at 09:41, Tim Harvey <tharvey@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

Re: Multi-Soc binary support for i.MX8M Mini/Nano/Plus/? in single boot firmware binary

[Stefano Babic]

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: sbabic@denx.de
=====================================================================

Re: Multi-Soc binary support for i.MX8M Mini/Nano/Plus/? in single boot firmware binary

[Peng Fan (OSS)]

On 2021/5/27 23: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).
> 
>  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?)

i.MX8MQ not have enough OCRAM for this case. SPL already use TCM here.

Regards,
Peng.

> 
> Best regards,
> 
> Tim

Re: Multi-Soc binary support for i.MX8M Mini/Nano/Plus/? in single boot firmware binary

[Tim Harvey]

On Wed, Jun 16, 2021 at 8:25 PM Peng Fan (OSS) <peng.fan@oss.nxp.com> wrote:
>
>
>
> On 2021/5/27 23: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).
> >
> >  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?)
>
> i.MX8MQ not have enough OCRAM for this case. SPL already use TCM here.
>

Peng,

Could you please explain what SoC you are referring to by 'i.MX8MQ'? I
don't see that on
https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-processors:IMX8-SERIES

Is this what NXP calls the 'i.MX 8M'?

Best regards,

Tim