This seems moderately consistent with what I was experiencing.
How is your issues going?
The issue was resolved when I followed the steps that I outlined in the other thread.
Considering you already have access to the serial port, I would say that you only need to edit the BPMP device tree to turn off the debug serial functionality.
Make sure you edit the correct file. The flash procedure doesn’t use the one listed in the configuration file (as per that thread).
Glad to hear that msg, I will find the method to edit BPMP device tree ,thanks
This problem is still unsolved.
I have tried to decompile tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2.dtb and modify it
port = <0xff>;
After compiling to DTB, flash -r -k kernel-dtb jetson-tx2 mmcblk0p1 is used again. The fault phenomenon does not change after restart.
please also refer to Topic 54572, which has confirmed to enable UART7 on TX2/ r32.3.1.
I have tried this topic for at least three times, but the fault still exists.
do step by step with what williamho says
since it has tested and confirmed with r32.3.1,
would you mind have integration to move your software release to it?
The upgrade version will not be considered at present, because many high-level development is based on the current version. This will lead to more problems.
bootlog.txt (165.5 KB)
this is the boot log info. please help me to fix this problem .
according to the logs, UART7 has registered correctly,
[ 0.239850] iommu: Adding device c290000.serial to group 21 [ 2.647940] c290000.serial: ttyTHS6 at MMIO 0xc290000 (irq = 44, base_baud = 0) is a TEGRA_UART
may I have your error reproduce steps, please also share failures for reference,
Hardware connection: TX2 uart7 <—> TTL convert USB - host pc
Using the cutecom tool, open /dev/ttyTHS6, @9600bps/8/1.
The host also opens the serial port tool，with 9600bps/8/1.
If TX2 sends any character, the host can receive it normally. Tx functions is correct
- The host sends 8 bytes, or multiples of 8 bytes, and TX2 can receive them normally.
- If the host sends less than 8 bytes, TX2 will not receive it, but the host will receive the content sent.
- If the host side sends more than 8 bytes of data, TX2 will receive 8 bytes, and the host side will receive the contents after 8 bytes.
the default baudrate setting is 115200/8n1,
If the serial port is used by the user, the baud rate should be determined by the user’s application instead of a default value. And paying attention to the baud rate should not be the focus of the problem.
please also have a check with having getty on background,
$ sudo /sbin/getty -a ubuntu -L 115200 ttyTHS<port> &
I used the command you gave to connect to uart7 through the serial console. There was no response.
If I replace other serial ports, such as ttyTHS2, the console operates normally.
Through this test, I think we can eliminate errors caused by cutecom.
I suspect that the following step did not work properly, Is there any way to verify it? Such as log information or auxiliary tools…how to confirm it
decompile tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2.dtb and modify it
port = <0xff>;
- did you mean you did not seen RX failure by having getty on background?
- according to post #21 from Topic 54572, UART7 should works with l4t-r28.3.1
- When I use the command you provided, the system does not prompt any errors. like this:
getty -a ubuntu -L 115200 ttyTHS6 &
- according to post#27 from Topic 54572, This topic only mentioned that ttyths6 can be turned on normally, but RX still has problems and has not been solved.
I did a test:
Restore the serial port in tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2.dtb to 0x07, and then flash in. The error phenomenon is the same. This also indirectly indicates that the modification of ucm2.dtb does not take effect correctly.