Can't seem to find gpiod.h for Verdin imx8m-plus build

@Evets,

If they device is connected to the network and you can ssh into it. The device should be recognized via the VS Code extension. There is no code to upload to the device to make it recognizable.

ApolloX is the V2 VS Code extension.

Eric

@eric.tx

The extension still says this only works for the 32bit version of Torizon. Is this the case? Before, I couldn’t install it, but now I can, even though that warning is still there. Maybe that is why it is not connecting?

Steve

@Evets ,

Where is this error coming from? Can you link more of the error?

The directions for connecting to a device are found here:

You should be able to connect to the network and then the device.

-Eric

Hi @eric.tx ,
OK, I have it loaded and the dev board is on my network. I try to use the “Network devices refresh” as instructed in the docs. It just sits there with the Trizon: Scanning Torizon devices… with nothing showing up as shown here.


If I manually add the IP address, I can get it to connect, as shown in @04-17 15:06:58:.205 timestamp. (I had removed the manual connection at 04-17 14:55:06.381) as shown here:

Also, you can see the reported version of v0.0.70 shown at the top of each picture.

And yes, if I open a terminal, I can do that (or also an outside ssh connection via a cmd window). I used the “Torizon: create new single container project”, (my only choice it gives me). results in this:
image
It also doesn’t seem to open any ports to the device, as you can see as if there were something open, it shows them.
Trying to run, gives me all sorts of errors as it doesn’t seem to open any ports or create a docker file.
RunOutput from terminal.zip (4.3 KB)

If I am missing something, please let me know what I am missing.
This last output was doing a “start from scratch” GPIO test. The problem I originally stated was from a Torizon extension (early access, or normal one). I had the ApolloX loaded but apparently not actually working, because the early access was loaded. But in any case, I couldn’t get the other extension to pull in the gpiod.h file, using the early access. I thought v2 was working at that point.

So in actuality, I would like to solve the original problem, rather than go down this V2 rabbithole.

Thanks,
Steve

@Evets,

I believe there are a few issues here.

It looks like you are still connected to the V1 Dev Container: Torizon_GPIO (lower left corner). The two versions are not compatible, so developing in V1 is not transferable to V2. You will want to close this.

If you are working in V2, you will also need to launch VScode from the WSL. Are you doing this? you can often just type ‘code’ into the CLI of WSL and it should open.

If you want to stay in V1, this is possible, but you should rebuild/reload the SDK. This is achievable by F1 + “Torizon:Rebuild SDK and reload in container”

-Eric

HI @eric.tx ,
At this moment, I am out of the ApolloX altogether and using the Early support extension, trying to get back to where everything compiles but gives me the error about not finding gpiod.h.

I did load VSCode from WSL. Didn’t know I could do this. I can’t do ApolloX v1 because it’s a 32bit version and this needs to be a 64 bit program.

If I DO run using v2, it compiles fine but when it tries to launch I get:

—> [Warning] The requested image’s platform (linux/arm64) does not match the detected host platform (linux/amd64) and no specific platform was requested

—> Running in 940ea075f832

Usage: usermod [options] LOGIN

Options:

-b, --badnames allow bad names

-c, --comment COMMENT new value of the GECOS field
-d, --home HOME_DIR new home directory for the user account
-e, --expiredate EXPIRE_DATE set account expiration date to EXPIRE_DATE
-f, --inactive INACTIVE set password inactive after expiration
to INACTIVE

-g, --gid GROUP force use GROUP as new primary group
-G, --groups GROUPS new list of supplementary GROUPS

-a, --append append the user to the supplemental GROUPS
mentioned by the -G option without removing
the user from other groups
-h, --help display this help message and exit
-l, --login NEW_LOGIN new value of the login name

-L, --lock lock the user account
-m, --move-home move contents of the home directory to the
new location (use only with -d)
-o, --non-unique allow using duplicate (non-unique) UID
-p, --password PASSWORD use encrypted password for the new password

