device tree bindings for EGPIO : bbai

General Discussion
,
1

I’m digging into device tree for bbai and have been unable to find something more definitive than comments that bind the egpio bit to the header. There are at least two instances where the comments assign the same egpio bit to two different (P8) headers.

The author of Moving to the BeagleBone AI — BeagleBoard Documentation , seems to have found the same inconsistency. there are 10 (ten) instances on the P8 header where this occurs. ( you have to interpret the reference to ‘PRU2’ to be ‘pr2’, and understand that the first row of data is mixed into the column headers )P

here are the four lines from src/arm/am572x-bone-common-univ.dtsi that I am referring to:
BONE_PIN(P8_36, pruout, P8_36A( PIN_OUTPUT_PULLDOWN | INPUT_EN | MUX_MODE13) P8_36B( PIN_OUTPUT | MUX_MODE15 )) /* vout1_d10.pr2_pru0_gpo7, vin2a_d0.off /
BONE_PIN(P8_06, pruout, P8_06( PIN_OUTPUT_PULLDOWN | INPUT_EN | MUX_MODE13 )) / mmc3_dat3.pr2_pru0_gpo07 /
BONE_PIN(P8_05, pruout, P8_05( PIN_OUTPUT_PULLDOWN | INPUT_EN | MUX_MODE13 )) / mmc3_dat2.pr2_pru0_gpo06 /
BONE_PIN(P8_38, pruout, P8_38A( PIN_OUTPUT_PULLDOWN | INPUT_EN | MUX_MODE13) P8_38B( PIN_OUTPUT | MUX_MODE15 )) / vout1_d9.pr2_pru0_gpo6, mcasp4_aclkx.off */

I’m acknowledging ‘newbie’ status here, and hoping someone has already figured this out.

debian@bbai01:~$ cat /etc/dogtag
BeagleBoard.org Debian Bookworm IoT Image 2023-10-07
debian@bbai01:~$ uname -a
Linux bbai01 5.10.168-ti-r72 #1bookworm SMP PREEMPT Sat Sep 30 03:40:45 UTC 2023 armv7l GNU/Linux
debian@bbai01:~$

thanks.
gomer

2

I’m not sure if I’ve understood your question correctly…

But please look into the schematic::
P8.36 is connected to ball number D7 and F2 (therfore A and B), while P8.06 is only connected to ball AC3.

Then take a look at the AM5729 data sheet:
on page 48 you can see that ball AC3 acts as pr2_pru0_gpo7 in MUXMODE 13, and the same is true for ball D7 (on page 79).

3

Thanks for the links to new documentation, I haven’t yet studied them. If I understand you correctly, the ‘ball’ is tied to the egpio bit, and the device tree references the ball. That is the link? Yet the ‘ball’ is not referenced in the DT any more than the egpio bit, except in comments…

is there some piece of code that ties the ‘ball’ to the DRA7XX_CORE_IOPAD? at least the IOPAD is in code in the DT.

I’m convinced that I must have missed some macro in the code that makes sense of the following lines that reference the ‘ball’. Can you assist?

debian@bbai01:/dev/shm$ grep AC3 dts_flattened.txt
src/arm/bbai-bone-buses.dtsi 2 : include/dt-bindings/board/am572x-bone-pins.h 3 : #define P8_06(mode) DRA7XX_CORE_IOPAD(0x3790, mode) /* AC3: mmc3_dat3 /
src/arm/am572x-bone-common-univ.dtsi 3 : include/dt-bindings/board/am572x-bone-pins.h 4 : #define P8_06(mode) DRA7XX_CORE_IOPAD(0x3790, mode) / AC3: mmc3_dat3 /
src/arm/bbai-bone-buses.dtsi 2 : src/arm/am572x-bone-common-univ.dtsi 3 : / P8_06 (ball AC3) gpio7_2 */
debian@bbai01:/dev/shm$

The following lines (repetitive) link an ‘IOPAD’ to what i assume is a header pin, without specifying which pin… I’m trying to understand the DT linkage (bindings), without relying on comments. thanks for your help. Perhaps the datasheet ties the ‘IOPAD’ to a ‘ball’ which is linked to the egpio pin.

