Confusion about how to flash custom carrier board

Hello,

we are developing a custom carrier board and have produced a first revision of it yet.
We made some kernel module and DT mods to bring it up following the steps in Kernel Customisation & Bring-Up Guide.

It could be observed, that after flashing, until apt update had run, everything works fine.
After update, several packages of the nvidia-l4t-series have errors, espacially the kernel package.

After digging around in this forum and inspecting flash.sh and apply-binaries.sh sources, the confusion about the functionality is even got bigger:

Generally, it makes no sense to have a custom and generic Image installed at the same time (if not targeting multiboot scenarios). So, the only clean solution seems to regenerate or update the debs according to Repackaging Debian Packages in the Linux Developer Guide, which would made the whole rootfs installation of kernel, modules and bootloader done by the build & flash process more or less senseless.

So, what is the desired way of bringing our custom software mods to our custom carrier board?

We use L4T R32.5.1 /w Jetson Xavier NX Production Version (p3668-0001).

What is the “software mods” that you changed here?

If this is just dtb and kernel, I would suggest you can run the apply_binaries.sh first and then put your “software mods” to the BSP package afterwards so it won’t get override again.

You mean putting them to the rootfs after apply_binaries.sh?

This only works until the first apt upgrade has run because the packages then will override the manual setup, and in addition, it will corrupt its own installation because the package expects its own configuration has taken place and thus cannot deal with our manual setup.
This leads to a system with broken kernel package!

The error during update:

Processing triggers for initramfs-tools (0.130ubuntu3.13) ...
update-initramfs: Generating /boot/initrd.img-4.9.201-tegra
Warning: couldn't identify filesystem type for fsck hook, ignoring.
I: The initramfs will attempt to resume from /dev/zram3
I: (UUID=aaa45a08-77ed-4889-b09f-277c94e041e0)
I: Set the RESUME variable to override this.
/sbin/ldconfig.real: Warning: ignoring configuration file that cannot be opened: /etc/ld.so.conf.d/aarch64-linux-gnu_EGL.conf: No such file or directory
/sbin/ldconfig.real: Warning: ignoring configuration file that cannot be opened: /etc/ld.so.conf.d/aarch64-linux-gnu_GL.conf: No such file or directory

I am little bit confused by the whole procedure here.

Are you saying that you run the “apt upgrade” on the “device” (not host) and the kernel is then broken?

Yes, surely on the device.

The procedure is as follows:
On Host:

  1. Customise Kernel .config
  2. Customize DTS
  3. Apply Binaries
  4. Build Kernel & DTBs
  5. Install Modules (+ DTBs)
  6. Flash

On Device:

  1. Boot
  2. Complete OEM-Setup
  3. Reboot
  4. Reacting on the “There are software updates available” message in the task bar and upgrading.
  5. Error above occurs

→ broken initrd (built modules, firmware not available)

It is expected. The apt upgrade will install the jetpack again to your device and this “jetpack” does not know any of the customization you made for your board.

Thus, to prevent it, you can remove the NVIDIA related source from you apt source list.

So in rootfs/etc/apt/sources.lists?

Yes, there would be a NVIDIA related source list file.

Ok, this sounds promisingly. I will try and give a feedback as soon as i know more.

So the workaround /w out commented nvidia apt sources works.
Unfortunately, this cannot be a solution for production purposes because the rest of the packages (cuda, multimedia, etc.) should stay installable by our customers.

For this purpose, i repacked the following packages:

  • nvidia-l4t-kernel
  • nvidia-l4t-kernel-headers
  • nvidia-l4t-xusb-firmware
  • nvidia-l4t-initrd
  • nvidia-l4t-dtbs

This works, meaning that other kernel related packages (like certain dkms backports, e.g. backport-iwlwifi-dkms) can be build and initrd/initramfs rebuilds and bootloader updates don’t break the system.

The only thing remaining is the package update mechanism which leads to a switch back to the official nvidia packages as there exists a newer version online than the repacked one kept locally and an apt upgrade is started.

To avoid this i can set the status of the corresponding packages to hold on the target system.

How can i achieve this on the host system? Is there a config file or sth. like that which can be used to set up dpkg selections or is there a rc shell script in which i can set the package hold status manually /w apt-mark?