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
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.
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
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,
hi Jerry
getty -a ubuntu -L 115200 ttyTHS6 &
[1] 2898
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?