I am trying to update kernel image without full flash due to customer request.
We need to update kernel image to fix some issue happens on customer’s device.
And I already check issue can be fixed with full flash.
(We are using JetPack 4.6.4.)
After check dmesg log, I can confirm device tree is replaced to my new device tree.
But I still observe issue happens.
It seems not replace kernel image correctly.
How can I update kernel correctly without full flash ???
Thank you.
I only can verify kernel image with issue reproduce steps.
If kernel image is updated correctly, issue should be fixed, right ???
Please refer to 0001-display-Get-back-time-delay-to-wait-DSI-stable-for-r.patch for our modification.
We adjust timing of DSI bridge IC power sequence and it is a built-in driver.
If it shows the build time of new kernel image, then I think the kernel has been updated correctly.
Do you build the driver into kernel image or as kernel module?
If you build it as kernel module, you have to transfer the .ko into the device (/lib/modules/..) and run sudo modprobe XXX to load it manually.
We build the driver as built-in driver in kernel defconfig.
( We set CONFIG_TEGRA_DSI2LVDS_SN65DSI85=y in kernel defconfig.)
So, I think this driver should be included in kernel image, right ???
Since you have added CONFIG_TEGRA_DSI2LVDS_SN65DSI85 as an integrated feature (the =y) it implies you probably need to also install all modules and change the CONFIG_LOCALVERSION (default is “-tegra”, you could rename it as something like “-sn65dsi85” or “-dsi2lvds”). If you had matched your kernel config for all integrated features, and then added purely as a module, then you could copy in just the one module. As is you have a lot more work to do, and it is riskier. If you use an initrd, then you would also have to update the initrd with the new modules. Adding modules not used for boot don’t require an initrd change, but you have probably invalidated all of the existing modules and will need a new initrd (if you have an initrd, which many people don’t use except for external boot devices).
Not all features can be a module, and not all features can be integrated, but most can be either. Is there a reason you need this device as integrated? Every time the driver updates you’ll have to go through the complete install of kernel and all modules. With a module it is just one file copy (followed by “sudo depmod -a” to tell the kernel to scan for changes in modules).
CONFIG_TEGRA_DSI2LVDS_SN65DSI85=y is already in kernel defconfig, even in old kernel image.
We don’t change kernel defconfig, and only adjust power sequence in this bridge IC driver.
Because it is part of display driver, we set it as a built-in driver.
Sorry for my unclear explain.
I also tried to update initrd image in rootfs but it doesn’t work.
We still can observe issue happens after partial flash and replace kernel image in rootfs.
If this has any dependencies in the form of a module, then changing to “=y” (editing the kernel) would imply all modules likely also must be recompiled. Perhaps a dependency is missing? Same if this was set to “=y” without a context-aware editor (e.g., menuconfig is context-aware).
On a different way of talking about this, if the camera is not plug-n-play, then you would also need to have added device tree edits if you added that config. This includes making sure that all power rails for the device and any part of its support have the correct device tree.
Think of device tree as arguments passed to drivers to tell them things about hardware that the driver cannot probe. A USB device can self-report a lot of details, and the address to access this is known simply due to the USB subsystem. There are other cases where plug-n-play might exist, e.g., for PCIe slots, but many other methods of connecting won’t inform the driver about things like physical address to look at, and the driver to associate with the address. Having the driver is half of this, but telling the driver where to find the hardware is still required. I’m reminded of the saying that “the lights are on, but nobody is home” when a driver is present but there is no association to the hardware. Device tree is possibly the issue.
