AM62 Gpio sys/class computation - Driver Lora

Hi Toradex,

I’m implementing the Lora Gateway driver from Semtech :

Bad luck, this driver implement a script that use the sys/class/gpio old fashion.

So I need, to expose this gpio to my C program running into my container.

My debian image build this driver that generate archive that i have linked into my C program.

But first, to validate my hardware connexion, i would like to just execute the example util_chip_Id program that read the pciE sx1302 module connected to SPI + reset pins. This executable is compiled when we build th driver.

I didn’t find information in the documentation for AM62 on linux kernel gpio number computation:

When I look into: sys/class/gpio, there is three gpio : 344, 396 and 488.

On my AM62 + Mallow board, I would like to use the GPIO 1,2,3,4 to control the reset signal etc…

So i’m searching the way to know the equivalence between the sys class export and the pin number on the mallow board.

An idea will be to modify the driver to use libgpiod also but I have difficulty to esptimate the effort for the moment.


Hi @jeremias.tx and @henrique.tx

Do you have this information please ?

Thank you !

Hi @FloSolio,

I am very sorry for the big delay.

When I look into: sys/class/gpio, there is three gpio : 344, 396 and 488.
From here you can see that " the long famous sysfs GPIO interface (/sys/class/gpio ) has been deprecated, the GPIO Char Device API, also known as libgpiod has been adopted by the Linux kernel community as the replacement."

If you are using a reference image you should be able to use the commands from the link I previously send you. Should you use a Torizon image, the functions are not integrated as a standard. In that case you can proceed with the steps below.

On this link you will find the instructions on how an example C code is run to toggle the gpios. When you get to step 2 (Build the Docker Image With the C Samples) please be sure to change the following lines:

ARG IMAGE_ARCH=linux/arm/v7


ARG IMAGE_ARCH=linux/arm/v8

also change the paths in the following lines according to the locations of your C files:

    && $GCC_PREFIX-gcc -o gpio-toggle ../gpio-toggle.c -lgpiod \
    && $GCC_PREFIX-gcc -o gpio-event ../gpio-event.c -lgpiod

When your container is running, you can get the information of the gpios through the gpioinfo command.
There you will see the necessary SODIMM pins you will need, to toggle your desired gpio pins.
From what I could gather, you want to use the following gpios, which can be found in the Mallow datasheet:

This means, that you will want to use SODIMM pins 206, 208, 210 and 212.
If you are successfully able to toggle those pins, you can use the gpio-toggle.c file as a template for your C application.

Best regards

1 Like

Thanks a lot @collin.tx for your answer.

I already successfully drove pins with python into my docker.

I fully agree that driving gpio via /sys/class old method is not the best way to proceed at the moment.

If you open the source files of the driver, you will see that /sys/class for gpio and ioctl to control spi communication are used.

If I understand correctly, I should modify all the sx1302 source code to drive gpio with libgpiod ? I would prefer to avoid that if possible, to keep it in line the project with git to be able to update it in case of new release.

So the question was , how to know the equivalence between the number that we should use with sys/class ans the sodimm pin number ?

For example, on other boards, there is a computation like this :

pin = 32*3+10


If I were able to have this info for my AM62 board, I should only need to adapt the pin number into the sheel script to export the gpio 1 2 3 4 pins (sheel script is here: sx1302_hal/tools/ at master · Lora-net/sx1302_hal · GitHub ).

If not, i would change the driver code.

Also, the spi command in the driver are using ioctl. And it seems to be the case in toradex spi example :

spi « tools - kernel/git/stable/linux.git - Linux kernel stable tree.

So no special adaptation should be done, may be just give the good spi number as an argument only ( spi1 vs spi0 by default in the driver).

Thanks a lot !

I also found this way to move from sys/class to gpio functions:

And the documentation missing for AM62 is :

The finality is to use driver function in my C project.

My project at the moment is based on the Torizon C template.

I was able to modify the docker file and build the archive of the driver.

I’m able to call driver functions in my main.c program.

So now the idea will be to drive the gpio and the spi.

I need to integrate in my C template the C gpio docker file content to control the gpio in my main.c

I have just an issue even if i add to torizonpackage and linker -lgpiod

I wonder how this header can be detect by my host system on vs code if it is not installed on it but installed via the docker.

So should I install gpio on my host pc to avoid it ?

I understand that toradex push to use docker method to work, but sometimes i have the feeling that we spend more time on this than our real application :sweat_smile:

Hello @FloSolio,

Sorry for the repeated delays when responding to this thread.

This documentation is missing because the alphanumeric GPIO assignment can change between BSP versions, therefore it is not the recommended approach for handling GPIOs.
That being said, the following assignment is valid for the Verdin AM62 Quad 2GB WB IT v1.1A running Torizon OS 6.5.0:

  • gpiochip0: Lines 0 to 23 correspond to /sys/class/gpio488 to /sys/class/gpio/gpio511;
  • gpiochip1: Lines 0 to 91 correspond to /sys/class/gpio396 to /sys/class/gpio/gpio487;
  • gpiochip0: Lines 0 to 51 correspond to /sys/class/gpio344 to /sys/class/gpio/gpio395;

This problem is more of convenience and ease of use, as the header is not actually missing when the code is built on the docker container.
Your workaround to install the development libraries on your PC is a valid one and should solve the problem.

Overall, Docker has a learning curve but its advantages in terms of containerizing applications and dependencies really pay off in terms of reproducibility and portability.

Best Regards,

thanks Bruno. I have just adapted the script by replacing the echo by gpioset function.

Thank you