Re-align RDEPENDS / RRECOMMENDS for NO_RECOMMENDATIONS = "1"

[maximdeclercq]

Some essential dependencies are listed as RRECOMMENDS in conf/machine/include/tegra-common.inc:

MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS = "kernel-module-ina3221 kernel-module-lm90 kernel-module-tegra-bpmp-thermal kernel-module-spi-tegra114 kernel-module-pwm-fan \
                                       kernel-module-ucsi-ccg kernel-module-pcie-tegra194 kernel-module-phy-tegra194-p2u \
                                       kernel-module-nvme kernel-module-pwm-tegra kernel-module-tegra-xudc"

For some distros I set NO_RECOMMENDATIONS = "1", which drops all of them, and the board then no longer flashes or boots:

• Essential for flash: kernel-module-tegra-xudc
• Essential for boot: kernel-module-nvme, kernel-module-pcie-tegra194, kernel-module-phy-tegra194-p2u

Moving them to MACHINE_ESSENTIAL_EXTRA_RDEPENDS might not be the right fix either, since the build could fail on kernels where these are =y instead of =m. So perhaps a better mechanism is needed to keep NO_RECOMMENDATIONS = "1" both buildable and runnable.

The flash scripts look like they might suffer from the same issue. tegra-target-flash-scripts lists essential modules under RRECOMMENDS, so the flash scripts might have issues under NO_RECOMMENDATIONS too.

[madisongh]

Yeah, we pretty much have to use RRECOMMENDS for kernel modules, for the very reason you mention - using RDEPENDS causes build failures when the needed kernel module is built into the kernel. I'm not sure there's been any effort upstream on coming up with a better way to handle that situation.

For now, you could add those to MACHINE_ESSENTIAL_EXTRA_RDEPENDS for those distros where you set NO_RECOMMENDATIONS.

I'm generally not happy with the excessive modularization of the kernel, anway. It's good for kernel developers, maybe good for desktop/server distros, but not as good for embedded use cases, IMHO. I would like to update the default kernel configuration to build in more of the absolutely-necessary drivers. Those drivers that are part of the NVIDIA out-of-tree bundle could then be referenced by their real name (with the nv- prefix) in an RDEPENDS setting, since they'll always be separately packaged.
The only downside I can think of there is that some of the OOT drivers replace in-tree drivers, but only for certain versions of the kernel, and keeping up with what's where, over time, could get messy.

[maximdeclercq]

Thanks for the reply.

It seems a bit narrower than I first thought. Boot turned out to be a local issue on my side rather than upstream, since the default tegra-minimal-initramfs already hard-PACKAGE_INSTALLs the storage modules and NO_RECOMMENDATIONS doesn't touch them.

The flash path does look like a real gap, and it seems arch-split. On Thor (tegra264) the flash initramfs pulls tegra-target-flash-scripts, whose RRECOMMENDS carry the adb/functionfs gadget stack (kernel-module-libcomposite and kernel-module-usb-f-fs). On Orin (tegra234) it uses tegra-flash-init instead, with RRECOMMENDS on kernel-module-libcomposite and kernel-module-usb-f-mass-storage. NO_RECOMMENDATIONS drops all of those, so flashing seems to break on either arch, which is also what tegra-demo-distro would hit.

On my end I just promoted these to RDEPENDS for Thor, but that's not really upstreamable because of the =y issue. Upstream there might be two options.

1. Hard-PACKAGE_INSTALL them per arch in tegra-initrd-flash-initramfs (matches how it already lists modules, but reintroduces the =y break)
2. PACKAGE_INSTALL_ATTEMPTONLY (=y-safe and survives NO_RECOMMENDATIONS, but a less common use and fails quietly).

Not sure which fits best according to the layer's conventions.

I'll try to replicate it on tegra-demo-distro to confirm, and maybe open a PR with the arch-split fix.

[madisongh]

I played around with using PACKAGE_INSTALL_ATTEMPTONLY for referencing the drivers in the initramfs recipes, while working on fixes for #2294, and it looks like that messed with the inter-task dependencies. Dependencies on kernel packaging disappeared, so rebuilding the kernel with a new version string did not trigger a rebuild of the initramfs, leading to a mismatch between the kernel version and the /lib/modules/<version> directory name, so drivers couldn't get loaded. It could be that something else was going on, but switching back to using just PACKAGE_INSTALL for everything did clear up the problem.