There appears to be some non-user-controlled traffic on UART7, which seems to make it difficult/impossible to use for a custom application, as noted here:
We are observing that sometimes this other (internal) controller responds with error messages to traffic we generate on that UART, which get interleaved with our application’s traffic. This makes UART7 not really usable for bidirectional communications with an external module (in our case, an IMU).
Is there some way to tell that “other” (internal to TX2) device on UART7 to “stop talking” after the boot process has completed, so that UART7 can be used solely for a custom application?
but when I use minicom to test whether if this port is ok, is return stange info
OPTIONS: I18n
Compiled on Feb 7 2016, 13:35:57.
Port /dev/ttyTHS6, 03:04:48
Press CTRL-A Z for help on special keys
f
error: line too long
command not found
]
command not found
] ]
error: line too long
command not found
] ]
error: line too long
command not found
] ]
error: line too long
One of the problems with using minicom is that it assumes everything you are talking to is also a modem with the “AT” commands. This is ok and won’t matter if configuration does not do this, but in this case it might be hard to distinguish whether this is a side effect of minicom configuration or if it is a side effect of something else.
So you might try again with a simpler application like this (picoterm example) or gtkterm (these don’t assume it is a modem):
<b>picocom</b> -b 115200 --databits 8 --parity n --stop 1 --flow n /dev/which/ever/tty/device/it/is...
Do the issues show up under any of these as well? (I am assuming this UART is 115200 8N1)
This makes me curious considering all else seems correct:
OPTIONS: I18n
Are you using a different character set or encoding other than en_US? I’m looking for the possibility that more than 8 bits are being sent or that there may be cases of combinations (UTF-16 instead of UTF-8) which the terminal isn’t passing through correctly.
If there is some sort of encoding issue I’m thinking perhaps passing known en_US UTF-8 file content through instead of keyboard might test encoding issues if any of the above differences are found.
Is there updated instruction for this? t186/tegra186-a02-quill-pxxxx.dtb doesn’t match any file in my bootloader folder with Jetpack 3.2.
Or where would we change it in the source dts file so as to preserve it when new dtb built (maybe stupid question - if these are bootloader dtb and not build when kernel dtb built).
This is just in general, I do not know about your particular case. Some general information…
The TX2 uses a tegra18x series, specifically the tegra186, abbreviated t186. The a02 would be a board revision, the “pxxxx” is abbreviated for the numeric designation of either the module or the carrier (so you might need to adjust specifics for your module and carrier). Depending on release, look in the driver package’s “bootloader/t186ref/” subdirectory. Various device tree files will be there, and flash would choose among those depending on what the board is (the numeric designation would have one version for module, a second version for carrier would combine to be a complete description of module on carrier). My TX2 developer kit happens to be described from “p3310-1000”. Different trees may apply to different subsets of module and carrier, whereby different smaller trees might be inserted into the final full tree.
Flash logs on my particular TX2 under R28.2 shows:
The first dtc operation, with “-I dtb”, takes the binary file as input, and the output format is source, via the “-O dts”. File name output can be arbitrary, and in that example, “-o test_bpmp.dts”. You can view, manipulate, edit, and place this extracted file back into binary format and use it to replace the one used in the “bootloader/” subdirectory during flash.
Note that within the “Linux_for_Tegra/” subdirectory, where the driver package exists, that the log above shows the original file in “bootloader/t186ref/tegra186-a02-bpmp-quill-p3310-1000-c01-00-te770d-ucm2.dtb” (and other dtb files) can be copied from other locations for staging before flash. Subdirectories of the “bootloader/” directory are worth exploring after looking at “copy” logs from a flash.
Seems to infer the proper dtb to modify is tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2.dtb similar but slight difference as listed by your flash log.
If you flash and save a log of your particular Jetson using the particular release currently running, then you should be able to verify which files are needed (my module or carrier revision may differ from yours).
Requires having build the kernel from source it appears, since the dtc file is found in the images output folder under scripts/dtc, in my case sources/images/scripts/dtc/
Looking at the flash.sh output as per linuxdev above I found the dtb used:
Btw, the dtc application itself, although being shipped with the kernel source, is more or less architecture independent and works across a very large range of device trees regardless of platform. This program is available as a regular package on Ubuntu, Fedora, and many other flavors of Linux without requiring the one which ships with kernel source.
Hello!
I’m try using UART7. Transmit from Tegra is good, but receive is wrong.
I change tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2.dtb in this place: (after decompiling, of course)
serial {
port = <0xff>; #port = <0x7>;
has_input;
};
Then I try flash Tegra, I see message:
NOTICE: BL31: v1.2(relase):e1e4477
NOTICE: BL31: Built : 00:08:30, May 17 2018
NOTICE: Trusty image missing.
ERROR: Error initializing runtime service trusty_fast