I have Jetson AGX Xavier.
Following the guide on this link, I got the Image file.
After placing this kernel image file in /boot/Image, I modified the /boot/extlinux/extlinux.conf file and changed the boot kernel.
By the way, not the modified image file, it keeps booting to the original kernel. Even if you delete all the image files in /boot, it seems to boot to the original kernel only.
In Xavier, does the bootloader not read the image file in /boot or need another process?
Which part of the link is wrong?
Hi,
Please provide the /boot/extlinux/extlinux.conf and the boot up serial console log.
Thanks
This is my console log and extlinux.conf file.
/boot/Image.ae is the kernel file I want to run.
Please let me know if you need anything else.
What is the problem?
output.log (122.2 KB)
extlinux.conf.txt (596 Bytes)
I don’t know if this is the case, but on some releases there was a bug where the “default” was not honored unless it was also the first entry. You might use serial console to interrupt and specifically pick your entry; alternatively, rearrange such that your ae entry is first before the original. Do beware though that if you’ve removed other content, and your content fails, then you could end up needing to flash again.
FYI, although what follows will seem irrelevant, it could in fact illustrate something…
When an eMMC model of Jetson boots, then the rootfs is the only part with the operating system itself; a large number of other partitions exist. Those partitions include a software equivalent of everything the BIOS would do if the Jetson had a BIOS. People who are looking for security in the boot stages would enable SecureBoot which enforces a custom signed content for every partition except for the rootfs. Some content which was previously in “/boot” suddenly is no longer allowed, including the kernel Image and the initrd. Even if the Image is named and present, that content essentially is blacklisted and invisible. Partitions which are properly signed are never invisible and exist even if they were never before used.
Kernel and initrd have always had partitions for that content, but the files named in extlinux.conf take precedence…unless security fuses are burned; in that case the /boot Image and initrd are ignored. Binary partition content will take over for the missing Image. Your removal of the Image file won’t stop boot to that same kernel if you have the binary partition with the Image. I assume you have not flashed, and this is why it still boots to the original kernel.
Note that I think you are booting to the original entry due to a bug and that this old/original entry boots even without the Image file because the content is coming from a binary partition. As soon as you swap entries such that the new ae entry is first, then I’m guessing it will do what you expected (provided the new kernel is valid). If not, then you would have to revert to the original entry to get the binary partition kernel to boot (e.g., via picking this entry in serial console during boot). With no “/boot” kernel the binary partition is still there.
Hi. Thank you for your response.
As you told me, I set ae to the first entry, but it still doesn’t work.
Even after I deleted the extlinux.conf file, it boots to the original kernel. As you said, it’s secure boot, so I think the kernel loads from the binary partition, not rootfs.
As you said, I would like to try to set the boot up through the serial console.
I can even connect a debug serial to check the boot log, but I don’t know how to set the boot entry via serial console.
Can you tell me how to do it?
I did not know you had burned the security fuses. Yes, in that case the content is not allowed from /boot. The content is only allowed from the signed binary partitions, which in turn is added only via flash. The flash or use of that content will of course fail if you don’t use the correct key.
Look up the docs for your specific L4T release (see “head -n 1 /etc/nv_tegra_release” to find the release). Then follow the instructions for flashing with a custom key:
https://developer.nvidia.com/linux-tegra
Basically it will tell you how to add your kernel to the flash software, and then the correct flash will use that (along with the key to sign with; binary partitions are a few bytes larger than the actual content because the signature is included along with the content).