Closed elbbit01 closed 1 year ago
This is the kernel trying to load the firmware from the file /lib/firmware/tegra19x_usb_firmware
. Is that file missing from your rootfs? If you use an initramfs (as we do in this demo distro), is that firmware file installed in the initramfs's rootfs filesystem? The driver may need that firmware early on in the boot process, so you need to make sure it's included in your initramfs.
Hi, first of all thank you for your quick answer. Actually your question triggered some deeper recheck on our recipes. We are building as you do in the demo distro, with initramfs, but we generate the update payloads adding to IMAGE_FSTYPES = cpio.gz.cboot.bup-payload. (Is this the right way to generate update payloads for an image based on this demo distro?) When we update, I am not sure if initramfs is included in any of the automatically generated payloads or how to separately generate a payload for it. It is anyway strange that after this partial updates, the system boots everything (except usb firmware) if there is no initramfs, right?
Regards.
The mechanism for generating the BUP payload depends on whether you've got INITRAMFS_IMAGE_BUNDLE
set to 1 or 0. By default, we have it set to 1, so bitbake kernel-bup-payload
should generate the correct payloads for you. If it's set to 0 (separating the initrd from the kernel build), you need that IMAGE_FSTYPES
addition (and we do that automatically in the tegra-minimal-initrams
recipe).
Hello, we were actually using the default value, but somehow setting extra the IMAGE_FSTYPES generated the wrong payloads. We saw that inside the tegraflash container there is a script to generate the payloads and manually used it. With that manually generated payloads our update is working fine.
Is there a proper predefined way to automatically generate these update payloads during the yocto build process without explicitly unpacking the tegraflash container afterwards?
Thanks in advance, Alvaro.
As I mentioned above, the kernel-bup-payload
will do that for you. But even simpler is to use the tegra-bup-payload
recipe, which installs a BUP payload into the /opt/ota_package
directory in your rootfs; it calculates its dependencies based on the initramfs bundling setting automatically.
By default it installs the full bl_update_payload
; if you need to use one of the subset payloads instead, you can do that via a bbappend.
Hi, you are right of course, I just followed my line of thinking and skipped what you meant with the recipe. The kernel-bup-payload recipe is all I need. It is working now. I just need to adapt a couple of recipes on my project. Thanks a lot. Alvaro.
Hi, I have an issue when uploading the kernel. We have an OS for nvidia Jetson Xavier based on meta-tegra where everything works fine when flashing with the autogenerated scripts. We have also been updating the rootfs without a problem, and we have found issues doing so with kernel_only.bup-payload. We are using nv_update_engine for it, first enabling redundancy and then installing the payload. Thats it. No error message, all success, but when rebooting, usb is not working and in dmesg we can find the following errors:
tegra-xusb 3610000.xhci: cannot find firmware....retry after 1 second [ 14.975822] tegra-xusb 3610000.xhci: Direct firmware load for tegra19x_xusb_firmware failed with error -2 [ 14.975829] tegra-xusb 3610000.xhci: cannot find firmware....retry after 1 second [ 15.600459] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 15.601534] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 15.999778] tegra-xusb 3610000.xhci: Leaving it upto user to load firmware! [ 15.999826] tegra-xusb 3610000.xhci: Direct firmware load for tegra19x_xusb_firmware failed with error -2 [ 15.999832] tegra-xusb 3610000.xhci: Giving up on firmware
We tried also updating the xusb_only.bup-payload. When it is just that payload, it works properly, but if we update the kernel too, then we have the same issue. It also happens with bup-payload (the main one).
I have tried to update to the autogenerated payloads from the similar build as I have flashed on the board, so there shouldnt be differences on the partition table, on the kernel size or anything like that. No changes in xusb firmware either.
Am I missing some step here?
Thanks in advance, Alvaro.