J721S2XSOMXEVM: Toggling GPIO's on GESI board from Linux Kernel

Part Number: J721EXSOMG01EVM

Tool/software:

First how we have things setup.

Using ti-processor-sdk-linux-adas-j721e-evm11_00_00_00_08. Built kernel using YOCTO, burned to SD card and booted. Removed to soft links to all other processors executables except for mcu1_0 which I left running ipc_echo_test.

Have the EVM main board wtih a J721ESOM as well as the Quad Ethernet and GESI expander baord.

We have sucessfully use the R5F processors to acess several pins on the GESI board as GPIOs for debugging and other uses.

We are now trying to control some of the GPIOS from the Linux Kernel.

I have added some GPIO muxing to the k3-j721e-evm-exp-board.dtso overlay file as follows.

   &main_pmx0 {

       /* GPIO_18 (pin PIN_PRG1_PRU0_GPO17 (Normally for GESI it is MCAN5_TX) 
          -> AJ21 (J13 pin 1 ) -> AJ21*/
       gpio0_18_pins_default: gpio0-18-default-pins {
          pinctrl-single,pins = <
                J721E_IOPAD(0x4C, PIN_INPUT, 7) 
          >;
       };
       /* GPIO_19 (pin PRG1_PRU0_GPO18 (Normally for GESI it is MCAN5_RX) 
          -> AE21 (J13 pin 2 ) -> AE21*/
       gpio0_19_pins_default: gpio0-19-default-pins {
          pinctrl-single,pins = <
                J721E_IOPAD(0x50, PIN_INPUT, 7) 
          >;
       };
       /* GPIO_26 (pin PIN_PRG1_PRU1_GPO5 (Normally for GESI it is MCAN6_RX) 
          -> AG21 (J11 pin 2) -> AG21  */
       gpio0_26_pins_default: gpio0-26-default-pins {
          pinctrl-single,pins = <
                J721E_IOPAD(0x6C, PIN_INPUT, 7) 
          >;
       };
       /* GPIO_53 (pin PIN_PRG0_PRU0_GPO10 (Normally for GESI it is SPI3_CS2) 
          -> AB25 (BP2 J5 pin 6) -> AB25*/
       gpio0_53_pins_default: gpio0-53-default-pins {
          pinctrl-single,pins = <
                J721E_IOPAD(0xD8, PIN_INPUT, 7) 
          >;
       };
    
       /* GPIO_80 (pin PIN_PRG0_PRU1_GPO17 (Normally for GESI it is SPI3_CLK) 
          -> AB25 (Motor Control  pin 24) -> Y25*/
       gpio0_80_pins_default: gpio0-80-default-pins {
          pinctrl-single,pins = <
                J721E_IOPAD(0x144, PIN_INPUT, 7) 
          >;
       };
};

Our uEnv.txt file has the overlay applied as shown below:

# This uEnv.txt file can contain additional environment settings that you
# want to set in U-Boot at boot time.  This can be simple variables such
# as the serverip or custom variables.  The format of this file is:
#    variable=value
# NOTE: This file will be evaluated after the bootcmd is run and the
#       bootcmd must be set to load this file if it exists (this is the
#       default on all newer U-Boot images.  This also means that some
#       variables such as bootdelay cannot be changed by this file since
#       it is not evaluated until the bootcmd is run.
psdk_setup_file=.psdk_setup
check_psdk_setup=load mmc 1:1 ${loadaddr} ${psdk_setup_file}

# Reset to the default environment
do_psdk_setup=env default -f -a; saveenv

# If not done previously, then reset to the default environment and indicate this by writing a file
# Also update the Linux hostname based on board_name
uenvcmd=if run check_psdk_setup; then echo "Already setup."; else run do_psdk_setup; mw.b ${loadaddr} 0 1; fatwrite mmc 1:1 ${loadaddr} .psdk_setup 1; reset; fi; if test "$board_name" = "j721e-sk"; then ; setenv args_all $args_all systemd.hostname=tda4vm-sk ; fi;

