Jetson TX2 will not boot fully after I flashed it

Hello, the Jetson TX2 is stuck on booting up. it has the error message:

sdhci-tegra 3440000.sdhci: could not set regulator OCR (-1)
vdd-1v8: voltage operation not allowed
sdhci-tegra 3440000.sdhci: could not set regulator OCR (-1)
vdd-1v8: voltage operation not allowed
sdhci-tegra 3440000.sdhci: could not set regulator OCR (-1)
vdd-1v8: voltage operation not allowed
sdhci-tegra 3440000.sdhci: could not set regulator OCR (-1)
vdd-1v8: voltage operation not allowed
sdhci-tegra 3440000.sdhci: could not set regulator OCR (-1)
vdd-1v8: voltage operation not allowed
sdhci-tegra 3440000.sdhci: could not set regulator OCR (-1)
vdd-1v8: voltage operation not allowed
sdhci-tegra 3440000.sdhci: could not set regulator OCR (-1)

I am not sure what I can do to fix this issue. I can do ctr+alt+F2 but I do not know how to fix it and what to type. Please help.

Which release did you flash with, e.g., JetPack4.3? Can you provide a full boot log via serial console? See this for serial console:
http://www.jetsonhacks.com/2017/03/24/serial-console-nvidia-jetson-tx2/

What is connected to the system, and does video have any kind of adapter? Is this a development kit or some other carrier board?

@linuxdev

I flashed it with JetPack4.3. As of right now I do not have the proper tools to obtain the full boot log but I am going to work on that.

The things that are connected are the monitor, keyboard, and mouse. There is an HDMI to DVI adapter since the monitor we are using only has DVI. Lastly, this is the NVIDIA Jetson TX2 Development Kit.

VGA literally cuts a wire for automatic configuration, the DDC wire (which provides EDID data). This will always fail unless you get lucky with a fallback mode. DVI to HDMI might work, but only for cases where EDID is passed through (analog DVI does not pass through EDID and is essentially just a different connector for VGA). In this case the system would boot, but video would fail (and perhaps look like a failed boot). Do you have a true HDMI monitor you can attach during the flash?

@linuxdev

I attached attached the Jeston TX2 to a HDMI to HDMI to a monitor. The same error does apply, however, as if nothing has changed.

When you say flash, does that mean you would like me to flash it again?

If during the previous flash the HDMI monitor was not attached, then you should probably flash it again (with the purely HDMI monitor available during the flash). There are some differences in flash behavior between a flash with HDMI versus a flash without HDMI. This is especially important on first boot after the TX2 has had its flash completed (the first boot is automatic, and this is where/when the admin account creation should occur).

Okay I will try this, I thought it would not matter since the Jetson should be in Force Recovery Mode? I guess I am wrong in assuming this?

The flash software knows if the monitor is connected or not, and then makes adjustments to the flashed software. This was not true in earlier releases, but currently there may be assumptions about wanting headless versus GUI configuration during a flash.

This sounds like a real trap. Is there any reason that the Linux image cannot determine at runtime whether or not an HDMI monitor is attached?

Are there other peripherals such as USB devices which must also be attached at time of flashing, and cannot be attached later?

Can you name other distributions for which you must have an HDMI monitor plugged in at time of installation, or else the image fails to boot later when an HDMI is plugged in?

If flashing for a GUI environment, then make sure you have HDMI attached. Technically you wouldn’t need the USB keyboard, but since there is a first boot account creation the reality is that this too should be connected. There are no other special requirements so far as SDKM picking what to install.

HDMI is hot plug, but consider that some people intend to run headless, and thus to not even install the GUI software (often motivated by the reduction in image size and reduced boot time when GUI software is removed). In the past it was up to individuals to add/remove packages after install to achieve headless operation (the only install was with GUI and no probing/guessing for GUI configuration existed during the flash). Headless options were added when several people asked for that option (there have been a number of forum threads asking how to achieve headless operation). The real problem is the mechanism for knowing whether the unit is intended to be headless or not. Quite often individuals performing the flash are not aware of headless/GUI mode changing based on whether a monitor is attached during the flash (past releases did not change what was installed with or without HDMI connected).

I would personally prefer to have multiple sample rootfs variants available: One with the full GUI, another with headless. On top of that, perhaps even an option to use yet another sample rootfs variant with remote desktop software (one might or might not want remote desktop software for both headless and GUI). One would still need a method of picking which sample rootfs is used, but I believe manually picking what is desired would be less confusing.