Jetson TX2 Jetpack 4.2 with kernel driver modifications

system configuration:

  • NVidia Jetson TX2 with JetPack 4.2 (latest).
  • kernel driver changed as requirement for our applications.

On TX2 with jetpack 4.2 and kernel driver changes we are able to run and access functionalities from docker container. So we have a working environment that we want to port on Balena OS.
But when we try to flash the same board(jetpack 4.2) with balena os balena-cloud-core_csal-jetson-tx2-2.35.0+rev1-dev-v9.15.0.img we are stuck at Nvidia startup screen.

  1. Can we use Balena OS with latest Jetpack 4.2?
  2. What are the steps to apply kernel drivers changes with Balena OS?

Thanks,
Stojan

Hi @gancev,

Currently we don’t have an estimation of release for BalenaOS on L4T 32.1 (Jetpack 4.2). We are waiting for a new L4T release (L4T 32.2) with bootloader fixes that will allow resizing Nvidia bootloader partitions, but we don’t have a specific time frame.

The reason you see the startup screen when trying to boot from an sd-card with L4T 28.2 is that the old kernel is not compatible with the new dtbs and firmwares that are already flashed on the emmc with the JetPack 4.2, and vice-versa.

  1. Currently we don’t have an official release due to the L4T bug, but we have a work-in-progress preview branch. If you want to use it for testing and development, you can do a Yocto build in which you can also add your kernel patches too:

  2. The steps for creating the build are as follows:

     git clone git@github.com:balena-os/balena-jetson-nano.git
     cd balena-jetson-nano
     git checkout wip_warrior_tx2
     git submodule update --init --recursive
    

    Modify layers/meta-balena-jetson/recipes-kernel/linux/linux-tegra_%.bbappend
    to apply specific kernel patches that you need

    balena-jetson-nano$ balena-yocto-scripts/build/barys -b tx2build -m jetson-tx2 -d

The argument -d is used for a development build, which allows you to have both the screen and serial consoles.

If you already have JetPack 4.2 on the board you can write the generated resin-image-flasher-jetson-tx2-…rootfs.resinos-img to an SD card and boot the board with it. Also please don’t forget to place the config.json of your application in the boot partition so you can see the target in the dashboard.

Hi @acostach

We are not able to complete the image build process following the instructions above. The build is without our patch applied.
log.do_configure.3601.log (10.3 KB)
This is the error summary and full log is also attached:

  • | Failed to apply delta (-1)*

  • | WARNING: exit code 255 from a shell command.*

  • | ERROR: Function failed: do_configure (log file is located at /home/stojang/balena-jetson-nano/tx2build/tmp/work/aarch64-poky-linux/tegra186-flash-dry/32.1.0-r0/temp/log.do_configure.3601)*

  • ERROR : Task (/home/user/balena-jetson-nano/tx2build/…/layers/meta-balena-jetson/recipes-bsp/tegra-binaries/tegra186-flash-dry_32.1.0.bb:do_configure) failed with exit code ‘1’*

Summary: 1 task failed:

  • /home/user/balena-jetson-nano/tx2build/…/layers/meta-balena-jetson/recipes-bsp/tegra-binaries/tegra186-flash-dry_32.1.0.bb:do_configure*
    Summary: There were 7 WARNING messages shown.
    Summary: There was 1 ERROR me ssage shown, returning a non-zero exit code.

We are using the following build configuration:

Build Configuration:
BB_VERSION = “1.42.0”
BUILD_SYS = “x86_64-linux”
NATIVELSBSTRING = “universal”
TARGET_SYS = “aarch64-poky-linux”
MACHINE = “jetson-tx2”
DISTRO = “balena-os”
DISTRO_VERSION = “2.37.0”
TUNE_FEATURES = “aarch64 armv8a crc”
TARGET_FPU = “”
*meta *
meta-poky = “HEAD:f2b442c5c8e3925a4d3fc9693f1e47863dade2a9”
*meta-oe *
*meta-filesystems *
*meta-networking *
meta-python = “HEAD:6fa72d587aab8e9d56d67a2552eb9cfbe25c86d2”
meta-tegra = “HEAD:9156fddc34bcea43489457d39db3209fe16bfb59”
*meta-resin-common *
meta-balena-warrior = “HEAD:a9504d5a43249d0a9766618b3027b34b16565109”
meta-balena-jetson = “wip_warrior_tx2:3ad689f7e9e2dbb9ee68978a8e89780d0a944e54”
meta-rust = “HEAD:84710b341be53cc2af13ecc8ae87773cf84687bf”

Is there recommended build environment where we can successfully generate the image?

Thanks,
Stojan

Hi @gancev,

I couldn’t reproduce this behavior, I’m using 18.04.2 LTS to build the image.

The error you encounter is when using bspatch - brought in by layers/meta-balena-jetson/recipes-devtools/bsdiff - to patch the binary image boot0.img, which will be finally written on the board in /dev/mmcblk0boot0. Since there’s no documentation on how this binary file gets generated during board flashing with the l4t ubuntu tx2 image and host flashing tools, we need to re-construct it using ‘dd’ as you see in the tegra186-flash-dry.bb.

We then use ‘bspatch’ to apply a very small binary diff which will get the image to look exactly like the one existing in a tegra l4t ubuntu image for tx2. To create boot0.bindiff we used bsdiff in devshell of tegra186-flash-dry, and done the diff between what exists in a l4t image in /dev/mmcblk0boot0 and the newboot.img we generate with dd inside the recipe. There’s also a comment inside the recipe that explains why this is done.

Errors like this could also appear if the version of the bsdiff tools you are using is different from the one used to generate the patch. Please ensure the native bspatch from sysroot is being used:
$ MACHINE=jetson-tx2 bitbake tegra186-flash-dry -c devshell
$ which bspatch
.../tmp/work/aarch64-poky-linux/tegra186-flash-dry/32.1.0-r0/recipe-sysroot-native/usr/bin/bspatch
and it is the one brought by the bsdiff recipe from recipes-devtools.

Alternatively you can create your own binary patch using the method I explained above.

I’m seeing the same error as @gancev so I updated the github issue.

~/workspace/balena-jetson-nano/tx2build/tmp/work/aarch64-poky-linux/tegra186-flash-dry/32.1.0-r0/tegraflash$ ~/workspace/balena-jetson-nano/tx2build/tmp/work/aarch64-poky-linux/tegra186-flash-dry/32.1.0-r0/recipe-sysroot-native/usr/bin/bspatch newboot.img boot0.img ~/workspace/balena-jetson-nano/layers/meta-balena-jetson/recipes-bsp/tegra-binaries/files/boot0.bindiff
Failed to apply delta (-1)

I’m also using Ubuntu 18.04 LTS. I haven’t yet tried to create my own binary patch.

Thank you for reporting this, I’ve updated the branch to the latest BalenaOS and removed bspatch completely, so the error should not occur anymore.