I am using a device-tree file for gathering pin statistics on the BBB with the am335x. For instance:
0x094 0x2f /* P8.08 GPIO2[3] in */
How did they come to the conclusion that 0x094 should be used in this context within the DTS file? Is the second hexadecimal value, 0x2f, meant for input only or is this a normalcy in DTS for input files?
I am studying the TRM now and trying to conceive exactly how the source code writers came to these definitive hex values for specific pins allocated to the headers of the BBB from the am335x.
Seth
P.S. Any recordings, papers, or knowledge would be much appreciated. I am still trying to build around a specific library and coming up short on knowledge of DTS and gathering data from TRMs.
more context from the .dts file would be necessary to determine what 0x094 is pointing to.
I’ve found the macros in the .dts and .dtsi files maddening. Also, I’ve been unsatisfied that comments are the only thing pointing to a P8 or P9 pin.
to address the macro confusion, I decided to decompile the .dtb file rather than use the .dts and .dtsi files… At least the decompiled file is pure device tree syntax.
fwiw… I’ve determined that lots of mapping detail is not in the device tree, but in the ‘c’ code of the kernel source (yet to be demonstrated)… My project involved determining the EGPIO bit in r30 and r31 assigned to the P8 or P9 pin… I found no such data in the device tree nor in the /sys data which I believe now are only as detailed as the device tree data. My next step is to download the kernel source and look there (fun!).
I was reluctant to conclude that the kernel source is doing such mapping, and I have not yet demonstrated that it is. Why use both? some mapping in the device tree, and some in the kernel source seems to violate the whole reason for the device tree.
BTW… just a guess, but the second value ‘0x2f’ is likely the mode of the pin, which is a level of mapping… but suppose the mode is pruout, what EGPIO bit is assigned to the P8 pin?
if you decompile the .dtb file, you will at least see consistent addresses per pin, and not have to rely on comments for the mapping.
good luck.
gomer
Edit: @lranders saved me a lot of work… mapping is not in the kernel source, but by hardware (ball number) … there is a canonical signal name per p8 and p9 header which can be used on the schematic (BBB_SCH.pdf) to find the ball number… then look up the ball number in the datasheet (https://www.ti.com) which will have which PRU and what bit number for EGPIO.
I thank you, sir. I have been searching the TRM and will be looking around in the SRM too.
I found an article on how one fellow achieved to think that subtracting 0x800 from the am335x BBB header hex value is necessary.
So, if it was above 0x800, which he thinks that it should be that way (above the value of 0x800), one would basically subtract the 0x800 value from the current, workable value:
0xF78 - 0x800 = 0x778 (and yes, I used a calculator)…
I do not think that is correct for some reason…
Anyway, that is what the calculator states. So, you think that the mapping is done in the kernel. That is interesting. I guess I can test it too… I actually have a freshly derived and built kernel.
The kernel I built is not what I am using now on the BBB and I think before time, beagleboard.org people were not in the kernel yet with this kernel I am using now…
I am using 4.19.x and I am pretty sure that the .org had not performed the necessary steps to get their builds and other bindings into the kernel at that point in time.
Seth
P.S. Thank you for any other ideas you have. I have checked in /sys/class/gpio/* and in /dev/* but I have not come across any real data that can be utilized.
That works. My next question has to do with the builder of the source. I guess using the addresses of the pins may work. I am not sure yet, i.e. as they did not use the PRU pins on the source DTS file within the build…
So, testing will ensue.
I may be going about things incorrectly. I ran out of pins that were already allocated via their DTS because I thought I needed to use the PRUOUT and PRUIN pins and their addresses and not the GPIO equivalents of addresses.
See:
0x094 0x2f is a GPIO pin made for Input only, e.g. for a simple switch. So, when the input gets a notification of being switched, the rest of the source makes the center point and/or gantry know about where it is located.
I figured I needed to make the PRU inputs available for the build via DTS files and not use the basic GPIO pins and the addresses of the GPIO pins. Now, I just do not know…
Seth
P.S. Anyway, thank you…I know now how to address this concern because of your instruction.
For that snippet of DTS, why would the source makers of the files and their personal DTS use 0x034 instead of 0x34?
For instance, here is their snippet: 0x034 0x07
And that is supposedly supposed to be a GPIO output pin and/or P8_11.
I am trying to figure out the connection from/to DTS and this source. I will be testing this source some more and see how far I get…
In the meantime, if you would, please try to describe to me why they use aforementioned trail of 0x with the extra 0 as in 0x034. Thank you for any guidance you can provide.
just a guess, but if some of the pins were greater than 0xff, then they would need three positions at least… 0x034 and 0x34 are equal, but might LOOK better in code if they lined up vertically… again, just a guess
All the fancy macro stuff hides the simple truth that you’re really just poking a value into a register.
All the AM335x PINMUXING is controlled by the System Control Module (SCM)
as described in the TRM you have supposedly been looking at. You want page 1459.
The interesting address offset starts at 0x800 and there’s one for each of the pins in question.
So when you see 0x034, that really means poke value into 0x834.
Unfortunately, they found no space in the 5000+ pages to describe the PIN_MODE,
so for that you need a separate PDF; the AM3358 Sitara Processors Datasheet, page 22.
Putting that information together, it should be easy to figure out both the offset and value.
That is the last thing you want to do is bypass the kernel management. With the single core SoC it was not an issue. Multi core its not so good.
The key part that is missing is the original .syscfg file that is generated by Ti’s sysconfig tool. It is way too time consuming and leads to head aches trying to recreate it.
It writes directly to the register, bypassing the kernel management, kernel needs to control all the low level access.
Bypassing the kernel can possibly introduce race conditions or even resource conflicts. Shortly, more bad than good is the bottom line regarding directly changing register values.
Poke around using devmem2 and you can easily break the system.
The numerical values in those links are the actual register addresses.
If its not exposed in the file system the kernel is not managing it. The stuff managed by the kernel directly is exposed /class/pwm/… that is from the device tree making the link with the kernel.
First your find the signal you want on P8/P9,
then you trace it back to the processor ball,
then you go into the AM3358 datasheet and find the PIN_MODE you want
and lastly you go to the PINMUX register for the pin in question.
Subtract 0x800 and you have the number you want to input into your device tree.
I thought there was a sensible answer. I really appreciate everyone stepping forth to pitch in.
Subtract 0x800 and not Subtract FROM 0x800. Got it…and phew.
I was wondering about this fact.
So, P8.15 for instance has a ball number and sometimes it was listed in the DTS in specific files. Then, from that ball number, I find the pin-mode and then the pinmux register for the pin (P8.15).
So, if it is…wait.
On beagleg, do I even need to account for PRU pins or is that done behind the scenes in the source? Argh…
I just C & P a long list of data in DTS format, used it to account for pruin and pruout on the pins in question. I then grabbed the data register muxing in hex format and applied it to the file in question.
So, this is not what I need to be doing. For instance, P8.15:
first, I am totally ignorant about ‘beagleg’… what is that?
second, on BBB finding the pru and egpio values is simple: config-pin -i P8_15
debian@bbb21:/dev/shm$ config-pin -i p8_15
Pin name: P8_15
Function if no cape loaded: gpio
Function if cape loaded: default gpio gpio_pu gpio_pd gpio_input qep pru_ecap pruin
Function information: gpio1_15 default gpio1_15 gpio1_15 gpio1_15 gpio1_15 eqep2_strobe pru_ecap pru0_in15
Kernel GPIO id: 47
PRU GPIO id: 79
debian@bbb21:/dev/shm$ ^C
from this you can see that P8_15 is attached to pru0 egpio bit 15
on the BBAI, which is my real goal, config-pin is not there, and I’m told that you can’t change mode on a running system without regretting it.
so on BBAI all pinmux configuration must be the default … which means device tree modification… I was using the BBB platform b/c it is better documented (at least the SRM)… now I have the deterministic calculus to map out the the egpio / pruX / prY values that I need to drive the PRU on the BBAI.