I have a problem that I can’t get into uboot. Pressing Enter can’t get into uboot
I sudo./flash.sh jetson-nano-qspi-sd mmcblk0p1 when brushing the machine /home/zzy/Desktop/Linux_for_Tegra1/rootfs/boot/extlinux/extlinux.conf is not found, exiting.If there is no extlinux.conf, I created an empty extlinux.conf, and after brushing the machine successfully, I can see this through the debugging serial port
missing environment variable: pxeuuid
Retrieving file: /boot/extlinux/pxelinux.cfg/01-48-b0-2d-5c-30-34
*** ERROR: `serverip' not set
Retrieving file: /boot/extlinux/pxelinux.cfg/00000000
*** ERROR: `serverip' not set
Retrieving file: /boot/extlinux/pxelinux.cfg/0000000
*** ERROR: `serverip' not set
Retrieving file: /boot/extlinux/pxelinux.cfg/000000
*** ERROR: `serverip' not set
Retrieving file: /boot/extlinux/pxelinux.cfg/00000
*** ERROR: `serverip' not set
Retrieving file: /boot/extlinux/pxelinux.cfg/0000
*** ERROR: `serverip' not set
Retrieving file: /boot/extlinux/pxelinux.cfg/000
*** ERROR: `serverip' not set
Retrieving file: /boot/extlinux/pxelinux.cfg/00
*** ERROR: `serverip' not set
Retrieving file: /boot/extlinux/pxelinux.cfg/0
*** ERROR: `serverip' not set
Retrieving file: /boot/extlinux/pxelinux.cfg/default-arm-tegra210-p3450-0000
*** ERROR: `serverip' not set
Retrieving file: /boot/extlinux/pxelinux.cfg/default-arm-tegra210
*** ERROR: `serverip' not set
Retrieving file: /boot/extlinux/pxelinux.cfg/default-arm
*** ERROR: `serverip' not set
Retrieving file: /boot/extlinux/pxelinux.cfg/default
Anyway, press Enter all the time to enter the uboot, and through the debugging serial port of the terminal I keyboard input anything can not be displayed, not clear why
I want to mention that it is now CBoot, emulating UBoot, but the functionality should be the same (or a compatible subset). The only way to reach that is with serial console. Your video uses an odd CODEC so I can’t see it, but you’d want to use any key other than the return/enter key. What happens is that in a very short time span any key will drop to a console; if you do this too soon, it is the environment’s console, and in that case, you’d have to enter the command “boot” to continue…then another fast key stroke right after that enters the kernel selection. When in the kernel selection, if you hit the enter key again, then you are probably just telling it to continue booting with the default kernel. By using something like the escape key repeatedly, you can be sure that it won’t continue booting.
Are you using the serial console? If so, don’t be afraid to rapidly hit the escape key (about every half second). If you see a kernel list, you’ve then passed the stage you are interested in. Otherwise the “help” command will verify you are there. If you want to post a video though, perhaps you have a different CODEC or means of making that video (not sure what software you used, firefox doesn’t like it).
这不是编码器的问题，可能是我usb扩展的问题，但是我上电的时候快速按回车键就是进入不到u-boot，这是新刷的机，甚至usb配置都进入不了，不能进入u-boot会导致我后面很多工作做不了
希望前辈看看有没有类似的人出现这样错误帖子，我刷机的时候说没有/home/zzy/Desktop/Linux_for_Tegra1/rootfs/boot/extlinux/extlinux.conf is not found, exiting，这是源码问题，还是什么
Some additional information, not an answer: During normal flash a purely Ubuntu “sample root filesystem” is a starting point for the image to be flashed. The “apply_binaries.sh” script (run with sudo) is what adds the NVIDIA drivers (this is done only once). Part of that content includes the extlinux.conf file. If it is missing, then you know one of these are true:
apply_binaries.sh was not run.
The filesystem cannot be read.
The filesystem cannot be found.
The pre-built SD card images all had the apply_binaries.sh step done by someone else. Using JetPack/SDK Manager to create images also makes sure this is done for you. Various command line tools usually require the end user to “sudo ./apply_binaries.sh” once.
Also, during boot, unless USB device drivers are present, you won’t find any USB device. Serial console for one is not USB, at least not at the Jetson side; the host PC would need USB if the host PC uses a USB serial UART. Escaping to the U-Boot console (CBoot) is not from a USB keyboard unless that keyboard is on the host PC while running a serial console. USB storage and USB keyboards, if directly attached to the Jetson, probably won’t help during boot unless some special setup has been used.
I saw “APX” in the lsusb listing. This means you are probably using a VM. I expect VMs to fail because unless USB is set up correctly, the USB will fail to reconnect after a disconnect (which happens during normal flash).
That I don’t know how to answer. I will say though that any USB issue means you won’t get a chance to find out if you compiled only part. Also, it could very easily be all of the content is good, but the network setup for PXE is wrong. Anything which can’t find the content will look about the same.
If networking is set up by the time of the boot prompt, then you should be able to ping the host. That would give you some minimal knowledge that networking is there (it wouldn’t tell you if kernel and other parts are correct).
The VM suggested by the APX tells me USB is likely the start of problems.
You don’t need to do anything special with the flash software itself. How did you set up before flashing (from the host PC side)?
Usually, if on command line, you would do this from the host PC:
Download and unpack the “driver package” as a regular user.
Go to “Linux_for_Tegra/rootfs/” (provided by unpacking the “driver package”), and unpack the “sample root filesystem” using “sudo”.
Go back to “Linux_for_Tegra/”, and then running “sudo ./apply_binaries.sh”.
Now you are ready for any command line flash.
Any modifications should take place after that and before flash.
Note that the release version of the driver package and sample rootfs must be a version which is compatible with the SD card you use (I assume this is a dev kit; if it is instead a module plus third party carrier board, then you need to add that information which changes things). After first boot account setup is completed, you should then be able to interrupt boot via serial console. Don’t expect to interrupt boot with a USB keyboard directly on the Jetson. I typically just “spam” the escape key until it interrupts. Technically, the enter key would also do this, but there are times when the enter key will also cause continuation. The space bar is also a good key to spam in serial console. Any failure to report needs a full serial console boot log.
Logs in the other URL only occur after Linux loads, so there isn’t much one can examine. We know it fails to find everything needed in boot, but I don’t have any means to narrow it down. You really need that serial console. It might be possible to debug the configuration with a dev kit carrier board, and then transfer to the other carrier board.
