Support Connect-tech Rogue AGX Carrier board for Jetson Xavier

Product support balenaOS
1

I am trying to add support for the Connect-tech Rogue AGX carrier board for Jetson Xavier in Balena-Jetson.

We are building an image based on l4t R32.3.1 as per:

Board support packages available to us from Connect-tech include

  1. https://connecttech.com/ftp/Drivers/CTI-L4T-AGX-32.3.1-V007.tgz
  2. A linux kernel source directory modified by Connect-tech to support the Rogue

We have managed to get things working without Balena-OS - that is by just plopping the modified source directory into a downloaded Linux_for_tegra package and flashing this using the flash script.

Now we are trying to patch the changes required to support the Rogue into the balena-jetson yocto layers.

We also have image sensors to support but have the required patch files that already sorted out.

What i’ve managed so far is to just ad the connect-tech provided tegra194-agx-cti-AGX101.dtb to layers/meta-balena-jetson/recipes-kernel/linux/linux-tegra/ and edit the bbappend file. Doing this the board at least boots - but HDMI doesn’t work and I don’t think the second ethernet port works - this doesn’t surprise me.

I am not familiar with Yocto but am reading through documentation as well as forum posts here such as

My questions are:

  1. Has anyone supported the Rogue?
  2. Can I get assistance in setting this up in balena-jetson yocto layers
7

Hi, we haven’t supported or worked with the Rogue carrier board, actually with no other carrier for the Xavier AGX.

The Xaviers don’t use u-boot, they use c-boot so we can’t make use of custom dtb configuration, instead we can probably support it as a community device.

Could you provide your dtb file for your board in a github issue at https://github.com/balena-os/balena-jetson and we will look into creating a branch you can use to do a custom build for testing.

9

What carrier board DO you have a base image for that carries the Xavier AGX? Any at all?

11

Hi Jonathan,

No, we haven’t worked with any Xavier AGX carrier boards yet, only the Jetson DevKit.

Phil

13

OK thanks. I’ll post an issue on balena-jetson as mentioned above.
Cheers

15

Posted here https://github.com/balena-os/balena-jetson/issues/104

16

Great, thanks Jonathan!

18

I will create a PR shortly but questions in the meantime,

Trying to see if I understand your statement correctly about not supporting custom dtb configurations.

I have created a new machine configuration say foo.coffee.
Created corresponding layers/meta-balena-jetson/conf/machine/foo.conf which simply includes:

include conf/machine/jetson-xavier.conf

Added my custom .dtb in layers/meta-balena-jetson/recipes-kernel/linux/linux-tegra/ and edited the corresponding linux-tegra_%.bbappend file to add it to the SRC_URI and add a do_configure function to copy it to DEPLOY_DIR.

Finally edited layers/meta-balena-jetson/recipes-bsp/tegra-binaries/tegra194-flash-dry_32.3.1.bb to override KERNEL_DEVICETREE pointing to my custom .dtb.

(same as how the orbitty etc… machines are done).

Ultimately I get past all the stages but fail in do_compile or do_configure with

| [   0.1129 ] Header already present for mb1_t194_prod_sigheader.bin                            
| [   0.1135 ] adding BCH for spe_t194.bin                                                  
| [   0.1169 ] adding BCH for spe_t194.bin
| [   0.1198 ] adding BCH for nvtboot_t194.bin                                                                                                                  
| [   0.1228 ] adding BCH for nvtboot_t194.bin                                                                                
| [   0.1304 ] Header already present for preboot_c10_prod_cr.bin                                                             
| [   0.1328 ] Header already present for preboot_c10_prod_cr.bin            
| [   0.1333 ] Header already present for mce_c10_prod_cr.bin                    
| [   0.1335 ] Header already present for mce_c10_prod_cr.bin                                                                                                  
| [   0.1353 ] adding BCH for mts_c10_prod_cr.bin                                                                                  
| [   0.1396 ] adding BCH for mts_c10_prod_cr.bin                                       
| [   0.2276 ] adding BCH for cboot_t194.bin
| [   0.3109 ] adding BCH for cboot_t194.bin                                            
| [   0.3213 ] Stat for tegra194-p2888-0001-p2822-0000.dtb failed
| [   0.3317 ]                                                                                               
| Error: Return value 4                                                               
| Command tegrahost_v2 --chip 0x19 0 --partitionlayout flash.xml.in.bin --list images_list.xml zerosbk
| WARNING: exit code 1 from a shell command.                                     
| ERROR: Function failed: do_configure (log file is located at /home/jonathan/src/f-balena-jetson/build/tmp/work/aarch64-poky-linux/tegra194-flash-dry/32.3.1-r0/temp/log.do_configure.5497)
ERROR: Task (/home/jonathan/src/f-balena-jetson/build/../layers/meta-balena-jetson/recipes-bsp/tegra-binaries/tegra194-flash-dry_32.3.1.bb:do_configure) failed with exit code '1'
NOTE: Tasks Summary: Attempted 3811 tasks of which 3419 didn't need to be rerun and 1 failed.

Looking into layers/meta-balena-jetson/recipes-bsp/tegra-binaries/tegra194-flash-dry_32.3.1.bb I see the definition of do_configure has a bunch of hardcoded references to tegra194-p2888-0001-p2822-0000.dtb

The jetson-xavier machine seems to lack the ability for this support in contrast to the orbitty and others.

