Add support for CTI Photon Xavier NX

[pgils]

Support for Jetson Xavier NX module (P3668-0000) in a CTI Photon carrier board.
Based on #74 with patches from CTI bsp xavier-nx-32.4.2 v001

The machine conf overrides jetson-xavier-nx-devkit-emmc.conf. Is this okay or do we need a standalone config first like with the jetson-nano?

Also I was not sure about the order for these variables. Does that look alright?
This seems to work fine as well:

DTBNAME = "tegra194-p3668-all-p3509-0000"
DTBNAME_photon-xavier-nx = "tegra194-xavier-nx-cti-NGX003"
KERNEL_DEVICETREE = "${DEPLOY_DIR_IMAGE}/${DTBNAME}.dtb"

Would that work as a simpler solution or is there a reason not to set KERNEL_DEVICETREE like this?

This builds and runs fine. We have not been able to test the WWAN interface which should now be enabled as we do not have a module for it yet, but we will soon. I expect these driver changes to be released for photon-nano as well, we will update it when the 32.4.2 BSP it released by CTI.

[resin-jenkins]

Can one of the admins verify this patch?

[acostach]

thanks for the PR @pgils! yes, overriding the generic nx should be fine and dropping _xavier-nx from KERNEL_DEVICETREE to only override the dtb makes the recipe cleaner

[pgils]

great! can i add the KERNEL_DEVICETREE change here or would you prefer a separate PR @acostach ?

[acostach]

@pgils let's wait for my PR to be merged first as we are currently running tests on the new meta-balena before updating it in the PR. afterwards rebasing this PR on top of master and adding the change should be perfect

[pgils]

@acostach I rebased this onto master and had to make one small edit in the boot blob generation in the last commit. Is this good to go?

[acostach]

@acostach I rebased this onto master and had to make one small edit in the boot blob generation in the last commit. Is this good to go?

@pgils I'm afraid it's probably not going to work, it didn't work for me but you can give it a test if you wish.

Reason is the boot blob is very tricky with regards to signatures, that's why we need to use some patching to have it resemble the one created during flashing by tegra host tools, which bundles the dtb for cboot to use. See:

balena-jetson/layers/meta-balena-jetson/recipes-bsp/tegra-binaries/tegra194-nxde-flash-dry_32.4.2.bb

Line 336 in 35ec3d2

# For this release, /opt/tegra-binaries/boot0.img MD5 should be 7cc64922796a9afc325a5cdf64413d10

If one signature didn't match, mb2 did not want to validate the cboot dtb contents and boot failed.

It's good if you can confirm on your side, you can try to write the bundle you get generated in your custom build like here:

balena-jetson/layers/meta-balena-jetson/recipes-support/hostapp-update-hooks/files/99-resin-bootfiles-xavier-nx-devkit-emmc

Line 71 in 35ec3d2

flash_erase /dev/mtd0 0 0

and also try with the one that's generated without the last commit. Would be great to know how it works on your side.

Regarding the configs enabled, some are already enabled by meta-balena: https://github.com/balena-os/meta-balena/blob/master/meta-balena-common/classes/kernel-resin.bbclass#L377

[acostach]

@resin-jenkins test this please

[pgils]

@pgils I'm afraid it's probably not going to work, it didn't work for me but you can give it a test if you wish.

@acostach OK i can confirm it does not work.
A boot blob generated with CTI dtb (tegra194-xavier-nx-cti-NGX003_sigheader.dtb.encrypt):

# md5sum /opt/tegra-binaries/boot0.img
7cb78c91fe6ca78f704612df9bb36170  /opt/tegra-binaries/boot0.img

Writing this to /dev/mtdblock0 results in verification failure and failure to boot like you said.

Writing one generated with tegra194-p3668-all-p3509-0000_sigheader.dtb.encrypt:

# md5sum /opt/tegra-binaries/boot0.img
7cc64922796a9afc325a5cdf64413d10  /opt/tegra-binaries/boot0.img

Works fine.

What still confuses me is that the checksum for the partition seems random after each initial flashing (of the full balena image):

# dd if=/dev/mtdblock0 bs=1M status=none|md5sum
ac4c4225819a635bc68895e9d57bf7d4  -

# dd if=/dev/mtdblock0 bs=1M status=none|md5sum
323ec1fbe62c3de76e0df7e992c8f408  -

# dd if=/dev/mtdblock0 bs=1M status=none|md5sum
3fd72a451c127082a6d6d6ec25eb084f  -

Yet this boots and reboots fine.

tegra194-p3668-all-p3509-0000_sigheader.dtb.encrypt is not present in ${DEPLOY_DIR_IMAGE}/bootfiles when DTBNAME is anything other than tegra194-p3668-all-p3509-0000, breaking the build. I added a line in the last commit to explicitly copy the signed dtb to bootfiles. This now builds fine.

Regarding the configs enabled, some are already enabled by meta-balena: https://github.com/balena-os/meta-balena/blob/master/meta-balena-common/classes/kernel-resin.bbclass#L377

I removed the duplicates and separated them as well!

[acostach]

@resin-jenkins test this please
@balena-ci retest this please