Basic IO (message in a bottle)

Some of us are not part of a large organization with a staff of engineers. I’ve been doing embedded design for a very long time but am by no means a Linux programmer expert on device drivers and such. So is it really that much trouble for nVidia to provide basic documentation to make their customers life just a wee bit easier?

I spent a long time just trying to connect the TX1 development kit debug UART to another computer using putty… a task I’ve done many many times. ‘dmesg | grep tty’ lists no less than 5 available devices and of course ttyTHS2 was the correct one AND last one that I tried. Someone at nvidia knew this so why do I have to find out this information empirically? Now I want to use the SPI1 device on J21. Looks like I have to write my own driver and compile my own kernel based on an alternate device tree… Really? you can’t make that available to help get your customers started so that they can concentrate on what ever it is that they actually want to accomplish?

nVidia, PLEASE at least offer basic stuff that you’ve already done so that everyone doesn’t have to start from scratch and hours of research.

Here’s the guide to the debug serial port:

On ARM, for interfaces off the ARM APMB Peripheral Bus like I2C/SPI/ect. (see pg 8 of the module datasheet), you have to edit the device tree in the DTS files for the specific devices. It’s an ARM thing. Sorry you’ve had a rough start of it.

thanks dusty_nv,

Your advice about the serial port is a good example of what I’m saying. Along with other sources I had read the guide that you refer to. I use an Adafruit 4-pin rs-232 3V- USB cable so a lot if what’s there doesn’t apply. That guide makes no mention of what device (ttyTHS2) is actually connected to J17 which was a big part of my problem. The guide does suggest that user privileges could be a problem ( a rabbit hole ) for serial devices… etc. etc I think that people who do this everyday forget the breadth of possible issues that need to be tracked down by those how don’t.

I’ve done device tree edits for embedded Arm in Xilinx and Altera FPGA devices so I’m not completely unfamiliar with Arm linux but I don’t do it on a regular basis . So my question remains, if nVidia has already tested the GPIO, audio and SPI interfaces offered on the user headers (like J21) why can’t that be part of the default kernel installed by the Jetpack? A least it would provide a known-good source for customers learning their way around Teguntu linux… just a (hopeful) thought

The test fixtures used in Q/A aren’t practical for release or applicable for typical embedded applications. Usage of the peripheral interfaces is dependent upon not only the carrier, but which device(s) are attached on the other end. GPIO and audio are in the kernel and SPI requires device-specific DTS configuration. The standard Linux APIs and interfaces for these and others are used. Over time more tutorials will be created by NVIDIA and the community. In the meantime here are some links —

I’m enjoying working with the TX1 and find most of the docs very useful, especially the TRM/CBS, higher level APIs (cuda etc) kernel build instructions and this forum.

But I also feel usr2222 has a point - some basic info at the interface level is/was missing, such as GPIO pin mappings (until recently) and a bunch of us can’t get SPI1 working over on this thread:

Granted there are may carriers, but most of us start with devkit, and if we can’t bring up interfaces on the dev board we can’t migrate them to our carrier either. Somebody at nvidia must know how these things should work, at least in a reference implementation. :)

Has anyone else had a problem of the GPIO Pins outputting 1.3-1.8V instead of 3.3v? I’ve already shorted the J24 pin which is supposed to change the output voltage between 1.8 and 3.3V, but nothing changes. Is there any software or hardware changes I can make to make sure the GPIO pins output a constant 3.3V?

J24 is used for voltage select for SPI1/I2C_GP0 level shifter (U7) , pin 1 + pin2 = 3.3V, Pin3 + pin2 = 1.8V