Just wondering if this all makes sense with the fact that custom dtb is not supported.

I’ll go forward with a PR in the meantime but this is definitely a wrench in the plans.

20

Hi Jonathan,

The dtb stayed hard-coded because for the moment only the devkit is supported by the recipe. Likely more changes are needed to support a different carrier board for the AGX, apart from the tegra194-flash-dry recipe.

Can you please indicate a branch where you pushed your changes, even if they don’t build correctly, so we can have a look and start from there?

22

Hi Alexandru,

I’m working with Jonathan on this.

Firstly, thanks for all of your help.

I fetched your r32.4.2 WIP Rogue branch from yesterday, and after making a few changes and adding a patch containing the kernel changes from CTI, I managed to build the kernel and rogue-specific device tree files.

With these changes, we no longer need to supply a precompiled DTB. Users can thus patch over the base Rogue patch if they want to add more hardware to the device (in our case, we add some cameras from another vendor, via another patch).

After building, I confirmed that the correct dtb data was deployed to the img file, so your fixes were very helpful in getting us over our roadblock. Thank you!

If you want to see the changes I made, they are here:

Please note that the patch file referenced by this change is not yet included, we’re still speaking to ConnectTech about releasing it.

With your improvements, the Jetson Xavier AGX has come up and appears on balena.io. We see the logo onscreen, and both Ethernet ports work, so it seems to have taken the DTB file correctly. We’re still investigating to see if all of the device’s hardware is working (this may take a while).

I’m going to go back to your 32.4.3 branch now and apply the same changes to my fork so we’re all on the same page and on a production-ready L4T version.

That being said, I would like to discuss jetson-flash. CTI’s approach for flashing the Rogue is to take the base Linux_for_Tegra directory and to modify it using scripts and materials in the following tarball:

https://connecttech.com/ftp/Drivers/CTI-L4T-AGX-32.4.3-V001.tgz
(The README file in the tarball explains how to ‘patch’ Linux_for_Tegra with its contents)

Among other things, it uses a custom conf file (see /conf/cti/xavier/rogue.conf in the tarball). This file specifies a rogue-specific pinmux file (see /bl/BCT/tegra19x-mb1-pinmux-agz-cti.cfg). I don’t know if this file is needed in your process, or if its fed in elsewhere. I figured it would be worth mentioning.

Any comments on this?

23

Hi @MarcBertola,

I’ve updated the 32.4.3 WIP PR and in the latest commit you can set your specific pinmux file to be used during signing, which is currently empty for the Rogue. I’m not sure where these configs end up but they probably become part of the boot blob - boot0.img.

Sure, if the kernel dts patch can be shared you can open a PR to include it as well as the custom pinmux as soon as this PR is merged.

To use a custom pinmux config during flashing you can either embed it your BSP archive and edit the path to it, or you can replace the pinmux file in resin-jetson-flash.js right before flash.sh is invoked.

24

Thanks for the reply.

Your work has allowed us to make excellent progress.

We’ll take a look at your latest commit to see what we need to do for the pinmux file.

Regarding the PR - I think it might make sense to merge back in two phases, the first one pertaining to the changes the remove the hardcoded dtb file:




However, I think you may want to wait on deploying the Rogue-specific machine changes. I’m concerned that without the kernel patches, they would combine the dev kit kernel with the Rogue DTB, which did not work well for us if I recall correctly. The Rogue kernel includes some additional drivers needed to support the hardware described in the DTB. It might create a false impression that the Rogue works with the p2822 kernel, which could lead to support headaches on your end.

It’s your call, ultimately. We’re very thankful for how quickly you turned all of this around.

27

Hi @MarcBertola,

Sure, even if we merge the changes to allow you to PR other specific configs or other kernel patches that suit your board, we won’t deploy it to the dashboard until you confirm it works as expected, because we don’t have this particular hardware.

28

I definitely got it appearing in balena.io using the original 32.4.2 branch+my changes. Both Ethernet ports and HDMI came up, which was not the case with the p2822 (dev kit) kernel and dtb. Jonathan was trying the 32.4.3 version yesterday. I believe he was successful.

We should try the pinmux next. After that we will try taking it a step farther by customizing the Rogue machine to include other hardware we have attached to it and try an end-to-end test. I’m working on the patches now.

29

Do you know which pinmux file I’m supposed to replace?
(I mean in the L4T archive - there are bunch - not sure which will be used)
UPDATE: Scratch this it appears to be tegra19x-mb1-pinmux-p2888-0000-a04-p2822-0000-b01.cfg as that was what jetson-flash output.

32

yes i am working on rouge for jetson agx xavier as a target for kernel image

33

Hi,
As I understand, this was part of the balena-jetson repository at some point, and has been removed since due to inactivity.
We’re interested in using balena with the rogue carrier and might be able to help maintain it, but might need some help getting started.

We have made the modifications described above (based on the current balena-jetson version; see here), and can build the image.
However, flashing fails, because some of the partitions specified in resin-jetson-flash.js seem to be missing (it looks like the image only contains resin-boot, resin-rootA, resin-rootB, resin-state, resin-data). Probably a beginner mistake-- what am I missing?

34

Quick update: the problem with the partitions has been fixed by adding the machine overrides to the conf file.

The system now shows up on the local network and we can connect in development mode.
We haven’t managed to make it show up on balena cloud. Would the device type matter for that? (we set it to jetson-xavier)