# Setting the right U-Boot environment variables
dorprocboot=1
name_overlays=ti/k3-j721e-evm-gesi-exp-board.dtbo

When booted I can look at the pinmux values for the GPIOs we want to use. They seem set to GPIO 0x08214007

However, The pins # seem off by one (GPIO0_18 is on pin 19?)

 cat /sys/kernel/debug/pinctrl/11c000.pinctrl-pinctrl-single/pins
registered pins: 173
pin 0 (PIN0) 0:? 11c000 00040007 pinctrl-single
pin 1 (PIN1) 0:? 11c004 00050004 pinctrl-single
. . .
pin 17 (PIN17) 0:? 11c044 00010004 pinctrl-single
pin 18 (PIN18) 0:? 11c048 08054000 pinctrl-single
pin 19 (PIN19) 0:? 11c04c 08214007 pinctrl-single
pin 20 (PIN20) 0:? 11c050 08214007 pinctrl-single
pin 21 (PIN21) 0:? 11c054 08214007 pinctrl-single
pin 22 (PIN22) 0:? 11c058 00050004 pinctrl-single
pin 23 (PIN23) 0:? 11c05c 00050004 pinctrl-single
pin 24 (PIN24) 0:? 11c060 00050004 pinctrl-single
pin 25 (PIN25) 0:? 11c064 00050004 pinctrl-single
pin 26 (PIN26) 0:? 11c068 00050004 pinctrl-single
pin 27 (PIN27) 0:? 11c06c 08214007 pinctrl-single
pin 28 (PIN28) 0:? 11c070 00050004 pinctrl-single
. . .
pin 53 (PIN53) 0:? 11c0d4 08214007 pinctrl-single
pin 54 (PIN54) 0:? 11c0d8 08214007 pinctrl-single
pin 55 (PIN55) 0:? 11c0dc 00010004 pinctrl-single

Then if I try to control one of the GPIOs, say GPIO_53, which is normally mapped to SPI3_CS2 and does not go through a selection mux. I don't see it change.

The gpio chips are as follows.

gpiodetect
gpiochip0 [1-0020] (16 lines)
gpiochip1 [1-0022] (24 lines)
gpiochip2 [3-0020] (8 lines)
gpiochip3 [5-0020] (8 lines)
gpiochip4 [42110000.gpio] (84 lines)
gpiochip5 [600000.gpio] (128 lines)
gpiochip6 [601000.gpio] (36 lines)
gpiochip7 [0-0048] (11 lines)
gpiochip8 [0-004c] (11 lines)
gpiochip9 [2-0020] (8 lines)

Chip 5 seems like it matches with main_gpio0 from the device tree (Address 0x600000)

gpioset -c 5 53=1  // Nothing changes on the scope we have connected to GESI Board J5 pin 6

I know some of the GPIOS go through muxes and have to be set with the expander GPIOS on the main board. I have the tried the GPIO_HOG in the device tree as follows by looking at the board(s) schematics.

&exp1 {
   // Enables MCAN4-7 if low rather then PWM signals
	p14-hog {
		/* P15 - EXP_MUX1 */
		gpio-hog;
		gpios = <12 GPIO_ACTIVE_HIGH>;
		output-low;
		line-name = "EXP_MUX1";
	};
   // Enables I2C 5 SDA and SCL on Gesi board if high
	p15-hog {
		/* P15 - EXP_MUX2 */
		gpio-hog;
		gpios = <13 GPIO_ACTIVE_HIGH>;
		output-high;
		line-name = "EXP_MUX2";
	};
   // Enables UART3 and some different MDIO signals when high
	p16-hog {
		/* P16 - EXP_MUX3 */
		gpio-hog;
		gpios = <14 GPIO_ACTIVE_HIGH>;
		output-high;
		line-name = "EXP_MUX3";
	};
};

I still cannot see any of the GPIOS toggle or change values.

