Problems flashing Xenomai 4

[morti]

Dear NVIDIA Support,

I am triying to use Xenomai 4 (EVL core) on my Jetson Orin Nx platform, as sourced from https://v4.xenomai.org/. My Orin Nx runs JetPack 6, flashed by SDK Manager.

I have followed various guides, such as those outlined in the documents https://theses.hal.science/tel-04277048v1/file/MOHAMEDABDULLA.pdf and https://cdck-file-uploads-global.s3.dualstack.us-west-2.amazonaws.com/nvidia/original/3X/e/d/ed9623eae58c967f59431dd36733a09cd39fb368.pdf. These resources detail the successful installation of Xenomai on a Jetson AGX Xavier board.

However, I encountered difficulties when attempting to flash the customized Linux image with Xenomai. My attempts can be summarized as follows:

1- Native Compilation on Orin Nx and flashing with extconfig: I endeavored to compile the Linux kernel, inclusive of Xenomai, directly on the Orin Nx following the steps outlined here (Building EVL :: Xenomai 4). Despite my efforts, I encountered challenges when attempting to flash the generated image. After compiling Xenomai (using appropriate flags for arm64, NVIDIA toolchain, and uapi) I experimented with various extconfig.conf configurations, like adding the Xenomai image, initrd and some dtbs in FDT. I was unable to successfully flash the Orin NX: when I power on the board, it loads the bootloader, and then the screen remains black.

2- Cross-Compilation and Flashing with Linux_For_Tegra Scripts: Subsequently, I attempted cross-compilation and flashing using the flash.sh script within the SDK Manager. Despite putting the board into recovery mode and executing the appropriate command with the DTB generated by my Xenomai kernel, I encountered the error: “Applet/MB2 is not running on device, Failed to get storage info.” Despite numerous attempts with variations in DTB, configuration, and storage, I was unable to achieve a successful outcome.

3- Cross-Compilation and Flashing with SDK Manager: Additionally, I tried flashing with SDK Manager by replacing the image, DTBs, and libraries (generated via make modules_install in Linux_for_Tegra/rootfs). Unfortunately, this approach was also unsuccessful.

I am seeking guidance on whether any of these methods should theoretically allow successful flashing. I would greatly appreciate any advice or insights you can provide to assist me in resolving this issue.

Furthermore, I am considering the possibility of achieving successful flashing by creating an image for the internal SD card using the jetson-disk-image-creator.sh script. Could you please provide information on the location of the libraries utilized by this command? I am considering replacing them with the Xenomai Libraries, Image, DTB… And generating the blob.img in this manner, could it work?

Thank you in advance for your attention to this matter and for any assistance you can offer.

[DaneLLL]

Hi,
Could you try Jetpack 5.1.2? We don’t have experience about this but you have mentioned it works on Xavier. Both Xavier and Orin are supported on Jetpack 5, so it may work on Orin/Jetpack 5.1.2. Please give it a try.

[morti]

Which of the previously followed options will work better?

Will I be able to compile and flash the Xenomai Linux kernel natively and include it in the Linux_tegra kernel sources directory, or must I use the Tegra Linux kernel sources? In this case, will I flash correctly by generating the Image, dtbs, and adding it to extlinux.conf?

If I compile it natively, can I flash my customized Image with SDK Manager, or will I need to use any special script? I ask this because I’ve read that flash.sh does not work in Orin Nx.

[linuxdev]

I don’t know about the Xenomai kernel. I can tell you though that for a kernel to work in a JetPack 5 (L4T R35.x) release, that you need the Jetson kernel source. Is Xenomai just a configuration, or is it also a source code edit?

You can easily compile kernels natively on Jetsons, but often they don’t have the disk space. Something like an external USB drive can be quite valuable for that. If you truly have a new kernel Image file, then I recommend copying that into the correct place, along with modules, but leaving the old content as a backup. There might also be an initrd edit needed depending on circumsetances. Then add a new boot option so you can pick either the original kernel or the new kernel (failure becomes non-fatal). I don’t know enough about your setup to be particularly useful to you for that, but adding extlinux.conf entries is normally trivial and quite useful (it is the initrd with custom boot configurations that can make it more difficult).