Tx2 uart7 rx func err

hello pwpost,

since it has tested and confirmed with r32.3.1,
would you mind have integration to move your software release to it?
thanks

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 .

hello pwpost,

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,
thanks

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

  1. The host sends 8 bytes, or multiples of 8 bytes, and TX2 can receive them normally.
  2. If the host sends less than 8 bytes, TX2 will not receive it, but the host will receive the content sent.
  3. 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.

hello pwpost,

FYI,
the default baudrate setting is 115200/8n1,

hi jerry
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.
thks

hello pwpost,

please also have a check with having getty on background,
for example,
$ 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
serial{
port = <0xff>;
has_ input;
}

hello pwpost,

  1. did you mean you did not seen RX failure by having getty on background?
  2. according to post #21 from Topic 54572, UART7 should works with l4t-r28.3.1

hi Jerry

  1. When I use the command you provided, the system does not prompt any errors. like this:

getty -a ubuntu -L 115200 ttyTHS6 &
[1] 2898

  1. 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.

I also continued to do this test:
Put {my_ path}/hardware/nvidia/platform/t18x/common/kernel-dts/t18x-common-platforms/tegra186-quill- common.dtsi Document’s serial@c290000 status = “disabled”;
Then: make O = $TEGRA_ KERNEL_ OUT dtbs
I found Linux_ for_ Tegra/kernel/dtb/tegra186-quill-p3310-1000-c03-00- base.dtb No update, also confirmed after decompiling to DTS serial@c290000 status != “disabled”;
I’ll go on. / apply_ binaries.sh After that, check the above DTB file again, but it is still not updated.
This shows that topic in 54572, #49 , When I followed these steps, they didn’t work,Which part of me is wrong? Please check it for me, thanks a lot!
https://forums.developer.nvidia.com/t/how-to-enable-uart7-d8-d5-as-normal-uart-like-other-uart-uartc-c280000/54572/49

could you please have a try to disassembler the dtb file into text file for modification,
for example,
$ dtc -I dtb -O dts -o temp.dts tegra210.dtb

then, convert the DTS into a DTB for flashing
$ dtc -I dts -O dtb -o output.dtb temp.dts

you may refer to Flashing a Specific Partition to enable -k options to flash kernel-dtb partition.
or, you may generate sign/encrypt file locally,
for example
$ sudo ./flash.sh --no-flash -r -k kernel-dtb jetson-tx2 mmcblk0p1
after that, you may using dd commands to overwrite device tree partition.
thanks

Thanks for your reply!
the problem of modifying dtsi and making it effective is clear to me.

1.Modify hardware /NVIDIA/platform/t18x/common/kernel-dts/t18x-common-platforms/tegra186-quill-common.dtsi
2.make O=$TEGRA_ KERNEL_ OUT dtbs
3. Generate the DTB file in $Tegra_ KERNEL_ Out / arch / arm64 / boot / DTS / directory
4.flash.sh -r -k kernel-dtb… This command defaults to writing DTB files in Linux_ for_ Tegra / kernel / DTB / directory
5.cp $TEGRA_ KERNEL_ OUT/arch/arm64/boot/dts/tegra186-quill-p3310-1000-c03-00- base.dtb Table of contents for step 4
6. flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1
At this point, the modified dtsi takes effect.

I suspect that the problem is in this step. I’ll see how to further investigate and confirm.Please give guidance

https://forums.developer.nvidia.com/t/internal-tx2-traffic-on-uart7/56904/2

I found the most official and the earliest topic of this problem. I followed this step and modified or not to 0xff. The phenomenon is the same: uart7 is sent normally, and there is an error in receiving. Bpmp failed to configure uart7. I don’t know what causes this phenomenon.
In addition, is the source code of bpmp low-level program open, and where can I get it?

I can access this information on uart7 now