Maybe there is a BUG about initrd in JetPack 3.1

I have some work to do in initrd, but maybe there is a bug.

Firstly,in Jetpack 3.1,the flash.sh did’t copy l4t_initrd.img file to be initrd, because these code.

line 700: if [[ “{target_rootdev}" == mmcblk0p* || "{target_rootdev}” == ${BOOTDEV} ]]; then
line 701: rootdev_type=“internal”;
line 702: INITRD="";

delele line 702;then initrd worked.

Then, I found that there is no print message of initrd in serial interface, but other message is normal.
The boot command line append by uboot has some vectors like “console=ttyS0,115200n8 console=tty0” in Jetpack 3.1
,which is different with “console=tty0 console=ttyS0,115200n8” in Jetpack 2.3.1.
If I change boot command line to “console=tty0 console=ttyS0,115200n8” in /boot/extlinux/extlinux.conf, The initrd message can be printed in serial interface.

Anybody can help me to confirm above message?

I’m using the driver package + sample rootfs, not JetPack, but I noticed that after the flash the “/boot/initrd” is zero bytes. The TX2 does not have an INITRD key/value pair in extlinux.conf, but the TX1 does, so I’m wondering if this is leftover baggage from the R27.1 release. Could someone check if R28.1 was intended to use an initrd? Or if perhaps this zero byte file under driver package+sample rootfs differs from what JetPack 3.1 might use? If there is a difference, which is correct…to use initrd, or to not use initrd?

Hi linuxdev:

I’m using R28.1 in TX1, which have an INITRD key/value pair in extlinux.conf, and the “/boot/initrd” is zero bytes.
This problem caused by the line 702 in flash.sh:

line 702: INITRD="";

this code does not appear in flash.sh in jetpack 2.3.1.

 Thank you!

I think this is just initializing the INITRD variable in the script. If rootdev_type is internal it may not be that an INITRD is wanted (by definition, an external initrd). I don’t know for certain though if this is correct behavior for avoiding an external initrd, someone would have to verify this. Still, an actual “/boot/initrd” which is size 0 and specified in extlinux.conf is odd…I would think the INITRD key/value pair would simply be removed, versus including the initrd with no content (a zero-length initrd file invites a cpio error).

Hi linuxdev:

The zero byte INITRD is not a big problem for me now.
I’m wondering what’s different between “console=tty0 console=ttyS0,115200n8” and “console=ttyS0,115200n8 console=tty0” in extlinux.conf.
In R28.1 , the extlinux.conf is like this:
TIMEOUT 30
DEFAULT primary

MENU TITLE p2371-2180 eMMC boot options

LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait

you can instead the APPEND by these words:

APPEND fbcon=map:0 console=tty0 console=ttyS0,115200n8 …

just like the earlier version of rootfs.

You will find the INITRD boot message printed by serial interface(ttyS0):

[ 00:00:01 ] L4T initrd starts from here…

If you use “console=ttyS0,115200n8 console=tty0” ,there is no INITRD boot message,although the INITRD worked.

thanks!

The kernel argument for console allows multiple listings. Order of listing should not matter. The “tty0” is just the local console, the “ttyS1,115200n8” is the serial console (and it has serial UART settings).

The INITRD line should probably be removed unless you’ve created your own initrd.

I’m not sure how fbconmap works with serial consoles. So far as I’ve seen only the local console is used for mapping. The “fbcon=map:0” should send boot messages to the first local tty (actually, to the first fb driver…I don’t think a serial UART counts in that, but I could be wrong). FYI, that argument is already there due to passing on from U-Boot (see “cat /proc/cmdline” after boot without manually adding this…this seems to be in the content of “${cbootargs}”.

Note that there is an initrd message during U-Boot stage which is not the “/boot/initrd”. The initrd message after kernel choice has been decided, but prior to kernel loading, is the initrd from “/boot/initrd”. Mine says:

Enter choice: 1:        primary kernel
Retrieving file: /boot/initrd
<b>0 bytes read</b> in 46 ms (0 Bytes/s)
Retrieving file: /boot/Image
20984368 bytes read in 528 ms (37.9 MiB/s)

Note that the “20984368 bytes read” is the kernel Image, not the initrd. All initrd has been loaded prior to the moment kernel read starts.

Whatever changes you wanted to make in the initrd, it sounds like those changes worked. I am curious if you had the need to add a module prior to boot starting (e.g., if ext2/4 drivers were in module format, then the initrd would need to have those modules before the kernel runs)?