Hello,
I am wondering if there are any plans for meta-mender to officially support the Orin NX (specifically I’m targeting the p3509-a02-p3767-0000 machine).
Or, alternatively, I am considering modifying the Mender setup myself to apply it to the Orin NX. I believe the Orin Nano NVMe project contributed by another user could be a good starting point. However, simply changing the machine name in that setup did not result in a successful boot after flashing. (I’m sorry that I couldn’t get logs for it.)
Could you please advise on which areas I should consider modifying when adapting the Mender project to a different machine?
Thank you very much.
1 Like
I second this. It is currently a struggle to get a new Jetson platform started with Mender, considering the documentation on the meta-mender-tegra-jetpack5 layer is deprecated. This documentation references an old version of tegrademo-distro that does not exist for Jetpack 5. Updated documentation for this layer in addition to some basic guidance on this thread would be much appreciated for us developers trying to integrate with tegra-based platforms.
1 Like
@gyuhwan-park, I tested the method in the linked thread with my Orin NX and got a successful flash and boot! That being said, I am using an Orin NX in a custom carrier board with a configuration most similar to the p3768-0000-p3767-0000 machine.
Our setups are slightly different, but I am still hoping to help, if I can. Can you walk through what you did with your Orin NX? Did you apply the patch to tegra-bootfiles as well as change the configuration in local.conf?
Hi @gyuhwan-park and @graceagrace,
Yes indeed, the Tegra family has been quite problematic since Jetpack 5. The main reason is that basically everything about how the Tegra family is booted, flashed, and so on is highly NVidia specific. Hence, glue logic has to be created and maintained. In the case of Jetpack 5, this has lately been contributed to the mentioned meta-mender-tegra-jetpack5 (on kirkstone), respectively meta-mender-tegra (on scarthgap) layers.
I do continuous build testing and am aware of some failures, but haven’t found time to dig into those.
If you have observations which need changing or fixing @graceagrace, respectively a starting point to sort things out then I am always here to listen and make it happen.
Greetz,
Josef
1 Like
Hi @graceagrace, thank you for letting me know.
I also applied it to p3509-a02-p3767-0000, confirming that flash, boot, and a basic mender install <URL> work. To share my experience here, I started with tegra-demo-distro and set all layers to kirkstone using git checkout or git clone -b. The additional layers for Mender I included are as follows:
layers/poky/meta-poky \
layers/poky/meta-yocto-bsp \
layers/meta-mender/meta-mender-core \
layers/meta-mender-community/meta-mender-tegra/meta-mender-tegra-jetpack5
For .conf file, I added:
CONF_VERSION = "2"
PACKAGE_CLASSES = "package_ipk"
INIT_MANAGER = "systemd"
INHERIT += "rm_work"
MENDER_ARTIFACT_NAME = "gha_autobuild"
INHERIT += "tegra-mender-setup"
# MENDER_FEATURES_ENABLE:append = " mender-growfs-data"
MENDER_FEATURES_DISABLE:append = " mender-uboot"
IMAGE_FSTYPES:tegra = "tegraflash mender dataimg"
IMAGE_FSTYPES:pn-tegra-minimal-initramfs:tegra = "${INITRAMFS_FSTYPES}"
IMAGE_FSTYPES:pn-tegra-initrd-flash-initramfs:tegra = "${TEGRA_INITRD_FLASH_INITRAMFS_FSTYPES}"
MENDER_EFI_LOADER = ""
INHERIT += "mender-full"
EMMC_SIZE = "0"
MENDER_STORAGE_TOTAL_SIZE_MB = "16384"
MENDER_DATA_PART_SIZE_MB = "100"
MENDER_STORAGE_DEVICE_BASE="/dev/nvme0n1p"
MENDER_DATA_PART_NUMBER="15"
TEGRA_EXTERNAL_DEVICE_SECTORS = "250069680"
UBOOT_EXTLINUX = "1"
USE_REDUNDANT_FLASH_LAYOUT_DEFAULT = "1"
There may be unnecessary steps in the process above, but I hope this is helpful for others looking to use Mender with p3509-a02-p3767-0000.
Yay! Glad you were able to make it work! Steps for a machine based off of p3768-0000-p3767-0000 are nearly identical to yours - in my case, I also created a .bbappend for tegra-bootfiles with the following content:
do_install:append() {
if [ -f ${SH_CUSTOM_CONFIG_FRAGMENT} ]; then
cat ${SH_CUSTOM_CONFIG_FRAGMENT} >> ${D}${datadir}/tegraflash/tegra19x-mb1-pinmux-p3668-a01.cfg
fi
cp ${D}${datadir}/tegraflash/${PARTITION_LAYOUT_EXTERNAL} ${D}${datadir}/tegraflash/${PARTITION_LAYOUT_EXTERNAL}.bak
# 1. Remove the <partition name="reserved"> block (optional)
sed -i '/<partition name="reserved"/,/<\/partition>/d' ${D}${datadir}/tegraflash/${PARTITION_LAYOUT_EXTERNAL}
# 2. Extract the <partition name="UDA"> block and modify <allocation_attribute>
sed -n '/<partition name="UDA"/,/<\/partition>/p' ${D}${datadir}/tegraflash/${PARTITION_LAYOUT_EXTERNAL} > uda_block.xml
sed -i '/<partition name="UDA"/,/<\/partition>/d' ${D}${datadir}/tegraflash/${PARTITION_LAYOUT_EXTERNAL}
sed -i 's/<allocation_attribute> 8/<allocation_attribute> 0x808/' uda_block.xml
# 3. Remove the id attribute from the <partition name="A_kernel"> block
sed -i '/<partition name="A_kernel"/,/<\/partition>/s/id="[0-9]*"//g' ${D}${datadir}/tegraflash/${PARTITION_LAYOUT_EXTERNAL}
# 4. Extract the <partition name="APP"> block and modify <allocation_attribute>
sed -n '/<partition name="APP"/,/<\/partition>/p' ${D}${datadir}/tegraflash/${PARTITION_LAYOUT_EXTERNAL} > app_block.xml
sed -i '/<partition name="APP"/,/<\/partition>/d' ${D}${datadir}/tegraflash/${PARTITION_LAYOUT_EXTERNAL}
sed -i 's/0x808/0x8/' app_block.xml
# 5. Clone <partition name="APP"> block to create <partition name="APP_b"> and append it to app_block.xml
sed -e 's/name="APP"/name="APP_b"/g' \
-e 's/id="1"/id="2"/g' \
-e 's/APPUUID/APPUUID_b/g' \
-e 's/APPFILE/APPFILE_b/g' \
-e 's|id as it is physically put to the end of the device, so that it|id as it is defined after `primary_GPT` so that it|' \
-e 's/nvme0n1p1/nvme0n1p2/' \
app_block.xml > app_b_block.xml
cat app_b_block.xml >> app_block.xml
# 6. Reinsert the modified APP and APP_b blocks before the <partition name="A_kernel"> block
awk -i inplace -v INPLACE_SUFFIX=.bak '/<partition name="A_kernel"/{system("cat app_block.xml");}1' ${D}${datadir}/tegraflash/${PARTITION_LAYOUT_EXTERNAL}
# 7. Reinsert the modified <partition name="UDA"> block before the <partition name="secondary_gpt"> block
awk -i inplace -v INPLACE_SUFFIX=.bak '/<partition name="secondary_gpt"/{system("cat uda_block.xml");}1' ${D}${datadir}/tegraflash/${PARTITION_LAYOUT_EXTERNAL}
}
As was done in the linked post for standing up an Orin Nano with NVMe storage. I’ve been able to flash OTA without issues multiple times at this point. It’d be great if a kas configuration could be made for these two machines and merged back into meta-mender-tegra-jetpack5 for others’ benefit - I’ll attempt to spend some time on this in the near future.
Hi @graceagrace,
Yep, getting that into the kas files would be great and I’ll happily do that!
I’ve just given the local.conf of @gyuhwan-park a short inspection, and it seems to add these assignments
MENDER_EFI_LOADER = ""
MENDER_DATA_PART_SIZE_MB = "100"
MENDER_STORAGE_DEVICE_BASE="/dev/nvme0n1p"
MENDER_DATA_PART_NUMBER="15"
TEGRA_EXTERNAL_DEVICE_SECTORS = "250069680"
In the “normal” jetson-orin-nano.yml there seems to be nothing conflicting, but AFAIK that should be targeting the SD card, right?
Concerning the jetson-orin-nano-nvme.yml, it sounds to me like the section
TEGRAFLASH_NO_INTERNAL_STORAGE = "0"
PARTITION_LAYOUT_TEMPLATE_DEFAULT = "flash_t234_qspi.xml"
PARTITION_LAYOUT_EXTERNAL="flash_l4t_t234_nvme.xml"
# Mender tegra_mender_calc_total_size workaround
# Setting MENDER_STORAGE_TOTAL_SIZE_MB to 16Gb and no EMMC
MENDER_STORAGE_TOTAL_SIZE_MB = "16384"
is somewhat conflicting.
So is the existing values incorrect? Or are we talking about a completely different, third setup?
Once we’ve figured that out, we can proceed to upstreaming your .bbappend.
Thanks for sharing,
Josef
Hi @TheYoctoJester,
Thank you very much for helping with this! To answer your questions:
- Yes,
jetson-orin-nano.yml targets an Orin Nano with an SD card.
jetson-orin-nano-nvme.yml should not be changed. I believe this is the configuration @paroque28 figured out in the linked thread to this topic.
Instead, @gyuhwan-park has posted configuration data for the Orin NX SoM. It seems the configuration he posted works for both meta-tegra machines p3509-a02-p3767-0000 (Orin NX in a Xavier NX carrier board) and p3768-0000-p3767-0000 (Orin NX in an Orin Nano carrier board).
Please let me know if anything I’ve said is unclear, or if you need more information.
Hi @TheYoctoJester,
Thank you for checking my experience.
I targeted the p3509-a02-p3767-0000 and used the meta-tegra configuration file conf/machine/p3509-a02-p3767-0000.conf as it is. The file contains the following:
TNSPEC_BOOTDEV ?= "nvme0n1p1"
PARTITION_LAYOUT_TEMPLATE_DEFAULT ?= "flash_t234_qspi.xml"
PARTITION_LAYOUT_TEMPLATE_DEFAULT_SUPPORTS_REDUNDANT ?= "1"
PARTITION_LAYOUT_EXTERNAL_DEFAULT ?= "flash_l4t_t234_nvme.xml"
TEGRAFLASH_NO_INTERNAL_STORAGE = "1"
As I studied based on the work done by @paroque28, I realized that there’s nothing to modify in p3509-a02-p3767-0000.conf. Haha, sorry for the confusion. Anyway, all I did was adding the previously mentioned configuration lines to local.conf.
I’ve only tested the p3509-a02-p3767-0000 machine, but after checking the files, it seems like p3768-0000-p3767-0000 would also work fine, as @graceagrace mentioned.
After flashing the image, I verified that the rootfs A/B switching worked properly multiple times by running mender install <URL> & reboot repeatedly. However, I’m not sure if what I’ve done is the most perfect recipe. I’m a newbie to Yocto, and even more so to Mender, so I’d appreciate it if you could check it out.
Thank you
Hi @graceagrace and @gyuhwan-park,
So, first shot! Does this look sensible for merging? meta-mender-community/kas/jetson-orin-nx-devkit.yml at orin_nx_experimental · TheYoctoJester/meta-mender-community · GitHub
Can you eventually give it a spin and check the functionality? I’ve build tested it along with the plethora of version bumps in meta-mender-community on the kirkstone branch.
Greetz,
Josef