As mentioned in the very first message of this thread - I have also been able to successfully disable the combined uart, and to bind the tegra-hsuart driver to the device, but actual data transfer over the port is very unreliable / non-functional - even a loopback jumper cable (tx->rx) fails to echo more than a few sent bytes in a terminal emulator e.g minicom, and host<->host transfers also show strange buffering / missing data problems.
Have you verified correct data transfer in addition to the lack of a /dev/ttyTCU0 and addition of a /dev/ttyS2 or /dev/ttyTHS2? because it seems like it should work - no dmesg errors or similar - and it sort of does work with tegra186-hsuart, but not in a way thats useful for transport of real-world data…
And what my initial questions were trying to resolve is - does this actually work, vs just look like it works - i.e. how much testing, if any - have you done with real world data transfer over the port that results from this process, and assuming there has been some - was any spurious behaviour such as I outlined above - present?
I tried using the ‘tegra20-uart’ driver in place of the ‘tegra186-hsuart’ driver, and got no I/O at all - I tried removing the dma devicetree entries for the tegra186-hsuart devicetree config so that it would be forced into PIO mode to see if dma was complicating things and got no I/O at all.
Looking at the tegra-tcu driver, it seems that it only talks with a mailbox buffer, and the actual uart initialisation and I/O is done by the SPE hardware on the jetson, and
the tcu driver hardcodes line-ending subsitutions/replacements that are not compatible with raw data transfer.
Are the ports on c280000 and c290000 - which, as far as I can tell - are part of the ‘AON - always on?’ hardware block of the SoC, actually drivable by the tegra-serial driver in the kernel - and if so, which variant?
if it is not tegra186-hsuart on the xavier nx, why is there a config for it in the platform devicetree with presumably correct clocks, registers and dma entries?
tegra186-hsuart kind of works - a /dev/ttyTHS2 is present, but cannot correctly transfer data.
using tegra20-uart, as you suggest above, results in a port that can be opened but results in no IO at all on /dev/ttyS2.
My situation is pretty much exactly the same as this person here:
They ended up re-enabling the TCU driver because the tegra-hsuart driver could not correctly drive it.
Really, what i’m looking for is not another redirection to a forum post, but an answer on whether this can work - I dont mind experimenting and following forum posting rabbit holes if I know that this does work and i just need to figure out the configuration to make it work - but if i’m just following forum postings and wasting hours on devicetree changes and reflashing boards - when it actually can’t work.- you know, itd be better to understand that sooner vs later.