debian@bbai01:/dev/shm$ grep 0x3790 dts_flattened.txt
src/arm/am5729-beagleboneai.dts 1 : src/arm/dra74x-mmc-iodelay.dtsi 2 : DRA7XX_CORE_IOPAD(0x3790, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) /* mmc3_dat3.mmc3_dat3 /
src/arm/am5729-beagleboneai.dts 1 : src/arm/dra74x-mmc-iodelay.dtsi 2 : DRA7XX_CORE_IOPAD(0x3790, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) / mmc3_dat3.mmc3_dat3 /
src/arm/am5729-beagleboneai.dts 1 : src/arm/dra74x-mmc-iodelay.dtsi 2 : DRA7XX_CORE_IOPAD(0x3790, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) / mmc3_dat3.mmc3_dat3 /
src/arm/am5729-beagleboneai.dts 1 : src/arm/dra74x-mmc-iodelay.dtsi 2 : DRA7XX_CORE_IOPAD(0x3790, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) / mmc3_dat3.mmc3_dat3 /
src/arm/am5729-beagleboneai.dts 1 : src/arm/dra74x-mmc-iodelay.dtsi 2 : DRA7XX_CORE_IOPAD(0x3790, (PIN_INPUT_PULLUP | MODE_SELECT | MUX_MODE0)) / mmc3_dat3.mmc3_dat3 /
src/arm/bbai-bone-buses.dtsi 2 : include/dt-bindings/board/am572x-bone-pins.h 3 : #define P8_06(mode) DRA7XX_CORE_IOPAD(0x3790, mode) / AC3: mmc3_dat3 /
src/arm/am572x-bone-common-univ.dtsi 3 : include/dt-bindings/board/am572x-bone-pins.h 4 : #define P8_06(mode) DRA7XX_CORE_IOPAD(0x3790, mode) / AC3: mmc3_dat3 */
debian@bbai01:/dev/shm$

gomer

4

significant portion of mystery resolved:

There seems to be a 1:1 relationship between ‘ball’ and the address used in
DRA7XX_CORE_IOPAD which is documented in the datasheet that @frawi provided. BUT DRA7XX_CORE_IOPAD uses PHYSICAL address (PA) (lower 4 bytes) and the datasheet uses an offset from some internal address…

subtracting 8K from the lower 4 bytes of the PA gives you the address used in the datasheet. great, progress. This much is pretty certain and documented in the ‘CONTROL MODULE’ chapter of the TRM (previously ignored by me)…

reference table 18-1617 (one example) on page 4872 (TRM) … it shows BOTH the PA used in the DT and the offset used in the datasheet. it also has the MUX signals coded into the lowest 4 bits of this register (3:0) complete with ICCS/PRU/bit … so … the TRM doesn’t use header pin designations, but it does have the PA which is in the DT (lower 4 bytes).

The DT does link the PA to the header pin, so that sort of answers my question.

except:
DRA7XX_CORE_IOPAD is a macro defined here:
#define DRA7XX_CORE_IOPAD(pa, val) (((pa) & 0xffff) - 0x3400) (val)
‘AND’ PA and 0xFFFF strips off the high 4 bytes (simple enough), but what is this MAGIC 0x3400 being subtracted from from the result?
( macro definition is in include/dt-bindings/pinctrl/dra.h )

here is an even more cryptic macro from src/arm/am572x-bone-common-univ.dtsi …
/* macro: BONE_PIN( , <mode_name>, <register_value_macro(s)> */
#define BONE_PIN(XX,ZZ,QQ)
XX####ZZ##pin: pinmux##XX####ZZ##_pin { pinctrl-single,pins = < QQ >; };

this seems to resolve some of what appeared to be ‘orphaned’ references, but not all of them:
simple example:
BONE_PIN(P8_03, pruout, P8_03( PIN_OUTPUT_PULLDOWN | INPUT_EN | MUX_MODE13 )) - resolves to -
P8_03_pruout_pin: pinmux_P8_03_pruout_pin { pinctrl-single, pins = <P8_03( PIN_OUTPUT_PULLDOWN | INPUT_EN | MUX_MODE13 ))>; }

there is a reference to ‘P8_03_pruout_pin’ in pinctrl-5 (phandle) here:
P8_03_pinmux {
compatible = “bone-pinmux-helper”;
status = “okay”;
pinctrl-names = “default”, “gpio”, “gpio_pu”, “gpio_pd”, “pruin”, “pruout”;
pinctrl-0 = <&P8_03_default_pin>;
pinctrl-1 = <&P8_03_gpio_pin>;
pinctrl-2 = <&P8_03_gpio_pu_pin>;
pinctrl-3 = <&P8_03_gpio_pd_pin>;
pinctrl-4 = <&P8_03_pruin_pin>;
pinctrl-5 = <&P8_03_pruout_pin>;
}; ( src/arm/am572x-bone-common-univ.dtsi )

would still like to run down ‘pinmux_P8_03_pruout_pin’ so far, no joy.

gomer

1 Like
5

I’ve not dug deeper into this yet but the first CTRL_CORE_PAD_x register is at address 0x4A00 3400 (CTRL_CORE_PAD_GPMC_AD0, TRM page 4226)
Perhaps the following CTRL_CORE_PAD_x registers refer to this as the base address?

1 Like
6

very useful observation, that address is a fine candidate for a descriptive symbol.

thank you
gomer