CTI Hadron

[oscarthorn]

Hi!

Thanks, again for all the work you do with meta-tegra!

We are trying to use a custom carrier board for Orin NX from CTI called the Hadron: https://connecttech.com/product/hadron-carrier-for-nvidia-jetson-orin-nx/

I have received their BSP package that contain various files and now I'm trying to figure out which variables to set to make yocto build the right image.

I have created a machine conf based on the ones for Orin NX in this repo and a flashvars file based on p3509-a02-p3767-0000.

Bootloader

There are 3 device tree files (and one file that's included in the pinmux) related to the bootloader and two conf files that CTI use for setting the correct variables. For these I think it is enough to set the correct variables in the flashvars file.

CTI	YOCTO
PINMUX_CONFIG="tegra234-cti-orin-nx-mb1-bct-pinmux.dtsi";	PINMUX_CONFIG="tegra234-cti-orin-nx-mb1-bct-pinmux.dtsi";
MB2_BCT="tegra234-cti-orin-nx-mb2-bct-misc.dts"	Not sure if I should add MB2_BCT to flashvars or is MB2BCT_CFG the one to use?
SCR_CONFIG="tegra234-cti-orin-nx-mb2-bct-scr.dts"	SCR_CONFIG="tegra234-cti-orin-nx-mb2-bct-scr.dts"

Questions:

1. Does my approach make sense?
2. Should I use MB2BCT_CFG or MB2_BCT, what's the difference?

Kernel

There are also two device tree files related to the kernel as well a kernel image and some deb files.

DTB: tegra234-orin-nx-cti-NGX012.dtb
I'm figuring I should set KERNEL_DEVICETREE in the machine conf with this? CTI has it as DTB_FILE/TBCDTB_FILE. Is it fine to just have the dtb file or do I need to ask for the dts?

BTBO: tegra234-p3767-overlay.dtbo
Does this go in TEGRA_PLUGIN_MANAGER_OVERLAYS? Not sure about this one. CTI has it as OVERLAY_DTB_FILE.

There are also deb files and a kernel image:

• nvidia-l4t-display-kernel_5.10.104-tegra-35.3.1-CTI-ORIN-NX-NANO-V002-20230515_arm64
• nvidia-l4t-kernel-dtbs_5.10.104-tegra-35.3.1-CTI-ORIN-NX-NANO-V002-20230515_arm64.deb
• nvidia-l4t-kernel-headers_5.10.104-tegra-35.3.1-CTI-ORIN-NX-NANO-V002-20230515_arm64.deb
• nvidia-l4t-kernel_5.10.104-tegra-35.3.1-CTI-ORIN-NX-NANO-V002-20230515_arm64.deb

I'm not quite sure what to do with these? I suppose I need to ask for the source so I can make proper patches as needed? But I'm not quite sure which recipes to patch?

Thanks in advance for any answers you might have!

Ps. Would you like a PR with hadron board support once I get it working?

[dwalkes]

Hi @oscarthorn and welcome!

Does my approach make sense?
Seems like a good start AFAIK.

Should I use MB2BCT_CFG or MB2_BCT, what's the difference?

I only see a reference to MB2BCT_CFG in the existing flashvars file - where are you finding the MB2_BCT reference in CTI and how is it used? I'd compare that to how the corresponding MB2BCT_CFG is used in meta-tegra.

Is it fine to just have the dtb file or do I need to ask for the dts?

You should be able to convert between dts and dtb as needed using the dtc tool. I think you'd need the DTS if you wanted to modify.

I'm figuring I should set KERNEL_DEVICETREE in the machine conf with this?

I believe so.

tegra234-p3767-overlay.dtbo Does this go in TEGRA_PLUGIN_MANAGER_OVERLAYS? Not sure about this one. CTI has it as OVERLAY_DTB_FILE.

I believe TEGRA_PLUGIN_MANAGER_OVERLAYS is the right spot, but for questions like this I'd peruse commit history referencing the associated vars.

There are also deb files and a kernel image:
I'm not quite sure what to do with these? I suppose I need to ask for the source so I can make proper patches as needed? But I'm not quite sure which recipes to patch?

Yes you would most likely need/want source for the kernel if it isn't already in whatever they have in their BSP. It may be that they didn't modify the stock L4T kernel, that's probably the first thing I'd check. If they have made changes and they've added something you need in your kernel you'd need to apply those patches on the kernel used for OE4T, which you can find at https://github.com/oe4t/linux-tegra-5.10

Ps. Would you like a PR with hadron board support once I get it working?

I expect we'd want to capture this, yes, and thanks for the offer. It might be best in https://github.com/OE4T/meta-tegra-community, I'd let Matt weigh in on that when you get that far.

Good luck and keep us posted!

[oscarthorn]

Thanks for the response!

I only see a reference to MB2BCT_CFG in the existing flashvars file - where are you finding the MB2_BCT reference in CTI and how is it used? I'd compare that to how the corresponding MB2BCT_CFG is used in meta-tegra.

MB2_BCT is reference here:

meta-tegra/recipes-bsp/tegra-binaries/tegra-helper-scripts/rewrite-tegraflash-args.py

Line 16 in 5cb18c8

"mb1_bct=", "mb2_bct=", "mb2_cold_boot_bct=", "mb2bct_cfg=", "ecid=",

but I'm not sure what the use is. In the CTI BSP it is a variable set when flashing (using the nvidia flashing script).

I'll keep this thread updated with what I find!

[dwalkes]

MB2_BCT is reference here:

I see now. I'd probably look at the usage in the underlying tegraflash.py for insight about the difference.

[lfdmn]

Hi @oscarthorn

I have added support for CTI TX2 based carrier and did some trials with Xavier based ones too.

They do patch the kernel so you need to request the kernel sources from their support. It is not available as a direct download. They are often not fully up to date with the latest JetPack release.

At the time they had different sources for TX2 and Xavier. This might have changed and I don't yet have experience with orin.

Once you have the sources, fork the oe4t linux kernel repository https://github.com/OE4T/linux-tegra-4.9 or https://github.com/OE4T/linux-tegra-5.10, match the branch for the sources you got, create a new branch for the CTI patches and time for some merging fun: the sources folder layout is different than oe4t, and oe4t kernel have some patches applied that are not part of NVidia sources.

What I find easier to do is to download the sources from NVidia to diff with CTI, and only applied the ones that are necessary on top of oe4t patches.

Once you are done with the merge, commit your changes, create you own layer (i.e: meta-cti), declare your new machines (match KERNEL_DEVICETREE with the CTI entry point) and flash vars, bbappend linux-tegra_4.9 or linux-tegra_5.10 to overwrite SRCREV to point to your fork, and SRC_REPO to your commit id.

Watch out for the correct ODMDATA from CTI source, that was the thing I had forgotten to set in the beginning and couldn't boot properly.

That should be all. If you need any of the camera drivers they provide, then bitbake linux-tegra -c menuconfig to reconfigure you kernel and change the default config.

Good luck

[oscarthorn]

@lfdmn Thanks for the guidance! That helps a lot :)

