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?
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.
@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?
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.
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:
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.
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
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.
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:
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.
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.
The flashing and booting processes were successful, and after checking the existence of the mender command and verifying the output of mender -h, the result seemed fine.
However, the image had some issues outside of the Mender layer, so I couldn’t verify mender install <HTTPserverURL> operations.
The issue where the dummy0 interface appears instead of eth0.
The fan is not functioning.
I’ll think about possible solutions myself, but if you have any ideas on how to resolve these issues, please let me know.
Thanks a lot for testing! The mentioned problems (eth0, fan) indeed don’t sound directly Mender related, but it still would be nice to fix. Were those already present when you did the initial work? Or did they just appear upon the orin_nx_experimental branch? In that case, it sounds like a regression in meta-tegra or one of the related layers as I did version bump them right before branching out.
PS: I plan to get an Orin NX for the testing here too, but still trying to understand the plethora of variants and carrier boards. My focus is obviously not the latest, greatest, or most fancy and specialized one, but most compatible respectively widespread one to maximize value for users. Pointers are appreciated!
In my previous tests, I based my setup on the tegra-demo-distro, and I added the necessary layers and configurations for Mender. During these tests, I did not encounter the issues (eth0
, fan). I suspect that the issue might be related to the version of one or more of the layers. Since the used layers are largely the same, I think it can be resolved.
(As a side note, I also encountered the issue of the fan not working on the basic poky kirkstone image of AGX Orin. If you know of a solution for this, I would greatly appreciate it if you could share it.)
I respect your decision on how to proceed because, based on my previous testing experience, I believe that all of these issues (eth0, fan) will be resolved soon and updated. (Regarding purchasing the Orin NX, I also chose a board that is commonly used, but I didn’t select it based on a deep understanding, so I’m not entirely sure.)
Thanks for testing with tegra-demo-distro. This is what I’d recommend. If you can reproduce on the tip of whatever branch you are using for mender integration I’d file an issue there. If not, I’d compare the revisions on tegra-demo-distro with the ones in used with mender integration along with similar configuration and build logs to attempt to troubleshoot.
Switching gears a bit re: procuring an Orin NX for testing, here is a brief primer on the Orin NX machine configurations available in meta-tegra:
p3509-a02-p3767-0000.conf: an Orin NX 16 GB module in a P3509 carrier board. This is the carrier board that comes with the Xavier NX developer kit from Nvidia, and the machine @gyuhwan-park is using.
p3767-0000-p3768-0000.conf: an Orin NX 16 GB module in a P3768 carrier board. This is the carrier board that comes with the Orin Nano developer kit from Nvidia.
p3767-0000-p3768-0000.conf: an Orin NX 8 GB module in a P3768 carrier board. This is the carrier board that comes with the Orin Nano developer kit from Nvidia.
meta-tegra provides other machine configurations for the Orin AGX (an industrial-targeted platform with 32 GB and 64 GB variants that many in the machine learning community are using, from what I’ve seen), as well as the Orin Nano (4 GB).
Based on my experience in the Jetson/Yocto Project developer communities, many of us are working with semi-bespoke hardware configurations (i.e. an off-the-shelf Jetson SoM with a custom, proprietary carrier board). The process for standing up a Jetson module with this setup is essentially to test with similar machine configurations to see if one boots, then create a custom BSP layer to fully support the hardware. For example, to support my Orin NX, I’ve started with the p3767-0000-p3768-0000 machine and built out a BSP layer with additional machine definitions and .bbappends to customize many of the boot files and configurations. This seems to be a fairly common workflow for users of meta-tegra. There are also well-known examples of commercially available carrier boards, such as those from SeeedStudio.
Considering that a significant portion of us are using unique carrier boards, it is difficult to easily suggest an Orin NX configuration for testing that would serve the majority of users. All modules I’ve mentioned above will be available for at least the next 5 years, per Nvidia’s product lifecycle, so that doesn’t narrow it down much, either. Maybe this is a good case for a poll among developers to see which meta-tegra machines are most commonly used, either off-the-shelf or as a starting point for custom development.
I tried to find your work around the jetson orin nx but the branch doesn’t exists anymore. I am trying to reproduce the build with an Orin NX and the seeedStudio A603 carrier.