Hello,
I have clonned raw image , I need to change kernel configuration(kprobes) and then flash this image to my jetson xavier agx.
Is there any way to change kernel configurations in clonned image on host computer and then flash it to jetson.
Thanks & Regards
Harshad
Yes. You said “raw” image, which is exactly what you need since it can be loopback mounted.
“Covering” a file with loopback means the loopback device can be treated as an ordinary block device (a partition or an entire disk). Covering a raw image with loopback means the loopback device becomes an ext4 partition. Do keep in mind that when done you need to release the loop device, otherwise you will run out.
The simplest method is to let mount do the loopback covering (you can do it in manual steps if you wish). Example, if the file is named “system.img.raw”:
sudo mount -o loop ./system.img.raw /mnt
ls /mnt
sudo umount /mnt
Note that you can list all active loop devices with “losetup -a”. You can detach a specific loop device (using “/dev/loop0” as an example) with “sudo losetup -d /dev/loop0”. You can blanket detach devices with “sudo losetup -D”). There are cases where using losetup as a regular user will list a loop device, but not create nor modify that device, whereas doing the same thing as user root/sudo will create a device in addition to listing it.
If you were to have temporarily mounted your loopback image on “/mnt”, then you can add or remove or alter files in “/mnt/boot”, for example, the kernel. You could add a kernel and modify “/mnt/boot/extlinux/extlinux.conf” to provide a new boot entry (and thus be able to use serial console to pick which entry to boot if you want the non-default entry, and perhaps rescue a system without use of flash).
Note that a normal command line flash might be something like this, which generates a new image each time run (adjust for your Jetson model):
sudo ./flash.sh jetson-xavier mmcblk0p1
(this writes a new “bootloader/system.img” and “bootloader/system.img.raw” each time)
However, to “reuse” the rootfs image, and not create a new one:
sudo ./flash.sh -r jetson-xavier mmcblk0p1
The above never overwrites and never creates any change to “bootloader/system.img.raw” or “bootloader/system.img”.
During flash only the actual “system.img” is flashed, and this is a “sparse” file by default, but a raw image works the same way without error if it is named system.img, but it takes longer to flash. You could place your modified image (make sure it is not mounted and not covered by loopback before you start…perhaps it wouldn’t be a problem, but it is asking for trouble to flash something mounted) as “bootloader/system.img” and that is what would be installed.
The “mksparse” (with fill pattern “0”) can be used to convert a raw file to sparse if you wish.
Note that there are also ways to set your kernel Image file by way of a conf file as well, such that it would still generate a new image prior to flash, but the image would use your kernel.
Hi,
Steps followed by me:
For Build:
1.) I downloaded L4T_32.6.1 sources and taken it to Nvidia Jetson Agx Xavier Target platform.
2) Link used for downloading: Jetson Linux R32.6.1 Release Page | NVIDIA Developer
Dowloaded the highlighted pakage.
For flashing:
After doing all this I am unable to boot my target. I don’t where is the issue thatsy I shared all the steps i did.
Please support.
Thanks & Regards
Harshad
My target platform is showing blank screen and i tried booting it up using power button and reset button but it is not booting.
This is incorrect when building natively. Do not specify “ARCH=”, let the build figure it out. Directly specified it is likely to think this is a foreign architecture (necessary when cross-architecture is built). Remove all of the “ARCH=arm64” and try again (you will need to make clean your output location and start over).
Hi,
Thankyou for the response. I will try doing this.
But Can you please check once if all other steps I did are correct which I mentioned above.
Thanks & Regards
Harshad
Is “O=kernel_out” a path to a temporary output location? If you typed this in literally, then it is probably wrong, but if this is an exported environment variable, then it is right.
Typically one would create an empty directory, for example, if your login name is “ubuntu”, you might “mkdir /home/ubuntu/output”. Then this command would be valid:
make O=/home/ubuntu/output tegra_defconfig
One could also save that location into an environment variable, for example:
export TEGRA_KERNEL_OUT=/home/ubuntu/output
# verify:
echo $TEGRA_KERNEL_OUT
# Now build using that environment variable instead of the exact path:
make O=$TEGRA_KERNEL_OUT tegra_defconfig
If you are building the kernel itself (and not modules, or perhaps as setup prior to building modules), then you can just build “Image” and skip “zImage”. zImage is a compressed version, and it builds Image first, then saves a compressed version as zImage, but zImage hasn’t been used in many years (when changing from 32-bit to 64-bit zImage stopped being used). And no need to “--output-sync”. You can build like this:
make O=$TEGRA_KERNEL_OUT -j 4 Image
All output would be somewhere in “$TEGRA_KERNEL_OUT”.
Note that unless you want the kernel loaded from a partition there is no need to flash. You could simply copy it to “/boot”. However, I advise keeping the old file and creating a new boot entry named after the new file. Then if something went wrong you could use serial console with the original entry selected as a kind of “rescue” boot. As an example, you could copy the new Image to “/boot/Image-custom”. Then duplicate the default boot entry of “/boot/extlinux/extlinux.conf”, and edit that for the new file. If you want a suggestion, then post your existing extlinux.conf content here and I’ll show you edits to allow picking between original kernel and new kernel using serial console.
You can of course add your Image file such that flash will use this. However, instead of memorizing which file (there are many versions of Jetsons and their carrier boards) I suggest flash once and keep a log of the flash so you can see which file it used. As an example with logging:
sudo ./flash.sh jetson-xavier mmcblk0p1 2>&1 | tee log_flash.txt
(then just look at the log and find any occurrence of “Image”)
The use of the “-r” option is to reuse an existing filesystem image, which means whatever you put in place as “Linux_for_Tegra/bootloader/system.img”. Note that no new kernel Image would be used unless it was already part of “system.img” when you “reuse” the filesystem image. It would be easier to just copy the Image to the running Jetson unless you plan to flash multiple times. You’d have to give details on what you actually want to do in order to advise, e.g., if you have several Jetsons to flash using a clone, versus just updating a kernel.
Thankyou for such a great explanation.
However, I have already tried replacing the Image in boot/Image and changing extlinux.conf but it did’nt worked for me as the target platform is Nvidia Jetson Xavier AGX with L4T 32.6.1 So I think it is booting from cboot.
Please let me know if still i can make it boot from my image or any steps todo for that.
Another thing I want to confirm that if I am flashing using flash.sh and using clonned Image then I need to only replace Image inside boot/Image in clonned Image using mount and unmount or is there any other place also in the release folder where i need to make this replacements.
How do you know it is using the wrong Image? Is this from the boot log (which is a good way to know)?
Unless security fuses are burned boot tends to look for the LINUX entry in extlinux.conf, and if found, will use that, but otherwise will use a partition image. If you know it is the wrong image based on boot log, could you attach the full serial console boot log to the forum?
Incidentally, if your replace Image at the PC side’s “rootfs/boot/Image”, then flash will overwrite this unless you’ve taken steps to use your Image. I mention replacing the Image directly on the running Jetson (and editing the running Jetson’s extlinux.conf since this too can be overwritten on the host PC side of “rootfs/”).
Hello,
I tried flash through ./flash.sh -r , following all the above steps. But still the target is not booting after flash.
log_flash.txt (2.0 MB)
I have attached here terminal logs after running flash.sh .
I am not getting where is the issue. Please support.
The flash itself worked without error. By what method have you tested if boot failed? Did you get a serial console boot log? Or just no monitor output? If boot log, then that is definitive, but if it is just the monitor not working, then it might just be video configuration. Do you have a serial console boot log you can post?
Also, if the rootfs image is not compatible with the release of flash software, then it likely would fail boot. Was the original rootfs from the same release as the flash software?
The boot failed because there is not output on monitor only blank screen. No, I don’t have serial console boot log as I dont know exactly how to take that.
Please let me know how can we enable and take serial console boot logs on host pc?
Regarding rootfs image I have also replaced the Image inside /JetPack_4.6_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/rootfs/boot/Image with my build Image.
Are you talking about this Image only or any other rootfs image?
If this is AGX Xavier dev kit, then if you look to the left of the 40-pin header there will be a micro-OTG USB socket. That socket accepts the provided micro-B USB cable, which causes the AGX to become a “device” when plugged in through that to a host PC. If you monitor “dmesg --follow” on the host PC, and then plug in the USB cable, you will see in dmesg the various “devices” the AGX emulates. Each device creates a file in “/dev”, and so for example, you might see the dmesg log indicating “/dev/ttyTCU0” or “/dev/ttyACM0” (the name depends on the driver). The first tty device should be the serial console.
If you run a serial console program on your Linux host PC, then this can talk to that device just like it is a local login on text/command line.
I prefer “gtkterm”, but “minicom” is popular, and some people use “PuTTY” (which also runs on Windows, but getting the name of the “COM” port in Windows might be more difficult). You can add “gtkterm” with “sudo apt-get install gtkterm”. Then, to talk to the serial console (I’m assuming it is “/dev/ttyACM0”, but adjust for your case), you would do this (but read the next paragraph):
gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyACM0
(this runs with setting 115200 8N1 on port ttyACM0)
The port device special file itself will be owned by root, and group dialout. A regular user can’t perform the above command without using “sudo”, but this is unnecessary. You can simply add your user to group “dialout” instead of sudo every time. If your user name on the PC is “ubuntu”, then this would add your user to group “dialout” (a secondary group):
sudo usermod -aG dialout ubuntu
(after this user “ubuntu” can use any of the regular serial ports without sudo)
Note that serial console programs have the ability to log to file (or clear screen followed by log to file). It is quite easy to tell the program to start logging right before you plug in the Jetson, and whatever you see will be logged from the moment the Jetson starts. You can attach this log to the forum and it says a lot since it include content from before Linux ever loads (dmesg only works if you can log in and then only for logs once Linux starts…it is better if even the boot stages get logged).
Incidentally, when using the capitalized “Image” I speak of the kernel file in “/boot”. When speaking of lower case “image” I am referring to the partition content of the root filesystem (“Image” is installed on the “image” prior to flash).
Hi,
I have tried replacing my Image and modules directly on the target and rebooting it by changing paths in extlinux.conf.
My target booted successfully and I can see my changed Image also but I am getting some warnings related to hdmi on console and it keeps coming in loop on console even after i logged in to target through ssh.
Messages seen are: “tegradc 15210000.nvdisplay: dc_hdmi_out_enable: couldn’t get regulator avdd_hdmi”
Also sharing the boot console logs for your reference. Please support.
boot_logs_2.txt (88 KB)
Is this a dev kit, or does it have a third party carrier board? If third party, then I’d say the odds are the device tree needs changes. If it is a dev kit, then I am surprised and it might be missing one of NVIDIA’s drivers (e.g., the build of the new kernel Image might have missed something).
Btw, what do you see from “uname -r”? Also, if you boot from the original stock kernel, what do you see from “lsmod”? If you instead boot from your kernel, what “lsmod” do you see there?
Hi,
No it is not devkit, yes it is a third party Xavier AGX carrier board from Connecttech. Please check this link https://connecttech.com/resource-center/kdb373/
With uname -r , I was able to see my kernel with localversion name I have given while building . Something like : “4.9.253-tegraupdated”
After booting from original kernal lsmod gives modules names and size . See below screenshot
But when I booted from my Image and replaced my build modules inside lib/modules/ in a seperate folder named as 4.9.253-tegraupdated . Then I can not see any output from lsmod.
Another thing If I replace old original kernel modules inside this folder and then boot with my new Image only. Then I can see modules details with lsmod. But hdmi warnings still appears on console.
I am not getting where is the issue. Please let me know how can I boot properly with my new Image. what changes needs to be done.
When you run command “uname -r”, does it say “4.9.253-tegraupdated”? Can you successfully “cd /lib/modules/$(uname -r)/kernel”? When you configured your kernel prior to build, did you start with either the “tegra_defconfig” or running system’s “/proc/config.gz”?
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
