RidgeRun / NVIDIA-Jetson-IMX477-RPIV3

NVIDIA Jetson IMX477 HQ RPI V3 camera driver
124 stars 39 forks source link

Unable to boot via external storage after install. #34

Open developer-ken opened 3 years ago

developer-ken commented 3 years ago

I've been booting my jetson nano b01 (4G version) from an SSD attached to the USB port. That worked perfectly.
How ever, after I installed this patch using the two .deb file and changed my extlinux.conf, everything got broken.
My device insist to boot from /dev/mmcblk0p1, even when the root=/dev/sda1 is set.
Here is an example that wont boot from my usb drive:

TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/initrd
      FDT /boot/tegra210-p3448-0000-p3449-0000-b00.dtb
      APPEND ${cbootargs} quiet root=/dev/sda1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0

I also tried APPEND root=/dev/sda1 ${cbootargs} quiet , even APPEND root=/dev/sda1 ${cbootargs} root=/dev/sda1 quiet, these does nothing.
I am getting really confused. I wonder why a camera driver patch override my bootdevice setting, and how to fix that.

developer-ken commented 3 years ago

I an using nvidia-l4t-kernel_4.9.201-tegra-32.5.0-20210115145440_arm64.deb nvidia-l4t-kernel-dtbs_4.9.201-tegra-32.5.0-20210115145440_arm64.deb two files.
I haveJetpack 4.5.1 [L4T 32.5.1] on my board.

campos-97 commented 3 years ago

Hello @developer-ken.

Is it possible for you to connect the board through UART and share with us the log messages output by the board during boot ? Otherwise, it would be also very helpful if you provide us with the output of running the dmesg command.

developer-ken commented 3 years ago

UART.log Here is my boot log from UART. It says

[    6.862032] Root device found: mmcblk0p1
[   17.018099] ERROR: mmcblk0p1 not found

but I have root=/dev/sda1 set

developer-ken commented 3 years ago

It seems to ingore my boot cmdline and get it from somewhere else? [0003.921] boot image cmdline: root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0

Pretty sure it is different from my setting image

developer-ken commented 3 years ago

Found something interesting on line 415: append: 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=1125 core_edp_ma=4000 gpt earlycon=uart8250,mmio32,0x70006000 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 quiet root=/dev/sda1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 It has two root variables. It seems that ${cbootargs} already has all the settings, and I have no easy way to change this. Just to mention, when I remove the FDT line, the system DO boot correctly. Maybe some feature I dont know that change the boot behavior when using FDT?

developer-ken commented 3 years ago

I tried a workaround, which is NOT working. APPEND 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=1125 core_edp_ma=4000 gpt earlycon=uart8250,mmio32,0x70006000 quiet root=/dev/sda1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0

This does not work. It changes the output in line 415 to the correct setting, but the log after that still uses root=/dev/mmcblk0p1.

My config file is surely loaded, as if I remove the FDT line, everything is fine. But something in the added dtb file is overriding my config.

campos-97 commented 3 years ago

Hello @developer-ken,

I am sorry for the delayed reply, we were arranging a setup to replicate the issues locally.

After getting the Jetson to boot from a USB device and installing the driver with option A, we certainly reached the same error you are facing. However, after some other testing, we believed the error is not caused the new device tree nor the kernel. It seems that just adding the the FDT line into the extlinux.conf file (without even installing the driver using the .deb files) cause the error you are experiencing.

We would then advice you to please try installation method B. We understand is not as convenient as method A, however by generating an Jetpack image with the already updated device tree and kernel you would not need to modify the extlinux.conf file. And you would only need to generate the image once, then you can use it to flash as many devices as you want.

Please let us know if you still face the same issue after following the B option installation procedure. Or if you have any other question or concern. We will be glad to help.