Any help would be appreciated.  Below is a diagram showing our understanding of the EVM and the GPIOS we are trying to use.

  • Hi Randy,

    There should be a user LED on the EVM board. Can you confirm that can be toggled through Linux to check if any GPIO can be toggled?

    Regards,

    Takuma

  • There are no user LEDs that I can find. I am looking in the TDA4VM-EV users guide (spruis4e.pdf). Would you mind pointing me where the led is found?

    I did find a user LED 1 and 2 on the main carrier board. they are connected to the I2C expander #2. However, by default something is hogging these GPIOS so they can't be controlled.I belive that expander 2 is chip 1 on my system based on the output of gpioinfo below. (Although I don't understand how there can be 24 outputs when the chip only has 16?)

    gpioinfo -c1
    gpiochip1 - 24 lines:
    line 0: unnamed input
    line 1: unnamed input
    line 2: unnamed output consumer=fixedregulator-sd
    line 3: unnamed input
    line 4: unnamed input
    line 5: unnamed input
    line 6: unnamed output consumer=enable                             - This should be LED 1
    line 7: unnamed output active-low consumer=standby          - This should be LED 2
    line 8: unnamed input
    line 9: unnamed output consumer=MCASP/TRACE_MUX_S0
    line 10: unnamed output consumer=MCASP/TRACE_MUX_S1
    line 11: unnamed input
    line 12: unnamed input
    line 13: unnamed input
    line 14: unnamed input
    line 15: unnamed input
    line 16: unnamed output
    line 17: unnamed output
    line 18: unnamed input
    line 19: unnamed input
    line 20: unnamed output consumer=reset
    line 21: unnamed input
    line 22: unnamed input
    line 23: unnamed input

  • Hi Randy,

    Try following this E2E I just made:  [FAQ] J721S2XSOMXEVM: TDA4VL: How to toggle user LEDs on CPB board? 

    Regards,

    Takuma

  • Takuma,

    I appreciate the exercise that you specified above. Indeed the LEDs toggle on GPIO 22 and 23. However, there are a couple of issues here that I need to clarify.

    1.The device in the subject is not the device we have. We have a J721ESOM not a J721SXSOM.  I selected that by mistake and could not figure out how to change it. In my first post all the code I pointed to was the J721E which I thought would be a clue that I was working on that part not the J721s. Sorry for the confusion. Though they are very similiar boards.

    2. I now see that the GPIO Expander 2 has 24 outputs unlike expander 1 that has 16.

    3. So we can toggle LEDS now that I know to which GPIOS they are are connected. However, this does not help me figure out why I can't get the GPIO's I originally pointed out to work. Especially the GPIO0_53 which does not go through mux chip that I can see. Maybe I have the wrong chip or GPIO numbers. Please can you validate my findings from my first post?

    I will point out, in case you have forgotten from my first post, that we believe the GESI board to be connected and working since we can toggle the GPIOs when using the R5F processors and I can get the I2C5 bus to work on the GESI board from Linux using the arch/arm64/boot/dts/ti/k3-j721e-evm-gesi-exp-board.dtso file.

    Regards,

    Randy

  • Hi Randy,

    1. Understood, and my apologies. I don't have a J721ESOM, so would have to search around for one. Let me see if I can obtain and test.

    2. You are correct. There are a couple of GPIO expanders on the board. Expander-1 is 16 bits while Expander-2 is 24 bits.

    3. LED is mainly a check to make sure the method used can toggle the GPIO. As for GPIO0_53, I agree with you. I checked through schematics and I also do not see any mux, and the correct offset looks to be used for pinmuxing as well. gpiochip5 should be correct as well. 

    So far, everything looks to be correct. But to double check, I think there were mentions of GPIO hog being used in devicetree to set the GPIO state. When doing the hog, it should be possible to set a name for the GPIO line. Do you see gpiochip5's line 53 gets the GPIO name set in devicetree when running gpioinfo?

    Regards,

    Takuma

  • Yes, If I add a gpio-hog to GPIO 53 as shown below. It shows up as a consumer=GPIO_53_OUTPUT. However, the pin is still low

    &main_gpio0 {

        gpio0_53_in_hog {
            gpio-hog;
            gpios = <53 GPIO_ACTIVE_HIGH>;
            output-high;
            line-name = "GPIO0_53_OUTPUT";
            pinctrl-names = "default";
            pinctrl-0 = <&gpio0_53_pins_default>;
        };
    };
    line 50: unnamed input
    line 51: unnamed input
    line 52: unnamed input
    line 53: unnamed input consumer=GPIO0_53_OUTPUT
    line 54: unnamed input
    line 55: unnamed input
    line 56: unnamed input
  • Hi Randy,

    Could you use devmem2 or any other method to dump the following registers:

    • 0x0011C0D8 - PADCONFIG register for GPIO0_53
    • 0x00600060 - GPIO_DIR45 register (the direction register of the bank of GPIO with GPIO0_53)
    • 0x00600064 - GPIO_OUT_DATA45 register (the output value for the bank of GPIO with GPIO0_53)
    • 0x00600068 - GPIO_SET_DATA45 register (the register that sets the OUT_DATA45 value to high)

    Regards,

    Takuma

  • Sure, Here they are. 

    Read at address  0x0011C0D8 (0xffff955af0d8): 0x08214007

    Read at address  0x00600060 (0xffffb6a4f060): 0xFFFFFFFF

    Read at address  0x00600064 (0xffff98bf5064): 0x00000000

    Read at address  0x00600068 (0xffff7fbc9068): 0x00000000

    Something doesn't look right to me.

  • As a note. If I change just the Padconfig register using devmem2 w 0x08004007. then I can toggle the GPIO.  I don't know how to get the registers to this value just using devicetree.

    Also, please excuse my ignorance on this, but wouldn't GPIO0_53 be in bank 3? It seems like ther are 15 bits per bank so bit 15 would be in bank register 23 not 45?

  • Hi Randy,

    That is a good find. Clearing bit 21, which is the Padconfig register's TX_DIS bit, is probably what is allowing the GPIO to toggle. 

    We do not provide a macro for enabling/disabling this bit, but what the fix would look like would be a new macro in arch/arm64/boot/dts/ti/k3-pinctrl.h that defines a new TX_DIS_SHIFT, a OUTPUT_DISABLE macro, and or'ed with the PIN_OUTPUT and/or PIN_INPUT macros.

    By default, it looks like the TX_DIS bit is a 0 for J721S2 and J784S4, while it is a 1 by default for J721E, J7200, J722S SoCs. I will check internally to see how this bit has been handled in the past, but might be a bug in the SDK.

    Regards,

    Takuma

  • Yes, I did look though that file but did not want to touch anything until I heard back from you.

    Do the other registers, Direction, Out and set have any bearing on this? It seems like the Direction bits might be important but maybe they are set with the gpioset executable.

    Also, as noted in my reply above your last one I do think we are on Bank 3 not bank 4.  I read from register GPIO0_DIR23 (0x00600038) and I got the following

    Memory mapped at address 0xffff84cad000.
    Read at address 0x00600038 (0xffff84cad038): 0xFFDFFFFF, Shows bit 21 set to be an output (32 from banks 0 and 1, 16 from bank 2 and then 5 from Bank 3) 32+16+5 = 53

  • Another note: I still cannot toggle GPIO0_18 (MCAN5_TX/GPIO0_18) with the same settings. The input to the mux that the MCAN5_TX/RX goes through is pulled low which should select the MCAN as the output.

    Regardless, I have checked on the input side of the mux as well and that pin in not toggling even with the same settings I used for GPIO0_53.

    Maybe there is another mux point for that signal?

  • Hi Randy,

    Do the other registers, Direction, Out and set have any bearing on this? It seems like the Direction bits might be important but maybe they are set with the gpioset executable.

    These registers should get set when setting the value via gpioset.

    Also, as noted in my reply above your last one I do think we are on Bank 3 not bank 4.  I read from register GPIO0_DIR23 (0x00600038) and I got the following

    Ah, yes, I think you are correct. That is my mistake. 

    Maybe there is another mux point for that signal?

    Yes, for MCAN5_TX there is a mux on the GESI board.

    This is controlled by EXP_MUX1

    Regards,

    Takuma

  • Takuma,

    I believe I have everything set to allow the MCAN5_TX line through, GPIO hog for MUX1 set to low to select MCAN signals. I even measured MCAN5_TX on the INPUT side of the mux and could not see it toggling. I will try some more things to see if this is just another register setting problem.

    &exp1 {
       // Enables MCAN4-7 if low rather then PWM signals
    	p14-hog {
    		/* P15 - EXP_MUX1 */
    		gpio-hog;
    		gpios = <12 GPIO_ACTIVE_HIGH>;
    		output-low;
    		line-name = "EXP_MUX1";
    	};
    	
    	. . .
    };

  • Hi Randy,

    Ok, understood. Does the padconfig register (0x0011C038) content also look good?

    Regards,

    Takuma

  • It looks like the following:

    Though I need to double check the address to see if that is the correct one for GPIO_18

    devmem2 0x0011c038
    /dev/mem opened.
    Memory mapped at address 0xffffabd5c000.
    Read at address 0x0011C038 (0xffffabd5c038): 0x00010004

    However, GPIO8_18/MCAN5_TX pad config register is at address 0x00011C04C

    And it value is:

    /dev/mem opened.
    Memory mapped at address 0xffff8f383000.
    Read at address 0x0011C04C (0xffff8f38304c): 0x08214007

    I can then change it using devmem2 0x0011C04C w 0x08004007

    However I still can't toggle the GPIO0_18 with these settings.

    I can see that there is a GPIO HOG for MUX1 but I don't know how to read it value. I can measure it on the board and it is 0V (or low) which seems to be the correct value to select the MCAN signals on the MUX chip.

  • Hi Randy,

    My apologies. I looked at J721S2 instead of J721E datasheet for the PADCONFIG address. 0x00011C04C is the correct address. 

    Could you try setting bit 18?  So a value of 0x40007. The other bits that are set by default, bit 14 and 27, should not affect the GPIO toggle experiment, so you can keep them set or overwrite them.

    Regards,

    Takuma

  • Takuma,

    I did try writting that value to the pad control register. It didn't seem to make a difference. I can see that the ouput register is changing. I might need to just trace the signal(s) back to the main board and see if there is a connection issue. I don't think there is but I am out of ideas.

    Output register after setting GPIO0_18
    Memory mapped at address 0xffff9bfb5000.
    Read at address 0x00600014 (0xffff9bfb5014): 0x00040000

    Pad Control register

    devmem2 0x00011c04c w 0x00040007
    /dev/mem opened.
    Memory mapped at address 0xffffadd32000.
    Read at address 0x0011C04C (0xffffadd3204c): 0x08004007
    Write at address 0x0011C04C (0xffffadd3204c): 0x00040007, readback 0x00040007

  • Hi Randy,

    I am seeing that GPIO0_18 also has same behavior as GPIO0_53 (aka, after setting padconfig register from 0x8214007 to 0x8004007, writes take effect). SDK 11.0 default image is used. Attaching some scope readings with example logs.

    gpioset -c gpiochip4 18=0

    gpioset -c gpiochip4 18=1

    And I have the probe connected to J13 connector, pin 1.

     

    Regards,

    Takuma

  • Maybe you can show me where in the SDK is the default image to load.  I could not find a *.wic image to burn onto an SD card either in the pre-build images or on the website.  Therefore I build my own using yocto and following the SDK instructions. 

    However, You are using GPIO chip 4 and mine shows up as GPIO Chip 5.

    Doing the same thing you did above and documenting the Oscilloscope output and Linux commands I get differenent results. matter of fact. I can't even see the input to the mux (U29) changing. 

    (The forum software won't let me add my images of where I am probing the board?)

    J13 Pin 1 Probe.jpg

    U29_Pin6 Probe.jpg

    However, If I do the same thing with MCAN5_RX (GPIO_19) I can get it to toggle. So there must be a problem with the pin/pad or path that has gotten damaged with GPIO0_18.  


    Thanks for your help. Lets call this one solved, due to individual HW problem with my specific board.