[chamois94]

Hi, did you manage to have the board boot ? Is it possible to share your work ? I have the same thing to do, so will be very helpful.

[spb06]

Hey there, I am going through something very similar involving a custom carrier board (AGX Orin).

We followed the instructions in the "Create a Custom Machine". Specifically, we created a new machine config and flash config as advised in the wiki.

For the machine conf file, we copied over the jetson-agx-orin-devkit.conf and renamed it to match our machine name. The carrier board vendor provided their own .dtb file that we believe should replace the .dtb file specified in jetson-agx-orin-devkit.conf but we are not sure the best way to go about doing that.

Any guidance will be greatly appreciated!

[Islam-Hussein-11]

After Struggling yesterday. I made this Machine Config which allow me to successfully flash the device and I made also a recipe to import .dtb and .dtbo files for cti.

`#@type: Machine
#@name: Nvidia Jetson Orin NX 8GB (P3767-0001)
#@description: Nvidia Jetson Orin NX 8G module in Hadron Carrier

NVPMODEL ?= "nvpmodel_p3767_0001"

TEGRA_BUPGEN_SPECS ?= "fab=000;boardsku=0001;boardrev=;chipsku=00:00:00:D4;bup_type=bl
fab=000;boardsku=0001;boardrev=;bup_type=kernel"

TEGRA_BOARDSKU ?= "0001"
EMMC_BCT ?= "tegra234-p3767-0001-sdram-l4t.dts"

#TEGRA_FLASHVAR_WB0SDRAM_BCT = "tegra234-p3767-0001-wb0sdram-l4t.dts"
#TEGRA_FLASHVAR_BPFDTB_FILE = "tegra234-bpmp-3767-0000-a02-3509-a02.dtb"

TEGRA_FLASHVAR_PINMUX_CONFIG = "tegra234-cti-orin-nx-hadron-mb1-bct-pinmux.dtsi"
TEGRA_FLASHVAR_PMC_CONFIG = "tegra234-mb1-bct-padvoltage-p3767-hdmi-a03.dtsi"
TEGRA_FLASHVAR_SCR_CONFIG = "tegra234-cti-orin-nx-mb2-bct-scr.dts"
TEGRA_FLASHVAR_MB2BCT_CFG = "tegra234-cti-orin-nx-mb2-bct-misc.dts"
TEGRA_FLASHVAR_GPIOINT_CONFIG = "tegra234-cti-orin-nx-mb1-bct-gpioint.dts"

Specify the DTB and DTBO files

KERNEL_DEVICETREE = "tegra234-orin-nx-cti-NGX012.dtb"
KERNEL_DEVICETREE_OVERLAYS = "tegra234-orin-nx-cti-overlay.dtbo"

require conf/machine/p3768-0000-p3767-0001.conf
`

