R28.2 Initrd and Device Tree?

Autonomous Machines Jetson & Embedded Systems Jetson TX1
#1

I’m looking at trying to enable OverlayFS, and I think what it comes down to is that an initrd must be used. However, despite seeing the initrd unpacked, there is no sign that it is used.

One place I see a possible failure at is that CBoot seems to handle something related to initrd before U-Boot takes over. The “chosen” of device tree has in it these two parameters which CBoot merges in:

linux,initrd-end = <0x84100000>;
linux,initrd-start = <0x84100000>;

What seems wrong is that the start and end addresses are both the same address. The default R28.2 has an initrd of 0 bytes in size (it isn’t used), so I am wondering if something passed on by CBoot might be essentially telling U-Boot that any initrd unpacked to a size larger than 0 should be ignored? Have the changes to merge part of boot into stages which are needed prior to U-Boot also changed initrd content to require a device tree edit?

Another possibility is if the kernel itself has been edited to not look for the customary init file locations (I had a custom “/init”, “/sbin/init”, and “/sbin/systemd”…so if it were any of those I should have seen it).

#2

linuxdev,

Let me try and see if we are able to set up initrd.

#3

Hi linuxdev,

Please try to use below command to enable initrd.

sudo ./flash.sh -I bootloader/l4t_initrd.img jetson-tx1 mmcblk0p1
#4

Will this go into a partition? If so, then I am curious about what partition in order to be certain the image will fit that partition.

Is this initrd image actually active by default? In other words, does the default R28.2 (or R28.2.1) use this initrd image? Stated in an alternate way, if I flash the existing “bootloader/l4t_intird.img”, will this be essentially no change?

#5

linuxdev,

To be more precisely, emmc boot does not need it by default.
If adding “-I” in flash, initrd would be used during boot up.

uill-p3489-1000-a00.cfg)... done.
copying pmc_config(/media/waywang/715d5ef2-5ded-4dfb-bc5c-5536922f920c/project/rel-28.2/out/l4t-t186ref-release-aarch64/full_linux_for_tegra/Linux_for_Tegra/bootloader/t186ref/BCT/tegra186-mb1-bct-pad-quill-p3489-1000-a00.cfg)... done.
copying prod_config(/media/waywang/715d5ef2-5ded-4dfb-bc5c-5536922f920c/project/rel-28.2/out/l4t-t186ref-release-aarch64/full_linux_for_tegra/Linux_for_Tegra/bootloader/t186ref/BCT/tegra186-mb1-bct-prod-storm-p3489-1000-a00.cfg)... done.
copying scr_config(/media/waywang/715d5ef2-5ded-4dfb-bc5c-5536922f920c/project/rel-28.2/out/l4t-t186ref-release-aarch64/full_linux_for_tegra/Linux_for_Tegra/bootloader/t186ref/BCT/minimal_scr.cfg)... done.
copying scr_cold_boot_config(/media/waywang/715d5ef2-5ded-4dfb-bc5c-5536922f920c/project/rel-28.2/out/l4t-t186ref-release-aarch64/full_linux_for_tegra/Linux_for_Tegra/bootloader/t186ref/BCT/mobile_scr.cfg)... done.
copying bootrom_config(/media/waywang/715d5ef2-5ded-4dfb-bc5c-5536922f920c/project/rel-28.2/out/l4t-t186ref-release-aarch64/full_linux_for_tegra/Linux_for_Tegra/bootloader/t186ref/BCT/tegra186-mb1-bct-bootrom-quill-p3489-1000-a00.cfg)... done.
copying dev_params(/media/waywang/715d5ef2-5ded-4dfb-bc5c-5536922f920c/project/rel-28.2/out/l4t-t186ref-release-aarch64/full_linux_for_tegra/Linux_for_Tegra/bootloader/t186ref/BCT/emmc.cfg)... done.
Existing bootloader(/media/waywang/715d5ef2-5ded-4dfb-bc5c-5536922f920c/project/rel-28.2/out/l4t-t186ref-release-aarch64/full_linux_for_tegra/Linux_for_Tegra/bootloader/nvtboot_cpu.bin) reused.
copying initrd(/media/waywang/715d5ef2-5ded-4dfb-bc5c-5536922f920c/project/rel-28.2/out/l4t-t186ref-release-aarch64/full_linux_for_tegra/Linux_for_Tegra/bootloader/l4t_initrd.img)... done.
	populating kernel to rootfs... done.
	populating initrd to rootfs... done.
	populating extlinux.conf.emmc to rootfs... done.
	populating /media/waywang/715d5ef2-5ded-4dfb-bc5c-5536922f920c/project/rel-28.2/out/l4t-t186ref-release-aarch64/full_linux_for_tegra/Linux_for_Tegra/kernel/dtb/tegra186-quill-p3489-1000-a00-00-ucm1.dtb to rootfs... done.
done.
Making Boot image... done.

This would directly affect the initrd in /boot

ls rootfs/boot/initrd -al
-rw-r--r-- 1 root root <b>6234666</b>  九  26 15:01 rootfs/boot/initrd
#6

Hi linuxdev,

Does this work?

#7

I’ll be testing this tomorrow! Stay tuned…

#8

Using R28.2, TX1, and a clone as “bootloader/system.img”, with a custom “bootloader/Initrd_test”, this is my command (the clone is from a partition originally flashed with size “-S 14580MiB”):

