Hello,
When attaching the TX1 module to a custom carrier board, the module never lots to GUI. Instead, it opens up “root” access terminal. I have attached an image of the screen and some messages. Of note, the module operates normally when attached to the dev board. I’ll reply with the image.
Thanks for the help.
Is the exact same root file system used in both the case of the custom carrier and the regular developer carrier board?
In the case of an exact match in root file system, which exact release is this from (see “head -n 1 /etc/nv_tegra_release”)?
Is the same monitor used in both custom carrier case and developer carrier board case?
Question 1: Yes
Question 2: REVISION: 2.1, GCID: 7791156, BOARD: t210ref, EABI: aarch64, DATE: Thu Sep 29 00:59:21 UTC 2016
Question 3: Yes, and it works when connected to the dev board
If you boot to both carrier boards, and run this command, does file “edid” exist on both? Are both finding this file at “/sys/kernel/debug/tegradc.1/”? If found, what is the content of file “edid” on both…do they match, or do they differ? Are both found in the same directory?
find /sys -name 'edid'
Normally I would not expect GPIO changes to be a problem, but changes could if the GPIO had previously been used for some other purpose and then suddenly the other purpose had been broken For example, suppose changing GPIO of something which detects video suddenly went missing…that’s just a contrived example, but it illustrates the idea. From both the developer carrier board and the custom carrier board, what is the content (use “ls -l /sys/class/gpio/*”, you’re just listing files, and for the case of symbolic links, where they point) of “/sys/class/gpio/”.
Note that monitor detection of EDID uses the i2c protocol, so if a change to GPIO broke i2c it might break the creation of the “edid” file (which is a result of monitor EDID query over i2c).
EDIT: On both carrier boards, what is the content of:
/sys/kernel/debug/gpio
root@tegra-ubuntu:/sys/kernel/debug/tegradc.1# vi edid
00 ff ff ff ff ff ff 00 0d 82 34 12 db 02 96 49
ff 1a 01 04 a2 00 01 78 fb 6e a5 a3 54 4f 9f 26
11 50 54 a5 6b 80 d1 fc d1 3c d1 cf 8b c0 8c c0
a9 c0 a9 40 b3 00 86 6f 80 a0 70 38 40 40 30 20
35 00 40 44 21 00 00 1e 00 00 00 fc 00 66 69 74
48 65 61 64 6c 65 73 73 47 53 00 00 00 fd 00 18
4b 1e 87 3c 00 00 00 00 00 00 00 00 ed 7b 80 a0
70 b0 47 40 30 20 36 00 40 68 21 00 00 18 01 69
02 03 45 01 47 66 64 61 5f 5c 3f 10 3e 7f 7f 28
0f 7f 07 17 7f ff 3f 7f ff 47 7f ff 5f 7f 82 7f
7f 00 7f 7f 51 7f 7f 30 77 7f 03 83 7f 00 00 6d
03 0c 00 20 00 80 3c 20 10 60 01 02 03 67 d8 5d
c4 01 78 80 03 1e 66 70 a0 80 b0 34 40 30 20 35
00 88 68 21 00 00 18 fe b9 70 50 d0 a0 3f 50 08
20 18 00 08 b0 41 00 00 18 71 c2 00 a0 a0 a0 55
50 30 20 35 00 00 b0 31 00 00 18 00 00 00 00 26
~
~
root@tegra-ubuntu:/sys/kernel/debug/tegradc.1# ls -l /sys/class/gpio
total 0
–w------- 1 root root 4096 Feb 11 2016 export
lrwxrwxrwx 1 root root 0 Feb 11 2016 gpiochip0 → …/…/devices/platform/6000d000.gpio/gpio/gpiochip0
lrwxrwxrwx 1 root root 0 Feb 11 2016 gpiochip1008 → …/…/devices/platform/7000c400.i2c/i2c-1/1-0074/gpio/gpiochip1008
lrwxrwxrwx 1 root root 0 Feb 11 2016 gpiochip984 → …/…/devices/platform/7000d000.i2c/i2c-4/4-003c/max77620-gpio.0/gpio/gpiochip984
lrwxrwxrwx 1 root root 0 Feb 11 2016 gpiochip992 → …/…/devices/platform/7000c400.i2c/i2c-1/1-0077/gpio/gpiochip992
–w------- 1 root root 4096 Feb 11 2016 unexport
~
~
root@tegra-ubuntu:/sys/kernel/debug# vi gpio
GPIOs 0-255, platform/6000d000.gpio, tegra-gpio:
gpio-2 (pcie_wake ) in hi
gpio-28 (usb-vbus3 ) out lo
gpio-56 (wlan_pwr ) out hi
gpio-57 (rtl-5v0 ) out hi
gpio-59 (bt_ext_wake ) out hi
gpio-60 (reset_gpio ) out lo
gpio-61 (bt_host_wake ) in lo
gpio-67 (vdd-disp-3v0 ) out lo
gpio-87 (pwm-fan-tach ) in hi
gpio-148 (cam_reset_gpio ) in lo
gpio-151 (cam_pwdn_gpio ) in lo
gpio-169 (lcd-bl-en ) out lo
gpio-188 (temp_alert ) in hi
gpio-189 (Power ) in hi
gpio-190 (Volume Up ) in hi
gpio-192 (Volume Down ) in hi
gpio-200 (1.extcon ) in lo
gpio-201 (sdhci_cd ) in lo
gpio-203 (en-vdd-sd ) out hi
gpio-204 (sdhci_wp ) in lo
gpio-225 (hdmi2.0_hpd ) in lo
gpio-228 (usb-vbus1 ) in hi
“gpio” [readonly] 46L, 1786C
gpio-229 (en-usb-vbus2 ) out hi
GPIOs 984-991, platform/max77620-gpio.0, max77620-gpio, can sleep:
gpio-984 (1.extcon ) in lo
gpio-985 (vdd-sys-boost ) out lo
gpio-987 (vdd-3v3 ) out lo
gpio-990 (regulator-pwm ) out lo
gpio-991 (max77620-gpio7 ) out lo
GPIOs 992-1007, i2c/1-0077, tca9539, can sleep:
gpio-995 (en-vdd-cam-1v2 ) out lo
gpio-1001 (en-vdd-cam ) out lo
gpio-1002 (en-vdd-cam-1v2-alt ) out lo
GPIOs 1008-1023, i2c/1-0074, tca9539, can sleep:
gpio-1009 (en-vdd-ts-1v8 ) out lo
gpio-1010 (en-vdd-ts-hv-3v3 ) out lo
gpio-1011 (en-vdd-disp-3v3 ) out lo
gpio-1012 (vdd-fan ) out hi
gpio-1015 (en-mdm-pwr-3v7 ) out lo
gpio-1017 (en-vdd-disp-1v8 ) out lo
gpio-1020 (vdd-hdmi ) out lo
gpio-1021 (en-vdd-cam-hv-2v8 ) out lo
Here’s an important part of the question…I see only one listing of the edid file…is this file an exact match regardless of which carrier board is used?
The files are present in both. After troubleshooting with the connectors the electronics seem fine. I do get to command line, though it never gets to the GUI on the carrier board/tx1, while it continues to work on the dev board. Could this have resulted in part from the update (ubuntu 14.04 to ubuntu 16.06)? I have another tx1 that is running ubuntu 14.04 and the GUI works fine.
How might I fix this? Is there a fix on the 16.06 ubuntu version, or must I try to get ubuntu 14.04 back up and running (I’d prefer not to have to…)?
Is the TX1 with ubuntu14.04 running a 32 or 64 bits arm linux ?
I’m running into similar (albeit maybe different) problems with L4T 64bits R24-2.1.
The ubuntu 14.04 module is running a 64bit
Which versions of L4T are running on each ?
Just some information: L4T prior to version R24.1 was 64-bit kernel space, 32-bit user space; L4T R24.1 offered two sample rootfs variations…one to maintain 32-bit user space, the other was a new 64-bit user space (most people used 64-bit user space when R24.1 became available). Anything newer than R24.1 will always be 64-bit in both user space and kernel space.
To see version:
head -n 1 /etc/nv_tegra_release
NOTE: It’s important to know if that edid file is the same on both carrier boards or not.
Hi,
Thanks for the advice. The carrier board does work with a tx module that has the beta version of R24.1. The module that does not bring up GUI but instead, brings me to ‘root command line’ has the latest Jetpack version with ubuntu 16.04
Is serial console available? If so, then it should be possible to log the entire boot process on the carrier board in question.
Having the same edid file present on both systems using the same monitor and cables with the same release of L4T should produce the same results on either carrier board. In this case I’d wonder if something is wired differently on the non-working carrier board, but it seems any possible wiring failure is not catastrophic (or else you wouldn’t even get the root command line).
Note that having a console login show up is normal on a directly connected keyboard/monitor setup if X does not start. However, if this is literally a “root command line” (running as root and not user ubuntu) then boot has stopped at single user stage. Normal user login stage where a password prompt is given is multi-user stage and occurs after single user stage; if in single user stage then the issue is not video at all…no graphics ever run in single user mode…this would indicate your video is completely functional but never reached.
On the command line you see did it autologin? If so, what user is shown from the “whoami” command?