boot/qoriq-ddr-phy-binary: new package

The DDR PHY on the NXP LX2160A SoC needs firmware. This is distributed
as prebuilt binaries by NXP through GitHub.
This firmware is linked and used by the ATF.

Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: Vincent Jardin <vjardin@free.fr>
---
 DEVELOPERS                                    |  3 +++
 boot/Config.in                                |  1 +
 .../arm-trusted-firmware.mk                   |  8 +++++++
 boot/qoriq-ddr-phy-binary/Config.in           |  9 ++++++++
 .../qoriq-ddr-phy-binary.hash                 |  3 +++
 .../qoriq-ddr-phy-binary.mk                   | 21 +++++++++++++++++++
 6 files changed, 45 insertions(+)
 create mode 100644 boot/qoriq-ddr-phy-binary/Config.in
 create mode 100644 boot/qoriq-ddr-phy-binary/qoriq-ddr-phy-binary.hash
 create mode 100644 boot/qoriq-ddr-phy-binary/qoriq-ddr-phy-binary.mk

Hi Vladimir,

On Tue, Mar 18, 2025 at 05:32:28PM +0100, Vincent Jardin wrote:
> The DDR PHY on the NXP LX2160A SoC needs firmware. This is distributed
> as prebuilt binaries by NXP through GitHub.
> This firmware is linked and used by the ATF.
> 
> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
> Signed-off-by: Vincent Jardin <vjardin@free.fr>

Please, can you consider this move to boot/ ? It seems to be better
aligned with some other binary firmwares that are used to build the ATF
using Buildroot such as binaries-marvell/ for instance.

Best regards,
  Vincent

Hi Vincent,

On Tue, Mar 18, 2025 at 05:36:28PM +0100, Vincent Jardin wrote:
> On Tue, Mar 18, 2025 at 05:32:28PM +0100, Vincent Jardin wrote:
> > This firmware is linked and used by the ATF.
> 
> Please, can you consider this move to boot/ ? It seems to be better
> aligned with some other binary firmwares that are used to build the ATF
> using Buildroot such as binaries-marvell/ for instance.

I didn't study the binaries-marvell case, but I can explain the
situation here.

You say "the [DDR PHY] firmware is linked by the ATF" and required to
build it, but that isn't really the case.

The documentation at https://docs.nxp.com/bundle/UG10143/page/topics/tf-a_features.html
says:

  How to compile DDR FIP image (only applicable for LX2160ARDB and LX2162AQDS)

  A pre-built FIP image is already provided in the release.
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  To regenerate the DDR fip image for LX2160ARDB, and LX2162AQDS, perform
  the following steps [ proceeds to show how to use fiptool ]:

In other words, running the commands below results in the exact same
fip_ddr binary as the atf would produce.

[vladimir@pc /opt] $ git clone https://github.com/nxp-qoriq/ddr-phy-binary.git qoriq-ddr-phy-binary
Cloning into 'qoriq-ddr-phy-binary'...
remote: Enumerating objects: 110, done.
remote: Counting objects: 100% (43/43), done.
remote: Compressing objects: 100% (31/31), done.
remote: Total 110 (delta 25), reused 28 (delta 12), pack-reused 67 (from 1)
Receiving objects: 100% (110/110), 255.87 KiB | 602.00 KiB/s, done.
Resolving deltas: 100% (69/69), done.
[vladimir@pc /opt] $ cd qoriq-ddr-phy-binary
[vladimir@pc /opt/qoriq-ddr-phy-binary] $ /opt/qoriq-atf/tools/fiptool/fiptool info lx2160a/fip_ddr.bin
DDR UDIMM PHY IMEM 1d FW: offset=0x178, size=0x6BD0, cmdline="--ddr-immem-udimm-1d"
DDR UDIMM PHY IMEM 2d FW: offset=0x6D48, size=0x694C, cmdline="--ddr-immem-udimm-2d"
DDR UDIMM PHY DMEM 1d FW: offset=0xD694, size=0x6D0, cmdline="--ddr-dmmem-udimm-1d"
DDR UDIMM PHY DMEM 2d FW: offset=0xDD64, size=0x5BC, cmdline="--ddr-dmmem-udimm-2d"
DDR RDIMM PHY IMEM 1d FW: offset=0xE320, size=0x7050, cmdline="--ddr-immem-rdimm-1d"
DDR RDIMM PHY IMEM 2d FW: offset=0x15370, size=0x6D14, cmdline="--ddr-immem-rdimm-2d"
DDR RDIMM PHY DMEM 1d FW: offset=0x1C084, size=0x714, cmdline="--ddr-dmmem-rdimm-1d"
DDR RDIMM PHY DMEM 2d FW: offset=0x1C798, size=0x5FC, cmdline="--ddr-dmmem-rdimm-2d"
[vladimir@pc /opt/qoriq-ddr-phy-binary] $ /opt/qoriq-atf/tools/fiptool/fiptool create --ddr-immem-udimm-1d lx2160a/ddr4_pmu_train_imem.bin --ddr-immem-udimm-2d lx2160a/ddr4_2d_pmu_train_imem.bin --ddr-dmmem-udimm-1d lx2160a/ddr4_pmu_train_dmem.bin --ddr-dmmem-udimm-2d lx2160a/ddr4_2d_pmu_train_dmem.bin --ddr-immem-rdimm-1d lx2160a/ddr4_rdimm_pmu_train_imem.bin --ddr-immem-rdimm-2d lx2160a/ddr4_rdimm2d_pmu_train_imem.bin --ddr-dmmem-rdimm-1d lx2160a/ddr4_rdimm_pmu_train_dmem.bin --ddr-dmmem-rdimm-2d lx2160a/ddr4_rdimm2d_pmu_train_dmem.bin fip_ddr_new.bin
[vladimir@pc /opt/qoriq-ddr-phy-binary] $ diff fip_ddr_new.bin lx2160a/fip_ddr.bin
[vladimir@pc /opt/qoriq-ddr-phy-binary] $ echo $?
0

