I use L4T release28.2.1.Tx2 and tx2-i both can boot up,but when tx2-i boot,system show some error message by dmesg.
I compare this dmesg log, find some different between emmc.
TX2-I :
[ 0.371263] isomgr_init(): iso emc max clk=1600000KHz
[ 0.371273] isomgr_init(): max_iso_bw=7680000KB
Tx2 :
[ 0.363012] isomgr_init(): iso emc max clk=1866000KHz
[ 0.363025] isomgr_init(): max_iso_bw=26870400KB
And tx2-i show this error message:
max_iso_bw is relaxed to 7799200KB from 7680000KB
[ 0.424424] ------------[ cut here ]------------
[ 0.424441] WARNING: at ffffffc00085857c [verbose debug info unavailable]
[ 0.424451] Modules linked in:
Not sure how this relates to the kernel error, but the tx2i.log file indicates EDID (i2c) failure and a regulator failure for HDMI.
This is surrounded by various EDID/i2c errors:
[ 4.809689] hdmi: couldn't get regulator vdd_hdmi_5v0: -517
Does the monitor work correctly on other systems? Is it purely HDMI? Probably the monitor is ok since the regulator failure wouldn’t care about things like VGA adapters, but I have to ask since EDID is failing. If nothing unusual is going on, then it looks like hardware failure.
Monitor is work correctly,use default edid message(1280x1024).Our hardware platform has two purely HDMI and both of them worked correctly.EDID failing because our platform does not connect tx2 DDC to monitor. TX2 display use default EDID instead of DDC.
Our hardware platform compatible tx2 and tx2i.Tx2 can work correctly but tx2i does not.
Another problem,when TX2I boot up on our platform,user cann’t transmit command by system terminal（uart0）.But receive work correctly.
I can’t help much with a custom board, but I wonder if the regulator is an issue even though you have hard coded the EDID. There are so many i2c errors I have to wonder if this might be influencing something else beyond just the monitor’s EDID.
Is your serial console trying to use RTS/CTS flow control? If so, disable this in software and connect only the DP/DM/GND.
Hi,
After flash the TX2I,this error was disappeared.But system treminal does not work correctly.Could you help me? How to disable flow control?
Base on dts file, I did not find any uart flow control property.
I use ssh connect to tx2-i,and use this command to transmit date to ttyS0(system terminal)“echo hello > /dev/ttyS0”.
On system terminal,I find ttyS0 transmit “hello” to my PC by USB-UART connection.
And use “cat /proc/interrupts | grep serial”,I find interrupt number has been increasing.But terminal still can not receive keyboard input.
Flow control depends on two wires, plus a setting in your serial console program. The wires are the CTS and RTS wires.
Most serial console programs do not use CTS/RTS unless set up to do so, but some might. Which serial console program do you use? Basically just look for any kind of flow control and make sure CTS/RTS or “hardware” flow control are not enabled as options. In some cases it may list “software” flow control to mean the same as no CTS/RTS.
The two wires supporting flow control, the CTS (“clear to send”) and RTS (“request to send”) wires are described here since a TX1 can use these (TX2 is the same as a TX1, but does not seem to support flow control in the TX2…only half of the communications works on a TX2 if flow control is enabled…exactly as you describe):
[url]Jetson/TX1 Serial Console - eLinux.org
If you have only the three wires connected, and not the five wires, then you already have disabled the hardware side and only the serial console program could have the wrong settings.
I find that most serial UARTs do the right thing if CTS/RTS is connected physically, but disconnected in software. Removing CTS/RTS wires (in addition to software setting) only matters on a few serial UARTs.
I am sure hardware and software flow control is disabled.
I noticed some log like this" To run a command as administrator (user “root”), use “sudo ”." But tx2 boot does not have this message.
If there is activity on the serial console UART, then this will be interpreted as a user typing in a command. Since serial console is logged in as user “nvidia”, you will see a message such as this if the command requires being root:
You must run this program as root or use sudo!
Certain commands already have “sudo” behind them to prevent this (requires a password), but I am wondering if your “sudo” is set up correctly. Do you see any kind of permission error if you run this command?
sudo ls
If this has an error, what is the output of:
ls -l /usr/bin/sudo
The bottom line is that some command was run, either via the serial line or via a boot script, and that command wanted root privileges to execute and did not have root privileges. If sudo is not set up correctly, then there was an issue with how flash was performed and no root command will ever succeed via sudo; if sudo was set up correctly, then the question switches to whether the root-only command arrived via the serial console or via a boot script.
The above ls command with sudo will test the sudo command itself.