Qemu Emulation

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
1

How can I create an image from my current setup on the xavier board and use this image in qemu-system-aarch64?
Now I have to test on the actual xavier do my changes than reflash(takes a long time) and then repeat.

2

It would only be the rootfs/APP partition, but you can clone a Jetson. Is this the SD card dev kit model? Or is it an eMMC model? Cloning information changes depending on model. That clone can then be mounted on loopback and would be an exact match for the entire rootfs/APP for use with QEMU.

3

The xavier is an emmc version

4

I have the system image created by the jetson-disk-image-creator.sh,that I use for the nvmflash.sh to flash the board .Also tried to use dd to clone the mmcblk and run in qemu using this launch command:

qemu-system-aarch64 \
	-machine virt -cpu cortex-a57 -m 2048 -smp 4 \
	-bios <aarch64/u-boot.bin> \
	-drive if=none,id=sda,format=raw,file=<IMAGE>  \
	-device virtio-blk-device,drive=sda \
	-device virtio-keyboard -device virtio-tablet \
	-device virtio-gpu,xres=1366,yres=768 -nographic -vnc :0

I grabbed the uboot version and the command from : Regular/arm - ALT Linux Wiki

5

I don’t know enough about qemu-system-aarch64 to offer help in its setup. However, how do you specify the path to either (A) the partition containing the file system, or (B) the path to a mounted file system to use as the root file system?

If you have a clone, and if that clone is named “system.img.raw”, then these examples are related:

  • Access as a partition by creating a loop device:

    • “sudo losetup --find --show system.img.raw” (pretend the reply is “/dev/loop0”)
      Now you can pretend “/dev/loop0” as if it is a hard drive partition, e.g., equivalent to something like “/dev/sda1”.
    • Now manually mount this on a mount point if you want to explore content or access it as a file system on temporary mount point “/mnt”:
      “sudo mount /dev/loop0 /mnt”
      (or unmount via either “sudo umount /dev/loop0” or “/sudo umount /mnt”)
    • Or, if the loop device is no longer in use, remove loopback (this is a limited resource):
      “sudo --detach /dev/loop0” (or shorter, “-d” instead of “--detach”)

  • Directly attach and mount in a single step if not already covered by a loop device (example mount point “/mnt”):
    sudo mount -o loop system.img.raw /mnt

How would you normally specify the partition or location/path to use for the root filesystem in “qemu-system-aarch64”? I don’t see an obvious method in your command line.

6

To specify the image I replace the placeholder in the command.
I tried it with the image created using dd i get stuck at starting kernel.

Uboot automatically finds my kernel file in the image and tries to launch it

7

I also tried modifying the extlinux conifg and chaged the /dev/mmcblk to the uuid of the disk

8

The images provided by the altlinux run properly using this command
Also tried to use the boot folder from one of the alt linux images and replaced the rest of the files with my data
Reached initramfs waiting for root
Then it fails

9

I don’t know enough about QEMU to debug much further, but if I did have to work on this, then I’d unpack the initrd, add some print/echo statements to say how far into the initrd it ran before hang, and try to narrow it down to the specific line in the transfer/pivot_root which fails.

An initrd is just a compressed cpio tar file. Here are some approximate notes on manually unpacking one and then repacking it:

# Do this in a clean temp directory:
gunzip < initrd > initrd.cpio
# This unpacks in the current directory:
sudo cpio -vid < initrd.cpio

Reverse:
find . -print | cpio -ov > ../initrd.cpio
cd ..
gzip initrd.cpio
mv initrd.cpio initrd

Here’s another thread which mentions this:
https://devtalk.nvidia.com/default/topic/1011027/jetson-tk1/jetson-tx1-initrd/post/5157554/#5157554

Here is a more expanded list of notes on initrd unpack/pack:

sudo -s
cd /tmp
# Need a clean directory you can later delete:
mkdir test
cd test
gunzip < /where/ever/it/is/initrd > initrd.cpio
# This does the actual unpack in current directory:
cpio -vid < initrd.cpio
# You can save or delete initrd.cpio here, I just
# delete (otherwise it gets put in any cpio you
# repackage which is not what you want):
mv initrd.cpio ..
# Explore, edit, modify if desired...then repackage
# with new name:
find . -print | cpio -ov > ../initrd-modified.cpio
cd ..
gzip initrd-modified.cpio
mv initrd-modified.cpio initrd-modified
# This is the old unmodified cpio file:
rm initrd.cpio
# Renamed with "-modified" just to keep it from getting mixed up,
# this is now usable as an INITRD entry.
rm -Rf test
exit

This is an alternate form to create a cpio file and then initrd based on using find to look for a tree of files (this is for creating an initrd entirely from scratch without a prior initrd to edit):

find . | cpio --quiet -H newc -o | gzip -9 -n > ../initrd_new

This is not so much about the edit process, but mentions some Xavier initrd mechanics:
https://forums.developer.nvidia.com/t/how-to-modify-initrd/116873

10

Thanks I’ll try it on Tuesday

11

Not sure How but yesterday it booted without having to do anything and I was able to log in thought the system was very unstable I can’t run sudo and some daemons failed to start (probably permission issues and owner issue) after a while the guest vnc friezes up.

The last thing I did for this image was ```
find ./ -type f -exec sed -i ‘s/Old-Disk-UUID/New-Disk-UUID/g’ {} ;

12

Can you see the permissions of file “/usr/bin/sudo”?
ls -l /usr/bin/sudo

It should have the left half something like this:
-rwsr-xr-x 1 root root

If sudo is refusing due to permissions, then the file system is the wrong type for Linux. In that case, what do you see from:
df -H -T /
(type should normally be ext4)

Note that when you flash a Jetson, that the file system type can effect permissions of the “Linux_for_Tegra/rootfs/” location. If permissions are incorrect there, e.g., if this was an NTFS partition originally, then permissions will fail on the Jetson even if the flash itself was technically correct.

13

sorry for the late response
to fix the issue i ran a for loop to check each file and copy the owner from the original image for the system

doing that reduced the failed services shown at startup but I reached an infinite loop with starting snapd .Sometimes it skips it and i manage to login only for the vnc to freeze

After tryng multiple time the image got corrupted
I no longer can access it it prints an error about the ext4 filesystem type and get stucked

14

It is still necessary to know which filesystem type is (A) at the host PC’s “Linux_for_Tegra/rootfs/” location, and on the NX’s filesystem. Checking file and copying to the other system is by far the hardest way to do this, and it is almost guaranteed to have points of failure. Knowing if the permissions could be correct via having the correct filesystem type is the only sane starting point. Trying to fix such a system, if wrong, is an extraordinary effort, and will be slower than simply flashing it with the correct filesystem type to start with. On the other hand, if this was already the right filesystem type, then it tells us something far different is going wrong.

15

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.