-R, --root CHROOT_DIR directory to chroot into
-P, --prefix PREFIX_DIR prefix directory where are located the /etc/* files
-s, --shell SHELL new login shell for the user account
-u, --uid UID new UID for the user account
-U, --unlock unlock the user account

-v, --add-subuids FIRST-LAST add range of subordinate uids

-V, --del-subuids FIRST-LAST remove range of subordinate uids
-w, --add-subgids FIRST-LAST add range of subordinate gids
-W, --del-subgids FIRST-LAST remove range of subordinate gids
-Z, --selinux-user SEUSER new SELinux user mapping for the user account

I forgot to add. I get these messages when loading the system using V2:

04-17 20:50:32.960] Activating ApolloX Torizon …
[04-17 20:50:32.961] Resolving host IP address …
[04-17 20:50:32.999] Host IP address OK
[04-17 20:50:33.011] ERROR :: Docker is not installed. Please install Docker: Install Docker Engine | Docker Documentation
[04-17 20:50:33.029] ERROR :: Docker compose is not installed. Please install Docker compose Overview | Docker Documentation
[04-17 20:50:33.042] ERROR :: PowerShell Core is not installed. Please install: Install PowerShell on Linux - PowerShell | Microsoft Learn
[04-17 20:50:33.052] git OK
[04-17 20:50:33.077] ERROR :: avahi-resolve is not installed.
[04-17 20:50:33.091] ERROR :: nmap is not installed.
[04-17 20:50:33.104] ERROR :: iputils-ping is not installed.
[04-17 20:50:33.114] file OK
[04-17 20:50:33.124] ERROR :: sshpass is not installed.

Docker is installed
Docker compose is installed
and sshpass is installed,
even though it says they are not.
I am running Ubuntu 20.04 in WSL2
Steve

Hi @Evets ,

Let me clarify a few points, just to make sure we’re talking about the same thing:

  • The image below shows ApolloX: it is version 2 of our IDE extension. In this context there is no V1 of ApolloX.
    apollox

  • The image below shows version 1 of the IDE extension: it can only refer to either “Toradex Torizon Support” or “Toradex Torizon Support (Early Access)”. If you’re not using ApolloX, then you’re using V1 of our extension.

  • ApolloX is used with VSCode connected to WSL2. V1 should not be used with VSCode connected to WSL2.

  • If you used ApolloX and want to return to V1 you have to disable/uninstall ApolloX, and also do the following:

    • On VSCode, press F1, then go to “Preferences: Open User Settings (JSON)”
    • Comment/remove the line that starts with DOCKER_HOST": "tcp://<ip-address>"
  • If you want to keep using ApolloX instead just disable/uninstall any V1 of the extension beforehand.


At this moment, I am out of the ApolloX altogether and using the Early support extension, trying to get back to where everything compiles but gives me the error about not finding gpiod.h.

You said you are not using ApolloX anymore, but these logs you posted:

[04-17 20:50:32.960] Activating ApolloX Torizon …
[04-17 20:50:32.961] Resolving host IP address …
[04-17 20:50:32.999] Host IP address OK
[04-17 20:50:33.011] ERROR :: Docker is not installed. Please install Docker: Install Docker Engine | Docker Documentation
[04-17 20:50:33.029] ERROR :: Docker compose is not installed. Please install Docker compose Overview | Docker Documentation
[04-17 20:50:33.042] ERROR :: PowerShell Core is not installed. Please install: Install PowerShell on Linux - PowerShell | Microsoft Learn
[04-17 20:50:33.052] git OK
[04-17 20:50:33.077] ERROR :: avahi-resolve is not installed.
[04-17 20:50:33.091] ERROR :: nmap is not installed.
[04-17 20:50:33.104] ERROR :: iputils-ping is not installed.
[04-17 20:50:33.114] file OK
[04-17 20:50:33.124] ERROR :: sshpass is not installed.

are from ApolloX. What version of the extension are you using: V1 or ApolloX?

We need to be sure of this as the procedures on how to run a C/C++ project with libgpiod change a lot depending on the version of the extension:


If you intend to use V1, we have an article in our developer page explaining how to create a C/C++ project with it and adding the gpiod library: C/C++ Development and Debugging on TorizonCore Using Visual Studio Code | Toradex Developer Center . To summarize:

  • Close any connections to WSL2 or dev containers you might have by clicking on the lower left corner of the VSCode window, then selecting Close Remote Connection.

  • Press F1, then select “Torizon/C-C++: Create new C/C++ application”. Choose a Makefile-based project, then follow the on-screen instructions and let VSCode reload inside of a dev container

  • Add libgpiod-dev:arm64 to the devpackages settings, and add libgpiod2 to the extrapackages settings.

  • Press F1, then select “Torizon: Rebuild SDK and Reload in Container”. Wait for the operation to complete

  • Add your code to the project. The text editor might complain about gpiod.h not being found. If you did the steps above, ignore the warning.

  • Change Makefile so it has -lgpiod when compiling the relevant source files.

  • Make the GPIO pins visible to the container: C/C++ Development and Debugging on TorizonCore Using Visual Studio Code | Toradex Developer Center . Choose the GPIO bank you will be using.

  • Deploy and debug: C/C++ Development and Debugging on TorizonCore Using Visual Studio Code | Toradex Developer Center


If you intend to use ApolloX, as you’re using so far:

  • Close any connections to dev containers you might have by clicking on the lower left corner of the VSCode window, then selecting Close Remote Connection.

  • Then, connect VSCode to WSL2.

  • Make sure you followed the steps here to setup ApolloX, until the Creating a new Single Container Project step: GitHub - toradex/torizon-experimental-torizon-ide-v2-docs: VS Code Torizon Integrated Development Environment Documentation (Choose a C++ project instead of the C# the example uses)

  • Add the libgpiod packages to torizonPackages.json, as @hfranco.tx explained before.

  • Add your code to the project. The text editor might complain about gpiod.h not being found. If you did the steps above, ignore the warning.

  • Change Makefile so it has -lgpiod when compiling the relevant source files.

  • Change docker-compose.yaml so that the container has access to the GPIO pins. As an example, adding gpiochip0 will look like:

devices:
  - "/dev/gpiochip0:/dev/gpiochip0"

Replace gpiochip0 with the GPIO bank you will be using. More details about the compose-file can be seen here: Services top-level element | Docker Docs


See if these steps help you.

Best regards,
Lucas Akira

Hi @eric.tx ,
Thank you for your patience. I didn’t understand when I first loaded ApolloX that it was a replacement for the other extension. So, I have been using v1, most of this time, with the exceptions of the occasional try of v2 without much success.
So I went back to v1 and am using the early access version. I did as you ask going back to v1, although there was no DOCKER_HOST": “tcp://” in the JSON file.
I have the #include <gpiod.h> in one of my files, as a test. When it compiles I get:
fatal error: gpiod.h: No such file or directory
13 | #include <gpiod.h>

Which is what I was getting in the beginning when I wrote up this ticket. I have the -lgpiod in my Makefile, but this addition, only effects linking, not compilation, and it complains that it can’t find it. I have searched my target device to see if there is a gpiod.h file there, and it doesn’t find one.

When I take the #include <gpiod.h> out of my cpp file, I get:

/usr/lib/gcc-cross/aarch64-linux-gnu/10/…/…/…/…/aarch64-linux-gnu/bin/ld: cannot find -lgpiod
collect2: error: ld returned 1 exit status
make: *** [Makefile:105:] Error 1

As it can’t find the library either. And now since I played around with v2, I am getting this error using v1 when I try to run:
—> [Warning] The requested image’s platform (linux/arm64) does not match the detected host platform (linux/amd64) and no specific platform was requested
—> Running in 2109e5e9d8e5

e[91mUsage: usermod [options] LOGIN

Options:
e[0m
e[91m -b, --badnames allow bad names
-c, --comment COMMENT new value of the GECOS field
-d, --home HOME_DIR new home directory for the user account
e[0m
e[91m -e, --expiredate EXPIRE_DATE set account expiration date to EXPIRE_DATE
-f, --inactive INACTIVE set password inactive after expiration
to INACTIVE
-g, --gid GROUP force use GROUP as new primary group
-G, --groups GROUPS new list of supplementary GROUPS
-a, --append append the user to the supplemental GROUPS
mentioned by the -G option without removing
the user from other groups
-h, --help display this help message and exit
e[0m
e[91m -l, --login NEW_LOGIN new value of the login name
-L, --lock lock the user account
-m, --move-home move contents of the home directory to the
new location (use only with -d)
-o, --non-unique allow using duplicate (non-unique) UID
-p, --password PASSWORD use encrypted password for the new password
-R, --root CHROOT_DIR directory to chroot into
-P, --prefix PREFIX_DIR prefix directory where are located the /etc/* files
-s, --shell SHELL new login shell for the user account
-u, --uid UID new UID for the user account
-U, --unlock unlock the user account
e[0m
e[91m -v, --add-subuids FIRST-LAST add range of subordinate uids
-V, --del-subuids FIRST-LAST remove range of subordinate uids
-w, --add-subgids FIRST-LAST add range of subordinate gids
-W, --del-subgids FIRST-LAST remove range of subordinate gids
-Z, --selinux-user SEUSER new SELinux user mapping for the user account
e[0m
e[91m
e[0m
And then it stops and brings up launch.json.

Not sure why this isn’t working anymore.

Steve

Hi @Evets ,

So I went back to v1 and am using the early access version. I did as you ask going back to v1, although there was no DOCKER_HOST": “tcp://” in the JSON file.

OK, no problem if don’t have the line starting with DOCKER_HOST, just skip the step about it if that’s the case.

I have the #include <gpiod.h> in one of my files, as a test. When it compiles I get:
fatal error: gpiod.h: No such file or directory
13 | #include <gpiod.h>

A library not being found in compilation time in V1 of the extension means that the SDK container doesn’t have it. I’ll go more into details below.

Which is what I was getting in the beginning when I wrote up this ticket. I have the -lgpiod in my Makefile, but this addition, only effects linking, not compilation, and it complains that it can’t find .

Yes, that’s right. I mentioned about the link parameter just to guarantee this part is correct.

I have searched my target device to see if there is a gpiod.h file there, and it doesn’t find one. When I take the #include <gpiod.h> out of my cpp file, I get:
/usr/lib/gcc-cross/aarch64-linux-gnu/10/…/…/…/…/aarch64-linux-gnu/bin/ld: cannot find -lgpiod
collect2: error: ld returned 1 exit status
make: *** [Makefile:105:] Error 1

You won’t find anything related to libgpiod in your target device, at least not directly. Let me explain:

In V1 of the extension, C/C++ projects use what is called an SDK container, which is an environment in your host computer made to cross-compile your code that will be deployed to the target SoM. All packages specified in devpackages will be installed in this SDK container, but you need to rebuild it each time you update devpackages.

Therefore, if you can’t compile your project due to a missing library, it most likely means that the SDK container for whatever reason doesn’t have the lib in question.

Just to be sure, did you add libgpiod-dev:arm64 to devpackages and rebuild your SDK container with F1 → “Torizon: Rebuild SDK and reload in container”, like shown in the picture below?

After selecting the option above you also have to choose yes in a confirmation pop-up that appears on the lower right of the VSCode window:

After doing that VSCode should restart. Wait until both the dev container and the extension load again before trying to debug.

With this I was able to compile and debug a sample gpiod app that blinks an LED connected to a GPIO pin.

Hope this helps you.

Best regards,
Lucas Akira

@lucas_a.tx
Yes, I am aware of the need for rebuilding of the SDK, and I do it quite often. And yes, I have libgpiod-dev:arm64 in the extension under “Custom Properties/devpackages” and have had that since the beginning. I still can’t get it to find the gpiod.h file.
I have to ask, are you using the same target as I have? iMX8m plus? Up until now, I’ve been able to get most things to work, although I had some trouble with CAN since I couldn’t get it to load the can-dev lib as specified in the example, but I haven’t tried too much with that. I don’t have any actual calls for GPIO statements in my code yet,. as that was the next step.

Even worse is I can’t seem to get back to where I was beginning yesterday, where I could compile and deploy my code to the target system. If I pull the gipod.h out and remove the lgpiod from the linking I was able to get to the debugger on the target system. But now it appears it can’t connect because the container is wrong? Please see the above statement.

If you have any other suggestions to get this running again, I’d appreciate it.

Thanks,
Steve

HI @lucas_a.tx
I went back though my docker checks to verify everything is working, and this is where things get weird. Under Configure Build Environment for Torizon Containers | Toradex Developer Center
it says the return for this command “docker run --rm -it arm64v8/debian arch” should be only “aarch64”, but when I run it, I get that, but also some pretext:
docker run --rm -it arm64v8/debian arch
WARNING: The requested image’s platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested
aarch64
Which is what I am seeing when I try to run debug my target. Is this a clue? What would cause this? I didn’t get this originally, I’m pretty sure.

Steve

Hi @Evets ,

Yes, I am aware of the need for rebuilding of the SDK, and I do it quite often. And yes, I have libgpiod-dev:arm64 in the extension under “Custom Properties/devpackages” and have had that since the beginning. I still can’t get it to find the gpiod.h file.

That’s strange. If you did all of this and gpiod.h still can’t be found then something could be wrong with the extension itself, with Docker, with the SDK container or even with the Dev containers extension. Can you send a screenshot of your entire VSCode window when the gpiod.h: No such file or directory error occurs, and with the extension settings being shown?

I have to ask, are you using the same target as I have? iMX8m plus? Up until now, I’ve been able to get most things to work, although I had some trouble with CAN since I couldn’t get it to load the can-dev lib as specified in the example, but I haven’t tried too much with that. I don’t have any actual calls for GPIO statements in my code yet,. as that was the next step.

I deployed the sample gpiod app I mentioned before on a Colibri iMX8X running TorizonCore 5.7.0, but all the procedures in the extension should be the same as on a Verdin iMX8M Plus, given that both SoMs are ARM64.

I went back though my docker checks to verify everything is working, and this is where things get weird. Under Configure Build Environment for Torizon Containers | Toradex Developer Center
it says the return for this command “docker run --rm -it arm64v8/debian arch” should be only “aarch64”, but when I run it, I get that, but also some pretext:
docker run --rm -it arm64v8/debian arch
WARNING: The requested image’s platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested
aarch64
Which is what I am seeing when I try to run debug my target. Is this a clue? What would cause this? I didn’t get this originally, I’m pretty sure.

This warning message appears when building a docker image with a different architecture than the host system, which is expected when trying to build containers designed for ARM systems on your host machine, which is x64. We do this to build, through emulation, the ARM containers that will be deployed to your Verdin iMX8M Plus, and it shouldn’t be a cause for concern, at least not this message by itself.

Best regards,
Lucas Akira

Hi @lucas_a.tx ,
OK, I played around a bit with an Hello World! example code. Initiallly, I had the same problem. But I changed a few settings in the Torizon extension, and now it is finding the gpio.h file and compiling. At this point, I don’t know why it is working. I added in the devices, the /dev/gpiochip0-5 (one per line), and then it started working. I did the same to my other project, but there is no difference, it still fails to build. I’ve even added the additional libraries i needed for the other build to the working one and it still works.

in doing a comparison between the builds, the only thing I thought was a bit weird, was in the settings.json file this line was present under “files.associations”:, which is a bit weird:
“gpiod.h”: “c”. My other project has this under “files.associations”:
“limits”: “cpp”,
“type_traits”: “cpp”
and nothing with gpiod.h

Also, my other project is a C++ project not a C project. Could this be the issue?
Also, can you outline the specific settings in the configuration that affects the container that gets built? As a work around, can I point to the working container as a starting point and have it work or will it not work because it’s a C project?

The project that isn’t working is below.

Steve

Hi @Evets ,

OK, I played around a bit with an Hello World! example code. Initiallly, I had the same problem. But I changed a few settings in the Torizon extension, and now it is finding the gpio.h file and compiling. At this point, I don’t know why it is working. I added in the devices, the /dev/gpiochip0-5 (one per line), and then it started working. I did the same to my other project, but there is no difference, it still fails to build. I’ve even added the additional libraries i needed for the other build to the working one and it still works.

Good to know that you managed to get your code working by creating a new project!

Also, my other project is a C++ project not a C project. Could this be the issue?
Also, can you outline the specific settings in the configuration that affects the container that gets built? As a work around, can I point to the working container as a starting point and have it work or will it not work because it’s a C project?

I don’t think this is causing the issue, because my gpiod test project made in C works fine, and its settings.json only has these lines:

{
    "torizon.configuration": "debug",
    "torizon.appfolder": "appconfig_0"
}

The last image you posted shows that with your non-working project VSCode isn’t connected to a dev container, and so it can’t really find the packages added in devpackages. In fact, the extension isn’t being initialized correctly: see the Torizon: Initializing... message at the bottom of the window. That’s what is causing the problem: for some reason the extension can’t start correctly when opening your non-working project.

If you want, you can send the source code of your project so we can try to run it on V2 (ApolloX). If don’t wish to make it public you can send it to our support email instead (support@toradex.com).

Best regards,
Lucas Akira

HI @lucas_a.tx ,
I can’t send any code as that is company policy. I will try a few more things to see if I can narrow it down more. Another thing I know is that even though it’s a makefile project, it comes up quite often (like every time I rebuild the sdk), asking about configuring cmake, which it isn’t and thus it has a setting “cmake.confgureOnOpen”: false. My settings.json looks like this:

{
“torizon.configuration”: “debug”,
“torizon.appfolder”: “appconfig_0”,
“files.associations”: {
“limits”: “cpp”,
“type_traits”: “cpp”
“gpiod.h”: “cpp”
},
“cmake.configureOnOpen”: false
}
Is there any way you can tell me what triggers putting in the gpiod.h file to the container? It just seems there there is some weird combination that is causing the issue here.

As for the container build issue, I briefly see a red line go by when building the sdk, but I can’t see what it is as it goes by too fast and it just says there is an “unknown error”, and there is no history at that point that I can look back to.

Thanks,
Steve

P.S. After I rebooted my computer, Docker no longer has any images or containers showing. I have no idea what happened.

@lucas_a.tx ,
The error was that it decided it couldn’t write to the target directory. The directory was for some reason owned by root, and also under work in the local file it had an additional directory and executable which was old, so I deleted it. But it still will not pull in the gpiod.h file. If I comment that out, it compiles and runs just fine and I can step through code.
I made the c_cpp_properties.json files match as well as settings.json, extension.json and tasks.json. Launch.json and torizon-vscode-settings.yaml files match except for the exe names. The only real differences now are the docker containers and config.yaml which has name and key differences.

Hi @lucas_a.tx
I figured out the problem. It was using another compiler, (aarch64-linux-gnu-g++) not the default one, (aarch64-linux-gnu-cpp).
However, when I tried to link my program, it gave me this error:

aarch64-linux-gnu-cpp: fatal error: too many input files

Why is there a limit here?

Steve

I changed it back to using the g++ version and took a look at the includes that were in the original makefile. There were things that didn’t need to be there. And then it found gpiod.h. Not sure why that made a difference.

Steve

Hi @Evets ,

Sorry for the delay in replying.

If I understood everything correctly, you managed to solve your initial issue i.e. gpiod.h not being found, and you now trying to figure out what caused it, is this correct?

I believe the header file wasn’t being found because of what I said previously: Given that your first project wasn’t connected to the dev container, VSCode wasn’t inside the environment that has the libraries defined in devpackages. As for why the project wasn’t connect to the dev container in the first place, it is difficult to know for sure without more info.

Keep in mind that when you open a C/C++ project folder on V1 of the extension you aren’t connected to the dev container right away, you have to click on a pop-up message prompting you to connect to it.

If your initial problem is solved, can you mark the relevant post as the solution? Otherwise feel free to reply back.

Best regards,
Lucas Akira

Hi @lucas_a.tx ,
To be perfectly honest, I don’t know why the gpiod.h wasn’t there when I compile. Because when I backed out my changes that I thought made it work, it still worked.
It could be related and is related to an include file that defined some things, that might have affected the compiler name, but I don’t understand when I went back to what I had, why the problem didn’t return.
I am pretty sure that the extra includes caused the issue, so not a normal thing for probably any one else.
I will say, it is not clear as to what items in the torizon extension affect the torizon container that the app runs in, and what affects the compiling mechanism/local container on the build machine. It seemed pretty straight forward for SPI, but gpio wasn’t the same, and now I’m having issues with CAN which I did have working where I could execute CAN commands, but now they aren’t found. I’m putting in another ticket for this. CAN information on your site seems very spotty and only talks about really working with python and command line.

Steve