The Problem That I face now that I can't switch root after booting in init script and I get kernel Panic.

[ 6.987967] nvme0n1: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15 p16 [ 7.036940] EXT4-fs (nvme0n1p1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none. [ 7.043475] Kernel panic - not syncing: [ 7.043478] Attempted to kill init! exitcode=0x00000100 [ 7.043482] CPU: 3 PID: 1 Comm: switch_root Not tainted 5.15.136-l4t-r36.3-1009.9+g46cdb595bebc #1 [ 7.043486] Hardware name: NVIDIA CTI Hadron + Orin NX/Jetson, BIOS v36.3.0 02/09/2024 [ 7.043488] Call trace: [ 7.043489] dump_backtrace+0x0/0x1d0 [ 7.043500] show_stack+0x34/0x44 [ 7.043504] dump_stack_lvl+0x64/0x80 [ 7.043510] dump_stack+0x18/0x34 [ 7.043513] panic+0xd4/0x3a0 [ 7.043518] do_exit+0x9e4/0xa10 [ 7.043523] do_group_exit+0x44/0xa4 [ 7.043526] __wake_up_parent+0x0/0x50 [ 7.043529] invoke_syscall+0x5c/0x130 [ 7.043533] el0_svc_common.constprop.0+0x64/0x110 [ 7.043537] do_el0_svc+0x3c/0xa0 [ 7.043540] el0_svc+0x20/0x60 [ 7.043543] el0t_64_sync_handler+0x108/0x114 [ 7.043546] el0t_64_sync+0x1a4/0x1a8

If you have any Updates I'd appreciate the help. I contacted also yesterday cti and the did provide me source code their kernel (Or you can say the provided the changed files and we should do our own patch).

How should one proceed ?

[Islam-Hussein-11]

So I could successfully boot the Hadron Carrier using Yocto. But It will need much effoert to completly match the standards. I got before a kernel Panic. But after applying source from CTI within Kernel Source I could Boot successfully. We got too many failed processes because I didn't integrate Everything no oot or anything else just the Kernel to get it up and running. I also integrated it manually for the sake of testing because when I made the patch it was over 1 GB and yocto fired and error cuz it couldn't handle such a big patch. I need to discuss further with someone who maintains OE4T to add that Machine. It would be a great addition to the community. @oscarthorn @dwalkes