Bad kernel command-line for jetson nano
brgl opened this issue · 6 comments
Hi!
I've been using meta-tegra with a custom distro on Xavier NX for some time with no major issues. We're now verifying the feasibility of downsizing to nano and so I built a regular core-image-minimal with the tegra demo distro for testing and I can't boot it on a brand new nano board - it goes into initramfs shell. The reason for the failure is this: the initramfs tries to mount a non-existent /dev/mmcblk0p because this is what it gets from the kernel command line which looks like this:
Kernel command line: tegraid=21.1.2.0.0 ddr_die=4096M@2048M section=512M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 console=ttyS0,115200n8 debug_uartport=lsport,4 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=0x1000@0xff780000 core_edp_mv=1075 core_edp_ma=4000 gpt tegra_fbmem=0x800000@0x92ca9000 is_hdmi_initialised=1 earlycon=uart8250,mmio32,0x70006000 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 root=/dev/mmcblk0p rw rootwait
I'm not sure where this invalid value comes from and why are there two root= parameters (one's correct). They are not set in KERNEL_ARGS in any way. Here's my build config:
meta = "HEAD:0e7201d43a0af436f450512fe444e3f271b20b24"
meta-tegra
contrib = "HEAD:146ceaa7400cdd92d9aad4f005cd3c6ba84b0e8c"
meta-oe
meta-python
meta-networking
meta-filesystems = "HEAD:11eae114522a6befa06c7f4021a83bc016133543"
meta-virtualization = "HEAD:8be0bc1480e649b2df5f9f8e87e01c5acbe61182"
meta-tegra-support
meta-demo-ci
meta-tegrademo = "dunfell-l4t-r32.5.0:a99d2da668e7ed6df5927501c134301dd5b43ef0"
That's probably coming from the KERNEL_ROOTSPEC setting, which is used to form the APPEND line in /boot/extlinux/extlinux.conf - part of the U-Boot setup that you wouldn't see on the Xavier. By default it sets the root= parameter based on the device number and partition number discovered from locating the extlinux.conf file.
I'm not sure why the partition number is coming out blank in your case, though. I just booted a dunfell-32.5.0 image on one of my Nanos, and it worked fine.
@madisongh Thanks for the hint. Indeed if I do setenv distro_bootpart 1 in u-boot and then boot, the system goes into user-space just fine. I'm trying to figure out why this variable is not defined by default in my u-boot env. I went with an even simpler setup - just poky and meta-tegra on dunfell-l4t-r32.5.0. The issue is still there.
Build Configuration:
BB_VERSION = "1.46.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "aarch64-poky-linux"
MACHINE = "jetson-nano-devkit"
DISTRO = "poky"
DISTRO_VERSION = "3.1.9"
TUNE_FEATURES = "aarch64 armv8a crc"
TARGET_FPU = ""
meta
meta-poky
meta-yocto-bsp = "dunfell:e1960e5d280c8fc19eab0fc63f45926d9fce2434"
meta-tegra = "dunfell-l4t-r32.5.0:146ceaa7400cdd92d9aad4f005cd3c6ba84b0e8c"
Is this a Nano dev kit (with SD card)? If so, did you program the SPI flash on it (./doflash.sh --spi-only)? If not, then the copy of U-Boot on it may not be the right one. Ours has a patch that temporarily sets distro_bootpart in the environment (in the boot script, it's a shell variable) so it can be used this way.
Yep that's it. I thought that since the system boots (unlike Xavier NX without SPI flashing), I don't need it. Closing this now.
Hi,
I think it makes sense to post in this ticket instead of opening a new one. I also have this issue, but I'm lookning for a solution that doesn't involve flashing the SPI chip. Is there anything more that will be an issue without flashing the SPI.
Because for it to make sense, I want to end up with an SD card image in the end, which I can deliver to others that they can use a flashing tool to flash their SD card, drop into their new jetson nano and start up, without needing scripts to flash an SPI flash chip.
Looking at that command line in the original ticket, as well as mine, it ends with:
root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 [...] root=/dev/mmcblk0p rw rootwait
which means root= is specified twice, first correct, second not correct.
I would assume it would be just to remove the second instance to get it working.
Is there anything more that will be an issue without flashing the SPI.
Hard to say for sure, but there could be. For instance, if the boot firmware in the SPI flash is from earlier than L4T R32.5.0, it will expect some of the boot firmware to be in partitions on the SDcard, so you'd get boot failures with the newer rootfs-only SDcard layout.