Re: [PATCH v2 0/8] imx8: switch missing boards to binman

[Marcel Ziswiler <marcel.ziswiler@toradex.com>]

Hi guys

On Fri, 2022-11-11 at 14:55 -0300, Fabio Estevam wrote:
> On Fri, Nov 11, 2022 at 2:40 PM Fabio Estevam <festevam@gmail.com> wrote:
> 
> > I removed SPL support, which does not seems to be needed as the scufw
> > handles DDR init.
> > 
> > I don't have access to an imx8qm/qxp board here.
> > 
> > Could you try removing SPL support from your board and see if it boots
> > with binman support?
> 
> Ok, let's SPL for now as this is a different topic for discussion.

Sorry, for jumping in (late) again. However, I still have some serious doubts about the whole topic and was
rather surprised that this series just all of a sudden got applied. I hope it is just me being confused so
please bear with me.

What exactly is binman vs. imx8image now doing (vs. what was it doing before)? Let us e.g. look at the i.MX
8QuadMax MEK board:

arch/arm/dts/fsl-imx8qm-mek.dts [1]:

That one just includes the following:

arch/arm/dts/imx8qm-u-boot.dtsi [2]:

[snip]

>	u-boot-spl-ddr {

That seems to be the SPL stuff. However, as mentioned before, it has nothing to do with the DDR initialisation
as that is done by the SCFW, not? Anyway, does using SPL even make sense then? I highly doubt it or does
anybody know any sensible reason for it?

[snip]

>		mkimage {

Here above u-boot-spl-ddr.bin gets run through imx8image with the configuration taken from here (if I am not
mistaken):

board/freescale/imx8qm_mek/imximage.cfg [3]:

> /* Boot from SD, sector size 0x400 */
> BOOT_FROM SD 0x400
> /* SoC type IMX8QM */
> SOC_TYPE IMX8QM
> /* Append seco container image */
> APPEND mx8qm-ahab-container.img
> /* Create the 2nd container */
> CONTAINER
> /* Add scfw image with exec attribute */
> IMAGE SCU mx8qm-mek-scfw-tcm.bin
> /* Add ATF image with exec attribute */
> IMAGE A35 spl/u-boot-spl.bin 0x00100000

So, if I am not mistaken this does already add SECO, SCFW and ATF, right?

BTW: There is also still a board/freescale/imx8qm_mek/uboot-container.cfg [4] which likely no longer serves any
purpose, not?

Anyway, let's continue with our discussion on [2]:

[snip]

>	itb {
>		filename = "u-boot.itb";

So we create a fit image.

[snip]

>				uboot {

Which contains U-Boot proper.

[snip]

>				atf {

And ATF.

[snip]

>				scfw {

And SCFW.

[snip]

>					scfw_blob {
>						filename = "mx8qm-val-scfw-tcm.bin";

BTW: Are we supposed to have a hard-coded file name for that val board here?

[snip]

>				seco {

And SECO.

[snip]

>					seco_blob {
>						filename = "mx8qm-ahab-container.img";

BTW: At least nowadays that one would likely officially rather be called mx8qmb0-ahab-container.img.

[snip]

>				@fdt-SEQ {

And, of course, the(m) device tree(s).

However, are we sure any of them ATF, SCFW and/or SECO in that fit image are even ever used? How exactly is
this supposed to work?

[snip]

>	imx-boot {

Then it creates flash.bin but only containing the SPL?

[snip]

[1] https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/fsl-imx8qm-mek.dts
[2] https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/imx8qm-u-boot.dtsi
[3] https://source.denx.de/u-boot/u-boot/-/blob/master/board/freescale/imx8qm_mek/imximage.cfg
[4] https://source.denx.de/u-boot/u-boot/-/blob/master/board/freescale/imx8qm_mek/uboot-container.cfg

Thanks for clarifying the whole situation.

Cheers

Marcel