Please provide the following info (check/uncheck the boxes after clicking “+ Create Topic”): Software Version
DRIVE OS Linux 5.2.0
DRIVE OS Linux 5.2.0 and DriveWorks 3.5
NVIDIA DRIVE™ Software 10.0 (Linux)
NVIDIA DRIVE™ Software 9.0 (Linux)
other DRIVE OS version
other
make -C kernel O=${PWD}/out-t186ref-linux tegra_defconfig
Configuration diff:
diff config-5.1.6.1 ./5.1.6.1/drive-oss-src/out-t186ref-linux/.config
6656c6656
< CONFIG_RCU_TRACE=y
---
> # CONFIG_RCU_TRACE is not set
6955c6955
< CONFIG_CRYPTO_SHA256_ARM64=m
---
> # CONFIG_CRYPTO_SHA256_ARM64 is not set
6958c6958
< CONFIG_CRYPTO_AES_ARM64=m
---
> # CONFIG_CRYPTO_AES_ARM64 is not set
Thankfully the difference is small.
Is there a way we can pull the .dtb file off of the unit so we can check them?
I see no path forward for rapid-application-development and multi-vendor integration when everyone has to build their own kernel. This is the point and purpose of using a highly stable platform such as an Ubuntu LTR.
A 5 minute task, build a DKMS module, turns into considerably more work.
The discrepancy between the default config and released config highlights a quality-control / release-control issue.
The binary released does not match the source-code release. This particular difference is small and easily remedied.
However consider how many people building the kernel to build new modules didn’t check and it indicates there is a flaw in the release process which makes this discrepancy possible at all.
This diminishes the value proposition of the Drive AGX platform for R&D.
I also need to know how to pull the .dtb file from the unit so I can check that isn’t broken or significantly different.
e.g. How do I access the boot partition and copy a file out of it?
(I am familiar with the u-boot tool and how it works.)
tegra_defconfig gives you a general default configuration for Tegra series SoCs. One shouldn’t expect it to match NVIDIA’s kernel configuration for specific products.