- we don’t just “let them use” it, they are aware of the DP state. But due to an issue with the WIFI modules that exists in the 4.9.x kernel used by jetpacks <5, we all hardly wait for a kernel 5 included in the NVIDIA BSP.
I mean, kernel.org released the 5.0 version already 2019! We did not expect to wait such a long time for a 3 year old kernel! - as i already mentioned in the linked post, there was no kernel modifications made to the tegra_defconfig. Also, the corresponding kernel options which are in question can be found there. So, let me reformulate the question: what does CONFIG_ARCH_TEGRA_19x_SOC if it is not needed for Xavier NX SOCs?
- we already ported our board changes successful (beside the WIFI issue, see above) with JP4 (L4T 32.5.1), so it seems strange to repeat this for every new major JP release!
For the usb hint, we also recognised this timely coincidence - the kernel throws a panic each time right after some usb enumerations. This is happening regardless of the USB Controller (SOC integrated or attached via pci).
We think it is probably sth. in conjunction with disabled SSC on one PCI Channel (CH5), because the image works on the DevKit with SSC enabled.
In this post, the moderator gives the hint that disabling SSC on plle can lead to USB issues.
We did not deactivate it for plle (CH4) but for pllnvhs (CH5), so we did not expect getting in trouble with USB.
Beside these two clocks, there are several failures during clock assigns and MEMIO mappings for certain components in the logs, which are also occurring with devkit and default image, so we were not sure what is the current status of the DP regarding clocks, mem and thus tegra19x support.
Where are the screws which we can adjust the timing behaviour, so we could avoid the panic?
It seems, that if the DPAUX write errors occur in early boot, the error is thrown more often.
Can it be the cpu-boost option in the USB dtb tree? Or sth. else we don’t have in mind…?