External boot drive cannot be updated

When I press the recovery and reset button, the system reboot again and stuck in startup processing again.

Hi,

As I already said, if we don’t have UART log, debugging is just like telepathy, and something like the system reboot again and stuck in startup processing again. does not help AT ALL.

I will try it later on but I just didn’t know what the SATA drive or external drive has to do with the boot drive(eMMC)? I guess the problem is probably with the L4T folder in the SATA drive. After reformatting the drive, it was gone.

After flashing/updating the system, the eMMC became boot drive again and there were 2 L4T folders appeared, one on the desktop(eMMC), the other on the sidebar(SATA drive). After cloning/copying the eMMC to the SATA, the latter’s LT4 folder was still existed. I think this L4T folder is somewhat critical to the booting processing.

A serial console boot log actually answers that question of “I just didn’t know what the SATA drive or external drive has to do with the boot drive(eMMC)?”. The serial console boot log essentially says what boot is thinking at every step of boot (you can’t get that from dmesg since dmesg does not exist during boot). There are various “pointers” during boot which might be picking eMMC or SATA, but which normally live on eMMC…unless it is chain loading to something else. The serial console log answers what it is trying to do.

1 Like

Here is the log.

SoC: tegra186

Model: NVIDIA P2771-0000-500
Board: NVIDIA P2771-0000
DRAM: 7.8 GiB
MMC: sdhci@3400000: 1, sdhci@3460000
Loading Environment from MMC… *** Wing - bad CRC, using default environment

In: serial
Out: serial
Err: serial
Net:
Warning: ethernet@2490000 using MAC aess from ROM
eth0: ethernet@2490000
Hit any key to stop autoboot: 0
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1…
maximum number of regions parsed, aboing
starting USB…
No working controllers found
USB is stopped. Please issue 'usb sta first.

Device 0: unknown device
starting USB…
No working controllers found
ethernet@2490000 Waiting for PHY autogotiation to complete… TIMEOUT !
phy_startup() failed: -110FAILED: -11ssing environment variable: pxeuuid
missing environment variable: bootfil
Retrieving file: pxelinux.cfg/01-00-0-8c-53-b0
ethernet@2490000 Waiting for PHY autogotiation to complete… TIMEOUT !
phy_startup() failed: -110FAILED: -11ssing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
ethernet@2490000 Waiting for PHY autogotiation to complete… TIMEOUT !
phy_startup() failed: -110FAILED: -11ssing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
ethernet@2490000 Waiting for PHY autogotiation to complete… TIMEOUT !
phy_startup() failed: -110FAILED: -11ssing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
ethernet@2490000 Waiting for PHY autogotiation to complete… TIMEOUT !
phy_startup() failed: -110FAILED: -11sing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
ethernet@2490000 Waiting for PHY auto negotiation to complete… TIMEOU!
phy_startup() failed: -110FAILED: -110missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
ethernet@2490000 Waiting for PHY autogotiation to complete… TIMEOUT !
phy_startup() failed: -110FAILED: -11ssing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
ethernet@2490000 Waiting for PHY autogotiation to complete… TIMEOUT !
phy_startup() failed: -110FAILED: -11ssing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
ethernet@2490000 Waiting for PHY autogotiation to complete… TIMEOUT !
phy_startup() failed: -110FAILED: -11sing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
ethernet@2490000 Waiting for PHY autoegotiation to complete… TIMEOUT !
phy_startup() failed: -110FAILED: -11ssing environment variable: bootfile
Retrieving file: pxelinux.cfg/defaultm-tegra186-p2771-0000
ethernet@2490000 Waiting for PHY autogotiation to complete… TIMEOUT !
phy_startup() failed: -110FAILED: -11ssing environment variable: bootfile
Retrieving file: pxelinux.cfg/defaultm-tegra186
ethernet@2490000 Waiting for PHY autogotiation to complete… TIMEOUT !
phy_startup() failed: -110FAILED: -11ssing environment variable: bootfile
Retrieving file: pxelinux.cfg/defaultm
ethernet@2490000 Waiting for PHY autogotiation to complete… TIMEOUT !
phy_startup() failed: -110FAILED: -11sing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
ethernet@2490000 Waiting for PHY autootiation to complete… TIMEOUT !
phy_startup() failed: -110FAILED: -11nfig file not found
starting USB…
No working controllers found
ethernet@2490000 Waiting for PHY auto negotiation to complete… TIMEOU!
phy_startup() failed: -110FAILED: -11ethernet@2490000 Waiting for PHY auto ne!
phy_startup() failed: -110FAILED: -11gra186 (P2771-0000-500) #
Tegra186 (P2771-0000-500) #
Tegra186 (P2771-0000-500) #

Any suggestions?

If it cannot be fixed, how do I flash the eMMC(factory reset) to its original status?

Hi,

can you make some update on your current situation?
Basically you have three things to do:

  1. Flash the internal eMMC
  2. Copy rootfs on the eMMC to your external drive
  3. Add a new entry pointing to your external drive in /boot/extlinux/extlinux.conf on both devices.

