/boot/extlinux/pxelinux.cfg fail



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).

希望前辈看看有没有类似的人出现这样错误帖子,我刷机的时候说没有/home/zzy/Desktop/Linux_for_Tegra1/rootfs/boot/extlinux/extlinux.conf is not found, exiting,这是源码问题,还是什么

希望前辈看看有没有类似的人出现这样错误帖子,我刷机的时候说没有/home/zzy/Desktop/Linux_for_Tegra1/rootfs/boot/extlinux/extlinux.conf is not found, exiting ,这是源码问题,还是什么

這代表你當初準備BSP的步驟有漏… 比方說apply_binaries.sh沒有跑…


→ Step 1: Set Up the Root File System

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.


 byte copied, 0.00016538 s, 6.0 kB/s
assign_string: crc-flash.xml.bin PTHD 65528 4
echo PTHD | dd of=crc-flash.xml.bin bs=1 seek=65528 count=4 conv=notrunc
4+0 records in
4+0 records out
4 bytes copied, 0.000211487 s, 18.9 kB/s
*** Flashing target device started. ***
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
[   1.1842 ] tegrasign --getmode mode.txt --key None
[   1.8457 ] Assuming zero filled SBK key
[   2.6506 ] 
[   2.6507 ] Generating RCM messages
[   3.2501 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 0 --download rcm nvtboot_recovery.bin 0 0
[   3.3884 ] RCM 0 is saved as rcm_0.rcm
[   4.4093 ] RCM 1 is saved as rcm_1.rcm
[   4.4095 ] List of rcm files are saved in rcm_list.xml
[   5.1062 ] 
[   5.1063 ] Signing RCM messages
[   5.1084 ] tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.key
[   5.6160 ] Assuming zero filled SBK key
[   5.6213 ] 
[   5.6214 ] Copying signature to RCM mesages
[   6.3357 ] tegrarcm --chip 0x21 0 --updatesig rcm_list_signed.xml
[   6.6866 ] 
[   6.6867 ] Parsing partition layout
[   7.6314 ] tegraparser --pt flash.xml.tmp
[   8.3070 ] 
[   8.3071 ] Using default ramcode: 0
[   8.3072 ] Disable BPMP dtb trim, using default dtb
[   8.3072 ] 
[   8.3072 ] Creating list of images to be signed
[   8.3096 ] tegrahost --chip 0x21 0 --partitionlayout flash.xml.bin --list images_list.xml
[   9.1860 ] 
[   9.1860 ] Generating signatures
[   9.4010 ] tegrasign --key None --list images_list.xml --pubkeyhash pub_key.key
[   9.6960 ] Assuming zero filled SBK key
[  10.8324 ] 
[  10.8325 ] Generating br-bct
[  10.8703 ] tegrabct --bct P3448_A00_lpddr4_204Mhz_P987.cfg --chip 0x21 0
[  11.8797 ] 
[  11.8798 ] Updating boot device parameters
[  12.1503 ] tegrabct --bct P3448_A00_lpddr4_204Mhz_P987.bct --chip 0x21 0 --updatedevparam flash.xml.bin
[  12.1511 ] Warning: No sdram params
[  12.1517 ] 
[  12.1517 ] Updating bl info
[  12.4184 ] tegrabct --bct P3448_A00_lpddr4_204Mhz_P987.bct --chip 0x21 0 --updateblinfo flash.xml.bin --updatesig images_list_signed.xml
[  12.4210 ] 
[  12.4210 ] Updating secondary storage information into bct
[  12.6954 ] tegraparser --pt flash.xml.bin --chip 0x21 0 --updatecustinfo P3448_A00_lpddr4_204Mhz_P987.bct
[  12.9465 ] 
[  12.9465 ] Updating Odmdata
[  13.1875 ] tegrabct --bct P3448_A00_lpddr4_204Mhz_P987.bct --chip 0x21 0 --updatefields Odmdata =0xa4000
[  13.3066 ] Warning: No sdram params
[  13.4031 ] 
[  13.4032 ] Get Signed section of bct
[  13.4059 ] tegrabct --bct P3448_A00_lpddr4_204Mhz_P987.bct --chip 0x21 0 --listbct bct_list.xml
[  13.4993 ] 
[  13.4994 ] Signing BCT
[  13.9546 ] tegrasign --key None --list bct_list.xml --pubkeyhash pub_key.key
[  14.3181 ] Assuming zero filled SBK key
[  14.4391 ] 
[  14.4392 ] Updating BCT with signature
[  15.0887 ] tegrabct --bct P3448_A00_lpddr4_204Mhz_P987.bct --chip 0x21 0 --updatesig bct_list_signed.xml
[  15.0898 ] 
[  15.0898 ] Copying signatures
[  15.3998 ] tegrahost --chip 0x21 0 --partitionlayout flash.xml.bin --updatesig images_list_signed.xml
[  16.5874 ] 
[  16.5875 ] Updating BFS information on BCT
[  16.7531 ] tegrabct --bct P3448_A00_lpddr4_204Mhz_P987.bct --chip 0x21 0 --updatebfsinfo flash.xml.bin
[  16.7547 ] 
[  16.7548 ] Boot Rom communication
[  16.8338 ] tegrarcm --chip 0x21 0 --rcm rcm_list_signed.xml
[  16.8345 ] BootRom is not running
[  22.4482 ] 
[  22.4482 ] Sending BCTs
[  22.4502 ] tegrarcm --download bct P3448_A00_lpddr4_204Mhz_P987.bct
[  22.5777 ] Applet is not running on device. Continue with Bootloader
[  25.9123 ] 
[  26.0053 ] tegrahost --chip 0x21 --align cboot.bin
[  26.1835 ] 
[  26.4049 ] tegrahost --magicid EBT --appendsigheader cboot.bin cboot.bin_blheader
[  26.9216 ] 
[  27.7464 ] tegrasign --key None --list cboot.bin_list.xml
[  27.7470 ] Assuming zero filled SBK key
[  27.7607 ] 
[  27.7634 ] tegrahost --updatesigheader cboot.bin_blheader.encrypt cboot.bin_blheader.hash zerosbk
[  27.8478 ] 
[  28.2195 ] tegrahost --chip 0x21 --align tegra210-p3448-0000-p3449-0000-b00.dtb
[  28.6385 ] 
[  28.8753 ] tegrahost --magicid DTB --appendsigheader tegra210-p3448-0000-p3449-0000-b00.dtb tegra210-p3448-0000-p3449-0000-b00.dtb_blheader
[  29.1198 ] 
[  29.7100 ] tegrasign --key None --list tegra210-p3448-0000-p3449-0000-b00.dtb_list.xml
[  29.7110 ] Assuming zero filled SBK key
[  29.7184 ] 
[  29.7214 ] tegrahost --updatesigheader tegra210-p3448-0000-p3449-0000-b00.dtb_blheader.encrypt tegra210-p3448-0000-p3449-0000-b00.dtb_blheader.hash zerosbk
[  29.7416 ] 
[  29.7421 ] Sending bootloader and pre-requisite binaries
[  29.9621 ] tegrarcm --download ebt cboot.bin.encrypt 0 0 --download rp1 tegra210-p3448-0000-p3449-0000-b00.dtb.encrypt 0

I consulted the official manual, but it’s stuck in the cboot. I don’t know why

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).

I will try again today, is it possible that I only compiled the kernel but I did not compile the u-boot

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.

head,Check out my post

head,check out my post

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:

  1. Download and unpack the “driver package” as a regular user.
  2. Go to “Linux_for_Tegra/rootfs/” (provided by unpacking the “driver package”), and unpack the “sample root filesystem” using “sudo”.
  3. Go back to “Linux_for_Tegra/”, and then running “sudo ./apply_binaries.sh”.
  4. Now you are ready for any command line flash.
  5. 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.

My serial port is broken

Without the serial port there is no way for a Nano to drop into a boot console.


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.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.