Even at runtime, the DDR PHY firmware is not compiled into the ATF firmware.
Rather, if you look at qoriq-atf commit 34d483565078 ("nxp: fip-handler
for additional ddr-fip.bin"), you will see that ddr_fip_setup() reads
the FIP image from offset 8M ("#define PLAT_DDR_FIP_OFFSET 0x800000") of
whatever boot storage device ATF was compiled for (QSPI_BOOT, NOR_BOOT etc).
In other words, the fact that board/solidrun/lx2160acex7/genimage.cfg in
my previous submission had "offset = 8M" here:

+       partition ddr-phy {
+               in-partition-table = "no"
+               image = "fip_ddr.bin"
+               offset = 8M
+       }

is not a coincidence, but ATF's expectation of where to find the FIP
image for the DDR PHY firmware at runtime. The two are in principle
decoupled at build time, and tied together by this convention.

But, my understanding is that one might want to re-generate another
Firmware Image Package (FIP) with DDR PHY firmware only in the case
where you have a trusted boot flow, and you want to authenticate the
firmware image by signing it with your own keys (more in
docs/plat/nxp/nxp-ls-tbbr.rst). That isn't something I was intending to
support, but is not something that your proposed patch supports either.
I would also imagine that using ATF's build system is not the only
possible way to sign the firmware images, but truth be told, I don't
really know, I never explored this, and for my personal use I don't
need it.

What is your intention? Do you just want me to move this package to
"boot" because of a misunderstanding, or do you want to support signing
of the DDR PHY firmware using ATF's build system?

Hi Vladimir,

On Wed, Mar 26, 2025 at 04:20:45PM +0100, Vladimir Oltean wrote:
> You say "the [DDR PHY] firmware is linked by the ATF" and required to
> build it, but that isn't really the case.
> 
> The documentation at https://docs.nxp.com/bundle/UG10143/page/topics/tf-a_features.html
> says:
> 
>   How to compile DDR FIP image (only applicable for LX2160ARDB and LX2162AQDS)
> 
>   A pre-built FIP image is already provided in the release.
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   To regenerate the DDR fip image for LX2160ARDB, and LX2162AQDS, perform
>   the following steps [ proceeds to show how to use fiptool ]:

Thanks for the pointers on this documentation and the below handson.

> In other words, running the commands below results in the exact same
> fip_ddr binary as the atf would produce.
> 
> [vladimir@pc /opt] $ git clone https://github.com/nxp-qoriq/ddr-phy-binary.git qoriq-ddr-phy-binary
> Cloning into 'qoriq-ddr-phy-binary'...
> remote: Enumerating objects: 110, done.
> remote: Counting objects: 100% (43/43), done.
> remote: Compressing objects: 100% (31/31), done.
> remote: Total 110 (delta 25), reused 28 (delta 12), pack-reused 67 (from 1)
> Receiving objects: 100% (110/110), 255.87 KiB | 602.00 KiB/s, done.
> Resolving deltas: 100% (69/69), done.
> [vladimir@pc /opt] $ cd qoriq-ddr-phy-binary
> [vladimir@pc /opt/qoriq-ddr-phy-binary] $ /opt/qoriq-atf/tools/fiptool/fiptool info lx2160a/fip_ddr.bin
> DDR UDIMM PHY IMEM 1d FW: offset=0x178, size=0x6BD0, cmdline="--ddr-immem-udimm-1d"
> DDR UDIMM PHY IMEM 2d FW: offset=0x6D48, size=0x694C, cmdline="--ddr-immem-udimm-2d"
> DDR UDIMM PHY DMEM 1d FW: offset=0xD694, size=0x6D0, cmdline="--ddr-dmmem-udimm-1d"
> DDR UDIMM PHY DMEM 2d FW: offset=0xDD64, size=0x5BC, cmdline="--ddr-dmmem-udimm-2d"
> DDR RDIMM PHY IMEM 1d FW: offset=0xE320, size=0x7050, cmdline="--ddr-immem-rdimm-1d"
> DDR RDIMM PHY IMEM 2d FW: offset=0x15370, size=0x6D14, cmdline="--ddr-immem-rdimm-2d"
> DDR RDIMM PHY DMEM 1d FW: offset=0x1C084, size=0x714, cmdline="--ddr-dmmem-rdimm-1d"
> DDR RDIMM PHY DMEM 2d FW: offset=0x1C798, size=0x5FC, cmdline="--ddr-dmmem-rdimm-2d"
> [vladimir@pc /opt/qoriq-ddr-phy-binary] $ /opt/qoriq-atf/tools/fiptool/fiptool create --ddr-immem-udimm-1d lx2160a/ddr4_pmu_train_imem.bin --ddr-immem-udimm-2d lx2160a/ddr4_2d_pmu_train_imem.bin --ddr-dmmem-udimm-1d lx2160a/ddr4_pmu_train_dmem.bin --ddr-dmmem-udimm-2d lx2160a/ddr4_2d_pmu_train_dmem.bin --ddr-immem-rdimm-1d lx2160a/ddr4_rdimm_pmu_train_imem.bin --ddr-immem-rdimm-2d lx2160a/ddr4_rdimm2d_pmu_train_imem.bin --ddr-dmmem-rdimm-1d lx2160a/ddr4_rdimm_pmu_train_dmem.bin --ddr-dmmem-rdimm-2d lx2160a/ddr4_rdimm2d_pmu_train_dmem.bin fip_ddr_new.bin
> [vladimir@pc /opt/qoriq-ddr-phy-binary] $ diff fip_ddr_new.bin lx2160a/fip_ddr.bin
> [vladimir@pc /opt/qoriq-ddr-phy-binary] $ echo $?
> 0

Yes, I had identified the same and I it is a good ack't that we can
rebuild it.

> Even at runtime, the DDR PHY firmware is not compiled into the ATF firmware.

Yes, I did notice it when reading the scripts.

> But, my understanding is that one might want to re-generate another
> Firmware Image Package (FIP) with DDR PHY firmware only in the case
> where you have a trusted boot flow, and you want to authenticate the
> firmware image by signing it with your own keys (more in
> docs/plat/nxp/nxp-ls-tbbr.rst). That isn't something I was intending to
> support, but is not something that your proposed patch supports either.

Right, it'll be my intend. I did notice this capability and I was
intending to check it once I'll dig with the complete chain of trust.

> What is your intention? Do you just want me to move this package to
> "boot" because of a misunderstanding, or do you want to support signing
> of the DDR PHY firmware using ATF's build system?

Sorry if I was unclear:
  - the signature will be a support I'll check and I'd like to
    mainstream with Buildroot.
  - it seems for me it was better to align it into the boot/ folder
    since this blob is rather loaded soon by the LX2160 ; so I was
    inspired by the Marvell case.

I do not pretend to have enough expertise with Buildroot, but it seems
for me that boot/ is a better home for such package. Maybe a Buildroot
maintainer can help us to be proper aligned with the intends of the
Buildroot's design ?

Vladimir: what would the rational be to have it into package/ ? Are
there some other cases of boot-stage firmwares that are into package/ ?
Maybe the package/freescale-imx with its FIRMWARE_IMX_PREPARE_DDR_FW
could be a case. What's about the signature of the IMX firmwares ?

Best regards,
  Vincent

On Thu, Mar 27, 2025 at 12:46:47AM +0100, Vincent Jardin wrote:
> Sorry if I was unclear:
>   - the signature will be a support I'll check and I'd like to
>     mainstream with Buildroot.
>   - it seems for me it was better to align it into the boot/ folder
>     since this blob is rather loaded soon by the LX2160 ; so I was
>     inspired by the Marvell case.
> 
> I do not pretend to have enough expertise with Buildroot, but it seems
> for me that boot/ is a better home for such package. Maybe a Buildroot
> maintainer can help us to be proper aligned with the intends of the
> Buildroot's design ?
> 
> Vladimir: what would the rational be to have it into package/ ? Are
> there some other cases of boot-stage firmwares that are into package/ ?
> Maybe the package/freescale-imx with its FIRMWARE_IMX_PREPARE_DDR_FW
> could be a case. What's about the signature of the IMX firmwares ?

I don't want to compare with package/freescale-imx. I think it's
sufficient to consider package/qoriq-rcw/ as something which is more
directly relevant here, because that is already used on Layerscape, and
ATF does have a build dependency on it. We do already have:

config BR2_TARGET_ARM_TRUSTED_FIRMWARE_RCW
	bool "Include NXP RCW in BL2"
	depends on BR2_PACKAGE_HOST_QORIQ_RCW
	help
	  Include the NXP RCW (Reset Control Word) in BL2. See
	  package/qoriq-rcw/ for more details. This is mostly useful
	  on NXP LayerScape platforms.

so a dependency from boot/ to package/ is not something entirely new
(though not required here, at least for now). Still, maybe it's best for
a Buildroot maintainer to share an expert opinion.