sudo ./flash.sh -r -S 14580MiB -I bootloader/Initrd_test jetson-tx1 mmcblk0p1

This sort of looks like it worked. My actual initrd size was 9,953,407 bytes. The device tree indicates stop/start addresses of:

linux,initrd-start = <0x0 0x83200000>;
linux,initrd-end = <0x0 0x83b7e1a1>;

…a span of 9,953,698 bytes (0x83b7e1a1 - 0x83200000 + 1).

On the other hand, my init was never executed. I had it simplified to basically say “BINGO” and drop into a shell. What I got was this as the entire life of the initrd:

[    0.447489] Trying to unpack rootfs image as initramfs...
[    0.449722] rootfs image is not initramfs (no cpio magic); looks like an initrd
[    0.469707] Freeing initrd memory: 9720K (ffffffc003200000 - ffffffc003b7e000)

So it found and unpacked the initrd, then threw it away. My initrd was designed to catch any hooks into “/init”, “/sbin/init”, and “/sbin/systemd”. Any attempt to use any of those should have resulted in some sort of evidence of my custom scripts (even a failure would be good, but boot was a match for not having an initrd…other than seeing it unpack and have a size greater than zero).

Is there some customization of init or systemd or the kernel which might cause the initrd to be ignored even though it is found and unpacked?

#9

linuxdev,

If you are not using the cpio commands (from the messages it appears so), it should read from /initrd.image and execute.

However, we cannot know much info from current log. Could you add some log in your init?

#10

The basic method I use to unpack an existing initrd is to do this in a clean directory:

gunzip < initrd > initrd.cpio
sudo cpio -vid < initrd.cpio

To reverse this:

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

In my case I unpacked the R27.1 initrd, unpacked it, replaced anything binary with the R28.2 version or my version (e.g., the kernel, the modules, firmware, libs), and then edited to create my own “/init”, “/sbin/init”, and “/sbin/systemd”…the hard link version was “/init”, the other “init” and “systemd” were symbolic links to my “init”. My “init” was the same as the R27.1 version, except that it always uses “/bin/bash” as the final program.

There may indeed be something missing, I’m not sure how to interpret the cpio magic comments. The three lines of log are everything…nothing before or after those log lines has any implication that I can see. I’ll attach a log.

From what I know (which might be wrong or incomplete) the “initramfs” comment is trying to detect an older style predecessor to the current initrd style file system. The “is not initramfs” (so far as I know) is simply saying the detected initrd is as it should be on newer systems.
log_initrd_boot.txt (88.1 KB)

#11

Somehow I cannot open your log file…

#12

Kwrite/gedit/nedit/kate/codeblocks/gVim/geany should work in Linux, or Wordpad/CodeBlocks in Windows (Notepad can’t handle it).

I think the problem is that boot has a couple of garbage binary characters near the start of boot, and the application you are using to read it will complain that there are some non-valid characters not part of UTF-8. The simpler text editors will just refuse to work with this, the ones more useful in code editing will simply warn about it or load without complaint and show some icon for non-printable characters.

#13

linuxdev,

Thanks. I can read the log now.

Not sure what is going on. What is the content in your init? Could you share how you set it up?

#14

I have tested several, here is one which simply adds “BINGO” to an already existing echo statement so I can search for it in logs. I have never found any indication that init was ever run from the initrd. I’ll do some more variations tomorrow (completely gutting everything except going into “/bin/bash”…I had tested something simlar to this as well though). Search for “BINGO” for this case to see what I was looking for…but nothing was printed at all.
init.txt (5.03 KB)

#15

linuxdev,

Where did you put this init.txt?

#16

It was really named “init” (".txt" is just so the forum lets me attach it). I had a hard copy at “/init”. Symbolic links at “/sbin/init” and “/sbin/systemd”. All three locations were the same file.

#17

Does your init file have permission +x?
If your initrd is copied from rel-27.1, is this initrd able to run /sbin/init on rel-27.1?

#18

It is readable and executable by user (root), group (root), and other. The initrd is originally from a running R27.1 system. The files in libraries and binaries are from R28.2. Normally the first thing which should occur in reading an initrd would be executing “init”, and so even if there is a problem with missing libraries or other support infrastructure (other than “/bin/bash”), I should at least see the echo statements…or some indicator that init was called. The most bare bones init might contain only “/bin/bash” (statically linked) and “/init” naming its whole content as running “/bin/bash” (basically this would be a rescue mode if init only runs bash).

All experimentation shows 100% success at getting the initrd unpacked, but has never had any indication that it tried to run init or systemd from the initrd…it simply ignores initrd’s content and moves on to the non-initrd without ever using a pivot_root.

#19

Hi linuxdev,

Please try to change this kernel cmd in p2371-2180-devkit.conf

CMDLINE_ADD=“console=ttyS0,115200n8 console=tty0 OS=l4t fbcon=map:0 net.ifnames=0”;
-TO-
CMDLINE_ADD=“console=ttyS0,115200n8 console=ttyS0 OS=l4t fbcon=map:0 net.ifnames=0”;

We can see below log after change the output to debug console.

[ 01:08:30 ] Rootfs mounted over mmcblk0p1
---
---
[ 01:08:30 ] Switching from initrd to actual rootfs
#20

Unfortunately I was still unable to see execution of a very cut down initrd intended to drop into bash instead of doing a chroot. This would have been left without even mounting rootfs other than the initrd, but boot continues on into GUI (which doesn’t even exist on the initrd).