### Start Installation with tegra-sysinstall Source: https://github.com/oe4t/meta-tegra/wiki/Over-the-air-reflashing-process This command initiates the system installation process. It reformats the eMMC and displays the new partition table, which should be verified against previous configurations. ```bash tegra-sysinstall ``` -------------------------------- ### Docker CI/CD Examples Source: https://github.com/oe4t/meta-tegra/wiki/OE4T-Meeting-Notes-2021-11-11 Examples of Dockerfiles and docker compose files used in CI/CD pipelines. These configurations are relevant for setting up automated builds and deployments. ```Dockerfile FROM ubuntu:latest RUN apt-get update && apt-get install -y \ build-essential \ git \ wget \ && rm -rf /var/lib/apt/lists/* # Add other dependencies and build steps here CMD ["echo", "Build complete"] ``` ```docker-compose.yml version: '3.8' services: builder: build: context: . dockerfile: Dockerfile volumes: - ./output:/app/output ``` -------------------------------- ### Kas Demos with SWUpdate Rootfs Overlay Source: https://github.com/oe4t/meta-tegra/wiki/OE4T-Meeting-Notes-2025‐04‐10 This points to the kas-demos repository, which includes examples of SWUpdate rootfs overlays. The next steps involve a tegraflash and SWUpdate sequence. ```shell https://github.com/Trellis-Logic/kas-demos ``` -------------------------------- ### Tegraflash Flashing Process Source: https://github.com/oe4t/meta-tegra/wiki/Flashing-the-Jetson-Dev-Kit This snippet shows the typical output during a successful Tegraflash operation, indicating the steps involved in flashing partitions on a Tegra device. ```bash sudo ./doflash.sh [ 1.7586 ] Flashing the device [ 1.7611 ] tegradevflash --pt flash.xml.bin --storageinfo storage_info.bin --create [ 1.7636 ] Cboot version 00.01.0000 [ 1.7659 ] Writing partition GPT with gpt.bin [ 1.7666 ] [................................................] 100% [ 1.7707 ] Writing partition PT with flash.xml.bin [ 15.9892 ] [................................................] 100% [ 15.9937 ] Writing partition NVC with nvtboot.bin.encrypt [ 16.2433 ] [................................................] 100% [ 16.2569 ] Writing partition NVC_R with nvtboot.bin.encrypt [ 26.2706 ] [................................................] 100% [ 26.2877 ] Writing partition VER_b with jetson-nano-qspi-sd_bootblob_ver.txt [ 36.3103 ] [................................................] 100% [ 36.3202 ] Writing partition VER with jetson-nano-qspi-sd_bootblob_ver.txt [ 36.5833 ] [................................................] 100% [ 36.5927 ] Writing partition APP with test-image.ext4.img [ 36.8548 ] [................................................] 100% ``` -------------------------------- ### Install udev rules for SD card writing and USB flashing Source: https://github.com/oe4t/meta-tegra/wiki/Flashing-the-Jetson-Dev-Kit This script helps set up udev rules to grant write access to Jetson devices via USB, allowing users to avoid using sudo for SD card writing and USB flashing operations. It is intended for Ubuntu systems. ```Shell wget https://raw.githubusercontent.com/OE4T/tegra-demo-distro/master/layers/meta-tegrademo/scripts/setup-udev-rules -O setup-udev-rules sudo bash setup-udev-rules ``` -------------------------------- ### Automate Unpack and Flash with oe4t-tegraflash-deploy Source: https://github.com/oe4t/meta-tegra/wiki/Flashing-the-Jetson-Dev-Kit This script automates the process of unpacking and executing the `./doflash.sh` script for Tegra flashing. It is useful for streamlining the deployment workflow. ```Shell https://github.com/OE4T/tegra-demo-distro/blob/master/layers/meta-tegrademo/scripts/oe4t-tegraflash-deploy ``` -------------------------------- ### Install Tegra Configuration Files (Yocto) Source: https://github.com/oe4t/meta-tegra/wiki/Creating-a-custom-MACHINE Appends the do_install task to install custom Tegra configuration files, such as padvoltage and pinmux settings, into the ${D}${datadir}/tegraflash/ directory. This is used when the fetch task is disabled. ```Yocto do_install:append:${machine}() { install -m 0644 ${CUSTOM_DTSI_DIR}/tegra19x-${machine}-padvoltage-default.cfg ${D}${datadir}/tegraflash/ install -m 0644 ${CUSTOM_DTSI_DIR}/tegra19x-${machine}-pinmux.cfg ${D}${datadir}/tegraflash/ } ``` -------------------------------- ### Manual Signing and Flashing (Shell) Source: https://github.com/oe4t/meta-tegra/wiki/Secure-Boot-Support This example demonstrates how to manually sign and flash boot files using the `doflash.sh` script. It requires specifying board-specific environment variables and providing paths to signing and encryption keys. ```Shell $ BOARDID= FAB= BOARDSKU= BOARDREV= ./doflash.sh -u /path/to/signing-key.pem -v /path/to-encryption-key ``` -------------------------------- ### Create SD Card Image with dosdcard.sh Source: https://github.com/oe4t/meta-tegra/wiki/Flashing-the-Jetson-Dev-Kit This command creates an SD card image file that can be later written to multiple cards. The resulting image file will be large, and the writing process can be time-consuming. ```Shell $ ./dosdcard.sh ``` -------------------------------- ### Organize TensorRT Packages for Xavier Source: https://github.com/oe4t/meta-tegra/wiki/L4T-R32.3.1-Notes This example demonstrates how to organize TensorRT debian packages for Xavier-based systems. It involves creating a 'DLA' directory and moving specific TensorRT and related library packages into it, as required by the 'tensorrt' recipe for distinguishing Xavier-specific packages. ```Shell cd ~/Downloads/nvidia/sdkm_downloads mkdir DLA mv tensorrt*.deb *libnvinfer*.deb libnv*parsers*.deb uff*.deb graphsurgeon*.deb DLA/ ``` -------------------------------- ### Unpack tegraflash Package Source: https://github.com/oe4t/meta-tegra/wiki/Flashing-the-Jetson-Dev-Kit This command unpacks the tegraflash package, which contains all necessary files and scripts for flashing a Jetson device or creating an SD card image. It is recommended to use a terminal for extraction to avoid potential issues with GUI tools. ```bash mkdir ~/tegraflash cd ~/tegraflash tar -x -f $BUILDDIR/tmp/deploy/images/${MACHINE}/-${MACHINE}.tegraflash.tar.gz ``` -------------------------------- ### Configure Polkit for Disk Group Access Source: https://github.com/oe4t/meta-tegra/wiki/initrd-flashing-support This script configures Polkit rules to allow members of the 'disk' group to mount filesystems and power off drives without requiring elevated privileges. This is part of the 'Avoiding sudo' setup for the initrd-flash script. ```shell cat << EOF > /var/lib/polkit-1/localauthority/50-local.d/com.github.oe4t.pkla [Allow Mounting for Disk Group] Identity=unix-group:disk Action=org.freedesktop.udisks2.filesystem-mount ResultAny=yes [Allow Power Off Drive for Disk Group] Identity=unix-group:disk Action=org.freedesktop.udisks2.power-off-drive ResultAny=yes EOF chmod 644 /var/lib/polkit-1/localauthority/50-local.d/com.github.oe4t.pkla systemctl restart polkit ``` -------------------------------- ### Install BUP Payload with nv_update_engine Source: https://github.com/oe4t/meta-tegra/wiki/Over-the-air-reflashing-process These commands use the nv_update_engine utility to enable A/B updates and install the BUP payload without rebooting. A successful installation is typically followed by a manual reboot. ```bash nv_update_engine --enable-ab nv_update_engine --install no-reboot ``` -------------------------------- ### Meta-Tegra: Add UEFI Keys to Build Source: https://github.com/oe4t/meta-tegra/wiki/Secure-Boot-Support-in-L4T-R35.2.1-and-later This snippet demonstrates how to add UEFI keys (PK, KEK, DB) to the build process by creating a bbappend for the `tegra-uefi-keys-dtb.bb` recipe. It sets up the necessary directory structure and copies the `UefiDefaultSecurityKeys.dts` file, with an optional step for `UefiUpdateSecurityKeys.dts`. ```Shell export MY_LAYER=tegra-demo-distro/layers/meta-tegrademo export MY_UEFI_KEYS_DIR=~/uefi_keys/ mkdir -p ${MY_LAYER}/recipes-bsp/uefi cat > ${MY_LAYER}/recipes-bsp/uefi/tegra-uefi-keys-dtb.bbappend <<'EOF' FILESEXTRAPATHS:prepend := "${THISDIR}/files:" EOF mkdir -p ${MY_LAYER}/recipes-bsp/uefi/files cp ${MY_UEFI_KEYS_DIR}/UefiDefaultSecurityKeys.dts ${MY_LAYER}/recipes-bsp/uefi/files/ echo "Copy below is optional, only needed if you plan to update your keys with a capsule update" cp ${MY_UEFI_KEYS_DIR}/UefiUpdateSecurityKeys.dts ${MY_LAYER}/recipes-bsp/uefi/files/ ``` -------------------------------- ### Initrd Flashing with USB Gadget Source: https://github.com/oe4t/meta-tegra/wiki/OE4T-Meeting-Notes-2022-12-8 This snippet describes the process of creating an initrd that starts a USB gadget for mass storage, enabling flashing of sdcards with rootfs disk images. It also mentions the challenge of programming the bootloader and potential solutions using BUP payloads or `nvupdate_engine -force`. ```Shell nvupdate_engine -force ``` -------------------------------- ### Create /var/extra Directory Source: https://github.com/oe4t/meta-tegra/wiki/Over-the-air-reflashing-process This command creates the /var/extra directory, which is required as a mount point during the installation process for temporary storage. ```bash mkdir /var/extra ``` -------------------------------- ### Bootloader Alternatives for OE4T Source: https://github.com/oe4t/meta-tegra/wiki/OE4T-Meeting-Notes-2023-03-09 This snippet explores alternatives to the L4TLauncher EFI application for OE4T, considering issues with extlinux syntax and secure boot signing. It suggests experimenting with Grub or SDBoot, acknowledging the complexity of integrating with devicetrees. The use of systemd-boot is mentioned as a previously successful option. ```bash echo "# Want to experiment with doing away with L4TLauncher as EFI app, look at Grub or SDBoot." ``` ```bash echo "# Have used systemd-boot previously, worked well." ``` -------------------------------- ### Initrd Flashing with RCM Booting Source: https://github.com/oe4t/meta-tegra/wiki/OE4T-Meeting-Notes-2023-02-09 This describes the initrd flashing process using RCM booting, where the kernel and initrd are downloaded over USB into memory. It highlights the need for a separate initramfs and the dependency on `bmaptool` for efficient flashing. It also notes potential issues in non-Ubuntu environments. ```markdown See https://github.com/OE4T/meta-tegra/wiki/initrd-flashing-support Key technology is RCM booting. Downloading kernel and initrd over the USB link into memory and booting from this. Separate initramfs built for this purpose. A;ways built, but can be turned off if you don’t need it. Not sure how well it works in non Ubuntu environments. If you run into problems in other environments comment in gitter or open a ticket in the repo. Have tried to minimize number of assumptions and additional requirements. Need bmaptool or the process goes very slowly. ``` -------------------------------- ### Tegraflash Command Error Source: https://github.com/oe4t/meta-tegra/wiki/Flashing-the-Jetson-Dev-Kit This snippet illustrates a common error during Tegraflash where the command returns an error code and indicates fewer bytes were written than expected. ```bash [ 1.9394 ] 00000007: Written less bytes than expected [ 21.7219 ] Error: Return value 7 Command tegradevflash --pt flash.xml.bin --storageinfo storage_info.bin --create ``` -------------------------------- ### Extlinux.conf Boot Support for Xavier Source: https://github.com/oe4t/meta-tegra/wiki/OE4T-Meeting-Notes-2021-06-10 This snippet details the implementation of extlinux.conf boot support for Xavier on the master branch. It aims to simplify kernel development and provide a workaround for cboot issues. However, it is noted that this method is incompatible with A/B redundancy due to limitations in the cboot code path. ```Shell # Example of extlinux.conf configuration (conceptual) # LABEL L4T # KERNEL /boot/Image # FDT /boot/dtb # APPEND console=ttyS0,115200n8 console=tty1 root=/dev/mmcblk0p1 rw rootwait # Note: Actual implementation details and file paths may vary. ``` -------------------------------- ### Enable Xavier extlinux.conf Support with cboot (L4T R32.x) Source: https://github.com/oe4t/meta-tegra/wiki/extlinux.conf-support To enable extlinux.conf support on Xavier platforms (L4T R32.x) using cboot, add the 'cboot-extlinux' package to your image. This allows the kernel, initrd, and device tree to be loaded from files within the root filesystem, simplifying kernel development. ```BitBake IMAGE_INSTALL:append = " cboot-extlinux" ``` -------------------------------- ### Display Partition Table with sgdisk Source: https://github.com/oe4t/meta-tegra/wiki/Over-the-air-reflashing-process This command displays the current partition table of the specified device (e.g., /dev/mmcblk0). It's used to compare partition layouts before and after the installation process. ```bash sgdisk /dev/mmcblk0 --print ``` -------------------------------- ### Configure CUDA Binaries for Ubuntu 16.04 Source: https://github.com/oe4t/meta-tegra/wiki/L4T-R32.2.0-Notes Sets the correct reference for CUDA host-side tools when the SDK Manager was run on an Ubuntu 16.04 system. The default assumes Ubuntu 18.04. ```bitbake CUDA_BINARIES_NATIVE = "cuda-binaries-ubuntu1604-native" ``` -------------------------------- ### Add meta-linaro-toolchain Layer Source: https://github.com/oe4t/meta-tegra/wiki/Using-linaro-gcc7-for-CUDA-support This snippet demonstrates how to add the meta-linaro-toolchain layer to your OE-Core project using bitbake-layers. This is a prerequisite for using the GCC 7 toolchain. ```Shell bitbake-layers add-layer meta-linaro/meta-linaro-toolchain ``` -------------------------------- ### Verify Device Tree Compatible String Source: https://github.com/oe4t/meta-tegra/wiki/Using-device-tree-overlays Command to display the compatible string from the base of the device tree in the running system. This helps verify that the applied device tree configuration is active. ```bash cat /sys/firmware/devicetree/base/compatible ``` -------------------------------- ### Configure Build for Signing (BitBake) Source: https://github.com/oe4t/meta-tegra/wiki/Secure-Boot-Support This snippet shows how to configure your BitBake build environment to include signing and optional encryption arguments for boot images and BUP packages. These arguments are passed to the flash-helper script during the build process. ```BitBake TEGRA_SIGNING_ARGS = "-u /path/to/signing-key.pem -v /path/to/encryption-key" ``` -------------------------------- ### Include Vulkan Package in Yocto Image Source: https://github.com/oe4t/meta-tegra/wiki/JetPack-6.0-L4T-R36.3.0-Notes To enable Vulkan support in your Yocto-built image, you must manually include the 'tegra-libraries-vulkan' package. This ensures the necessary configuration file for the Vulkan dispatcher is installed. ```bash IMAGE_INSTALL:append = " tegra-libraries-vulkan" ``` -------------------------------- ### Bitbake Integration for LUKS Encryption Source: https://github.com/oe4t/meta-tegra/wiki/OE4T-Meeting-Notes-2022-05-12 This section discusses the challenges of integrating LUKS encryption directly into the Bitbake build process. It highlights the need to run outside of sudo or fakeroot, suggesting Bitbake might need to run within QEMU. This is a potential roadblock for encrypting at build time. ```Shell Tried to create LUKS encryption in bitbake. Need to run outside sudo or fakeroot. Only possibility might be to have bitbake run in qemu. Will need to wait until after figuring out A/B and secureboot. ``` -------------------------------- ### Tegra Serial Console Error Output Source: https://github.com/oe4t/meta-tegra/wiki/Flashing-the-Jetson-Dev-Kit This snippet displays error messages captured from a serial console during a Tegraflash failure, often related to storage device communication or command execution. ```text [0020.161] device_write_gpt: Erasing boot device spiflash0 [0039.824] Erasing Storage Device [0039.827] Writing protective mbr [0039.833] Error in command_complete 18003 int_status [0039.840] Error in command_complete 18003 int_status [0039.847] Error in command_complete 18003 int_status [0039.852] sending the command failed 0xffffffec in sdmmc_send_command at 109 [0039.859] switch command send failed 0xffffffec in sdmmc_send_switch_command at 470 [0039.866] switch cmd send failed 0xffffffec in sdmmc_select_access_region at 1301 [0039.876] Error in command_complete 18001 int_status [0039.883] Error in command_complete 18001 int_status [0039.890] Error in command_complete 18001 int_status [0039.895] sending the command failed 0xffffffec in sdmmc_send_command at 109 [0039.902] setting block length failed 0xffffffec in sdmmc_block_io at 945 [0039.909] block I/O failed 0xffffffec in sdmmc_io at 1215 [0039.914] block write failed 0xffffffec in sdmmc_bdev_write_block at 178 [0039.921] device_write_gpt: failed to write protective mbr [0039.926] Number of bytes written -20 [0039.930] Written less bytes than expected with error 0x7 [0039.935] Write command failed for GPT partition ``` -------------------------------- ### Grub Bootloader Support in Jetpack Source: https://github.com/oe4t/meta-tegra/wiki/OE4T-Meeting-Notes-2023-08-10 This snippet highlights the integration of Grub bootloader support within the Jetpack system. It references documentation for detailed implementation and configuration, particularly for UEFI environments. ```Markdown See [this link](https://docs.nvidia.com/jetson/archives/r35.4.1/DeveloperGuide/text/SD/Bootloader/UEFI.html#grub-support). ``` -------------------------------- ### Avoiding Tegraflash Helper Script Changes Source: https://github.com/oe4t/meta-tegra/wiki/OE4T-Meeting-Notes-2022-06-09 The team aims to avoid modifying NVIDIA's tegraflash helper scripts by booting into an OS and installing from there, as the current scripts are too tightly coupled to Ubuntu. ```Shell # Tegraflash helper script changes from NVIDIA can be avoided, since you boot into an OS and install from there. # Too hard-coded to the Ubuntu OS to be useful most likely. ``` -------------------------------- ### External Device and RCM Boot Options Source: https://github.com/oe4t/meta-tegra/wiki/initrd-flashing-support Helper scripts support `--external-device` for passing options to `tegraflash.py` and `--rcm-boot` for direct kernel/initrd download and execution. ```bash initrd-flash --external-device --rcm-boot ```