I am using new BSP r35.4.1 and a carrier board Jetson Xavier NX (it is unfused board)
I created a sample customized rootfs and enabled disk encryption but during flashing the Jetson Xavier NX board failed to boot and get stuck in “Waiting for target to boot-up…” . Log coming from
Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash_internal.sh
NOTE: I am not using any docker environment. I am using an Ubuntu 20.04 based PC.
However, I didn’t face this issue in earlier BSP r35.1
I also noticed l4t_initrd_flash_internal.sh file has changed since r35.1 to r35.4.1 version. That’s why I used --network usb0 flag in my flash command. But still can’t make it to work .
Could you please let me know the reason for it and how can I make it work with new BSP r35.4.1
Thanks !
Logs:
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Timeout
Cleaning up…
I also saw that it got stuck in loop in l4t_initrd_flash_internal.sh with parameters :
I am not using SDKManager to install JP-5.1.2. I have created a customized rootfs which I want to flash on the Xavier NX board. Could there be something wrong here ?
In earlier BSP 35.1, modifying the init file in l4t_initrd.img was working perfectly fine.
But in this BSP 35.4.1, even adding a simple echo statement in initrd is leading to “Timeout” issue. but if we don’t modify this init file, it works perfectly while flashing without “Timeout” issue.
If yes, how can we do that ? We tried this approach by using flag "–uefi-keys uefi.conf " with l4t_initrd_flash.sh script but it didn’t generate initrd.sig.
Note: We tried signing the initrd both for fused and unfused boards but it didn’t work either.
so… it means you’re able to flash the target with disk encryption enabled on default r35.4.1 release image.
may I have more the details to update init file?
We extract init file from l4t_initrd.img and then edit the init file by just putting an echo statement, nothing more, then we repackage the initrd contents into l4t_initrd.img and copy it to bootloader. Thats it…
decompress:
cp bootloader/l4t_initrd.img ~/initrd/
cd ~/initrd/
gzip -cd l4t_initrd.img | cpio -imd --quiet
vi init #Just added a echo statement in “init” file
rm l4t_initrd.img
But during flashing the initrd contents (init file which I modified with an echo statement gets overwritten) are overwritten with default values. Why are my changes in initrd gets lost when I run the l4t_initrd.flash.sh script ?
We want to modify the initrd in order to implement generic passphrase based disk encryption.
As the generic passphrase based implementation is not directly supported by Nvidia, we want to try it ourselves.
Could you please let us know what exactly changed from BSP 35.1 to BSP 35.4.1 while modifying “l4t_initrd.img” ?
Because I was able to modify l4t_initrd.img in BSP 35.1 by modifying init file and flash the jetson but this leads to “Timeout” in new BSP 35.4.1 as I mentioned earlier. If you could help us resolving this , that would be great help.
I’ve put this into internal discussion, and it may takes some time to come out conclusion.
anyways, could you please see-also Topic 266810 for the steps to modify initrd for testing.
BTW,
please note that you should do "sudo su" before modifying the initrd, or it may cause a problem.
for the steps to modify the initrd (on target or on the host), you must use the parameters in these commands EXACTLY,
for instance, To Modify Ram Disk.
Thanks @JerryChang .
It was indeed the issue of sudo permissions.
While modifying init file l4t_initrd.img with old BSP 35.1, I was using “sudo su” but somehow it got skipped while migrating to new BSP 35.4.1.
I re-ran the steps of modifying init file with “sudo su” and now the “Timeout” issue is not there anymore.
Thank you again for your suggestion and reminder to use “sudo su”.