In my quest to use the GPT1 timer on my colibri i.MX7 module, I am looking at accessing its registers which are located (according to the NPX doc and the device tree) at 0x302d0000 and beyond.
Access is required from an application that I write with Visual Studio Code with the Torizon extension.
The first one was suggested by jeremias.tx (in another post regarding GPT1) and is rather informative but this example does not compile in my application due to the #includes, I probably need to install an SDK etc. And there is perhaps also a problem with the fact that running within a container shields the application from the ‘real’ memory ? (like it is for e.g. TCP/UDP ports).
The second method seems feasible except that one needs to be root in order to open /dev/mem.
So my immediate question is: How can I make my application/container execute as root ?
In a broader perspective, any kind of suggestion of how to read/write I/O registers from my application would be welcomed…
How can I make my application/container execute as root ?
For our extension when you create a project it asks for a username. This username is the user that is used inside the container at runtime. You can change this via the username field in the configuration.
Sometimes things are so easy
However, even being root I could still not open /dev/mem. While googling, there seem to be further restrictions in order to avoid user programs having access to the physical memory. So this is probably not the way to go when I want to access I/O.
Any suggestions on how to do that another way would be welcome !
Another question concerning the change of user for the container : changing from ‘torizon’ to ‘root’ did work because they have the same password. But I was wondering where the password could be changed. When you create a new application, it asks for both user name and password but I could only find a ‘user name’ field in the Torizon extension once the application is already configured.
Another question concerning the change of user for the container : changing from ‘torizon’ to ‘root’ did work because they have the same password. But I was wondering where the password could be changed. When you create a new application, it asks for both user name and password but I could only find a ‘user name’ field in the Torizon extension once the application is already configured.
One thing to understand is that the user in the container is separate from the user outside of the container.
Inside the container the torizon and root user are password-less. These users are different from torizon and root` outside of the container.
Furthermore when you create a project with the extension only a username is required. This username being what user to use inside the container. Are you perhaps talking about the username/password required when adding a device? This username/password is for accessing the device via SSH, and is unrelated to your project and container.
OK, so what could I do so that my application that runs inside the container has sufficient rights to open /dev/mem of the actual machine ?
(I did add /dev/mem to the “devices” list in the Torizon extension)
Yes, that’s probably the one…
Meanwhile, it is very well possible that this way, trying to use /dev/mem, is a dead end due to possible other restrictions for its use as I mentioned earlier. So any suggestions for other way to access the GTP register are still welcome…
Can you please give us more details on your use case so that we can understand if there could be any alternatives for GPT that you could use. If you cans share as much information as possible from what you’re trying to achieve this would be great
I need to use GPT0 in order to divide an external clock (4MHz) to a lower frequency which is then output on a pin. This output signal is then used to start ADC conversions (at e.g. 100kHz) that are handled by the M4 core (another subject I did not yet fully explore ). The fact to use the external source is important since the sampling time shall be related to this 4MHz signal that is used to modulate a signal that is sampled afterwards (the details are a bit complicated…)
As per I/O mux of the Colibri i.MX7D, SODIMM pin 60 is dedicated to GPT1.CLK and pin 93 is GPT1.COMPARE. I already “liberated” these pins from the standard function by modifying the device tree (see my post GPT1 )
Although nothing is fixed, I already have our custom motherboard on my desk, i.e. it will not be easy to re-map the 4MHz input and frequency programmable output signals to other SODIMM pins.
So far, I have been looking at different snippets of code which often appear to come from kernel source and require specific #includes which I do not have.
One of my other fears is that GPT1 is already used by the Linux kernel itself but I do not have the faintest idea of how to find this out. The only thing I know is that in the Colibri device tree, there are definitions for gpt1 … gpt4 in imx7s.dtsi and gpt1 is the only one that does not have the line status = "disabled".
For me this either means that it already should appear as a device under Linux or that it is reserved.
I have also tried to find a definition for the device tree syntax concerning gpt. How do you specify that the CLK and COMPARE pins mentioned above are associated with the device ?
Hopefully this information will give you some better idea of what I want to achieve…
You mention that you modified your device tree but you didn’t share with us the files. Would you be able to share it with us? You can use share.toradex.com to upload them if needed.
Can you also please share with us the output of the following commands?
dmesg
zcat /proc/config.gz
You can save the output of these commands as text files and then upload them together with the device tree.
Usually, it’s done when you define the nodes on the device tree. We’ll have a look on what you’ve done and suggest modifications if we think it might be necessary.
I uploaded both the device tree files and the output of the two commands you asked for here.
The starting point of the device tree is the file imx7d-colibri-emmc-interferometer.dts. This will then include the other ones (maybe there are files which are not used but I think I pretty well limited the files to the minimum set). Any other file which is usually outside the dts-arm32 folder has not been modified are are identical to the one in the toradex Git repository.
After looking at your device tree, some things came to my attention.
On the imx7-colibri-interferometer.dtsi I’d recommend you to remove the following line as it should be added on the iomuxc and not there on the gpt1.
106 &gpt1 {
107 status = "okay";
108 // do something with "gpt1-grp" that I defined under iomuxc......??
109
- 110 MX7D_PAD_LCD_DATA02__GPT1_CLK
111 };
Also, just for confirmation, do you use any overlay that enables the lcdif interface? The pins that you want to use for GPT are in conflict with pinctrl_lcdif_ctrl and this may be causing additional issues.
Moreover, you create pinctrl_gpt1 but this group seems to not be used anywhere else again. Is this right? Therefore, you just created the control group but has not applied it anywhere else.
Finally, as suggested in your other post, we don’t have that much experience with GPT. Did you also ask about it on community.nxp.com? You may find more examples there and help from people using the GPT function on iMX7 modules.
You’re completely right. I just put it there while looking around on how to configure the GPT. The tree doesn’t even compile like this. Sorry for the confusion !
This is also one of the trials. I suspect I need something like this so that I can specify in the &gpt1 node which I/O is associated with it (just like one creates a ‘chip select’ group that is used in ecspi node. But I cannot find anywhere what the syntax of a gpt node is supposed to be. If you have any pointers in that direction, it would help.
No I did not yet post any request but I did look around quite a bit on the forum. And that’s where I come back to the beginning of this post again: I found, just like at your site, examples of GPT coding in kernel space or at least with an SDK installed.
So today I’m stuck on how I can access the timer configuration registers from within a container. If I could do that, I would not have any trouble writing a “driver” myself (I’m used to configure all kinds of hardware, but not on Linux and in Containers.
Maybe this will end up as a task for the M4 core, which will probably be much easier…
You don’t need to worry about that, we’re here to help
I’ll be checking if I can find anything useful for you in that sense but I strongly recommend you also post it on the NXP Community and share the link here so that more people can help you out.
If you think that the M4 Core may fit your final goal, you can have a look on the following sites:
This may not be what you expected to do initially but it can be useful nevertheless.
I have some problems posting on the NXP forum, I have an account but I have to confirm my e-mail before being able to post, and the confirmation link doesn’t seem to work… I’ll try later and keep you up to date.
One of the things I’m afraid of when I read some posts and also the i.MX Linux manual is that e.g. in the manual (section 3.3 “Timer”) it is said that either the EPIT or GPT is used by the Linux kernel. If this appears to be GPT1, I can simply forget about using it! Is there any way that you can find out whether this is the case in the Torizon kernel?
I certainly am going to use the M4, because I need it for fast data acquisition (another subject that I still have to dive in…)
Please keep us updated if you’ve managed to do it.
The TorizonCore images for iMX7 modules use our mainline kernel. Therefore, they are somewhat different from the NXP one usually referenced as downstream but I can’t guarantee that they’ll differ on this specific topic at the moment. Can you please share with us the number/version of the manual that you refer to?
Ok! Please feel free to post any M4 related questions also here in the community
Best regards,
I did manage to post my questions. No answers yet… but I 'll keep you informed.
It appears that I used “Rev. 0, 03/2016” of the “i.MX Linux Reference Manual”. So this is quite old…
I found a newer (latest?) version: Rev. LF5.15.32_2.0.0, 30 June 2022 in which section 3.3. is not at all about timers! It appears that the section I referred to is now under 2.1.3. and table 5 clearly states that
GPT is configured to generate a periodic interrupt at a certain interval (every 10 ms). Used by i.MX 6 to go into WFI mode.
Used by i.MX 6 and i.MX 7
The only hope is that it is not GPT1… In table 6, the source file drivers/clocksource/timer-imx-gpt.c is mentioned. So if you have access to this file in Toradex’s Torizon implementation, it is perhaps possible to confirm that GPT1 is used by Linux or not…
No answer from NXP yet. I decided to give up for now. The project must go on.
The solution I’ve chosen to get a programmable output frequency is the use of a small PIC18F microcontroller (based on what I had laying around) using two counters and an I2C interface in slave mode. Not want I planned but at least I control everything and it works.
Best regards and many thanks for your support on this topic, even though we didn’t get it solved !
Jeroen