Which step did you fail?

Actually I totally have no idea what you are saying here.

I tried it twice but failed(TX2 cannot be detected).

Since it fails to startup, there is no way to copy the eMMC.

No way since it cannot bootup.

After reformatting the SATA drive, the system fail to startup.

Then please put flashing log and UART log here.
I don’t see any of them.

I don’t know. Systems on eMMC should have nothing to do with your SATA drive.
Can you please first forget about the SATA drive, and focus on getting it to work on eMMC?

I changed the boot drive from eMMC to SATA drive and it worked(a L4T folder in the drive). However, after updating the system to 4.6.4, the eMMC became boot drive again. There were 2 L4T folders appeared, one on the desktop(associated with boot drive), another on the sidebar(associated with SATA).

I tried to make the SATA to be boot drive again but failed. Then I cleaned(reformatted) the drive and tried it all over again. But after reformatting the drive, the system stuck in the booting processing. No matter the SATA drive attached or not, the outcome remains the same.

I know it is very hard to be understood. Probably no one has encountered this problem before.

Again, we need log here, or debugging with such limited information is just like telepathy.

I don’t think there is something called L4T folder, or are you referring to the rootfs?

How did you do that? with extlinux.conf?

Since the system fails to startup, the boot logs could not be generated.

The L4T folder contains a few short documents regarding the system. I did not see any system files in this folder.

I replaced “root=dev/mmcblk0p1” with “root=dev/sda1”(The same as last time which it worked).

Try to use this method to dump the log. UART log as this page can dump at any situation. That is what we need.

The L4T folder contains a few short documents regarding the system. I did not see any system files in this folder.

This sounds just a unclear description. How about just share a screenshot of what you saw?

The folder probably named “L4T Readme”. I wasn’t aware of the name.

That thing has nothing to do with this issue. It is just related to usb device mode and your issue has nothing to do with usb device mode.
Please just focus on dumping the log from uart .

There must be a system file or kernel in the SATA and the system keeps trying to locate that file before going to next step.

Can I copy the L4T files from the host computer to the SATA?

I cannot answer, but this might be useful…

Jetsons do not have a BIOS. The functions are instead in partitions. This does mean that you do not get the same ability to boot to different devices simply by plugging them in and selecting them. The flash itself essentially installs a “pointer” to where to start. To some extent some environment can be set up to offer picking boot behavior within the boot environment, but the pointer itself has to remain in the eMMC.

Normally the boot points to the extlinux.conf setup of the eMMC rootfs partition. Sometimes it can be set to “chain load” to an external device, but otherwise an initrd is used (an initial ramdisk is a miniature rootfs entirely in RAM whose purpose is load an environment capable of using the next device, and then transferring to that next device, e.g., a SATA drive if normally using eMMC…not the same as chain loading, but they both get there).

eMMC models, since they have eMMC partitions for different pseudo-BIOS and bootloader content, have any initrd setup during flash (if using that).

eMMC models also have a partition for kernel and device tree. eMMC models also look at “/boot/extlinux/extlinux.conf” of the rootfs, and if a kernel is named or a device tree is named as a file, then those are used as a higher priority than what is in the partitions. The exception is that if security fuses are burned, then only the partition content will be allowed.

Note that, other than for rootfs, all partitions are signed. The default is to sign with a NULL key, but they are still signed. No partition content (other than rootfs) is allowed if the signature is wrong. If the security fuses were burned, then the key must match those fuses (which is when files in “/boot” for device tree and kernel are no longer available).

If you have an eMMC rootfs partition, then you can clone this to a file. That file is essentially a bit-for-bit exact copy of the partition. You could use a tool like dd (or there are other options) to place that image on another drive. You can also loopback mount that image and edit it, e.g., you could edit the extlinux.conf file if you so desire. That image can be used:

  • As the rootfs during a normal flash.
  • To examine and edit via loopback.
  • To create a matching partition on other media, e.g., SATA.

Do note that there is a likelihood though that some edits are still needed when you copy a partition. Remember that some boot parameters are in the extlinux.conf of the eMMC. You might, as an example when chain loading, need to edit one or both of the extlinux.conf on eMMC and/or SATA.

1 Like

Try to dump the log first. It is just wasting time to keep such communication without providing log

For example, you are just like talking about “there is a bug”, “cannot boot”, “cannot flash”, “how can I do with SATA?”, “I saw a L4T folders”.

This communication is pointless. For example, “L4T folders” turns out just irrelevant info.
If you are not some kind of experts of jetson, then follow the suggestion from NV moderators first.

I know it is very hard to be understood. Probably no one has encountered this problem before.

No, the hard part is you don’t dump the log. Boot issue is quite common here and our side encounters various of boot issue everyday…

If you have problem in flashing with sdkamnager, then that is something we want to check. But not something about SATA. Deal with what we want to check first and your issue would be easier to get fix later.

Flashing the eMMC with sdkmanager is not a problem if the system can startup normally otherwise I don’t know how to make it.

Anyway, I will try to fix it with serial console again.