AM3352: Pull down not deactivated

Hello Sébastien,

You may require higher-level access rights in the HLOS to directly modify the PADCONFIG registers. What is the result when using sudo devmem?

Can you verify the information in your .dtsi file? 

When I configure C13 in the SysConfig-PinMux Tool I receive the following line for .dtsi output.

AM33XX_IOPAD(0x9a4, PIN_INPUT | MUX_MODE7) /* (C13) mcasp0_fsr.gpio3[19] */

Regards,

Dear Fleenor,

Thanks for your answer. I am already logged as root when I use devmem. I will try again again sudo in front of the command.

Concerning device tree syntaxe, I think my syntaxe is the same as yours because AM33XX_IOPAD is a macro offseting the 0x800 to x09A4 to get 0x1A4. 

 Below is the ./include/dt-bindings/pinctrl/omap.h

So I don't think it is the root cause.

Sébastien

Dear Fleenor,

I've test using sudo access as you  requested. I get the same (see below)

regards,

Sébastien

-sh-5.0# sudo devmem2 0x44E109A4

/dev/mem opened.
Memory mapped at address 0xb6f88000.
Read at address 0x44E109A4 (0xb6f889a4): 0x00000027
-sh-5.0#
-sh-5.0#
-sh-5.0# sudo devmem2 0x44E109A4 l 0x37
/dev/mem opened.
Memory mapped at address 0xb6fc5000.
Read at address 0x44E109A4 (0xb6fc59a0): 0x000000000000002F
Write at address 0x44E109A4 (0xb6fc59a0): 0x0000000000000037, readback 0x0000000000000037
-sh-5.0#
-sh-5.0#
-sh-5.0# sudo devmem2 0x44E109A4
/dev/mem opened.
Memory mapped at address 0xb6fc9000.
Read at address 0x44E109A4 (0xb6fc99a4): 0x00000027
-sh-5.0#

Hey Sébastien,

Thank you for verifying the information, it's unfortunate we were not lead to a better outcome. Since we have verified that the pinmux configuration options (PADCFG & value to set) are correct along with the associated SysConfig Tool data, I am going to share the information with another team member who can help further review the linux-related requirements for setting the PADCFG registers and ensuring proper linux boot parameters. 

One other note, the E2E forum requires you to use the "Insert/Edit Media" button to include screenshots (normal copy/paste methods do not work). I am unable to see your ./include/dt-bindings/pinctrl/omap.h image.

You should expect follow up on this thread within the week with further details.

Thanks and Regards,

Dear Fleenor

Thanks for you answer,

Below is the ./include/dt-bindings/pinctrl/omap.h I wanted to share

Sébastien

Hello Sébastien,

Devmem2 is a userspace program. It should not be able to modify Control Module registers, even if you ran it as sudo (including pinmux settings). Instead, you would want to set pinmuxing in uboot or kernel (that is the "higher level access rights in the HLOS" Zack was talking about).

Have you checked the Linux device trees to ensure that your uboot pinmux setting is not getting overwritten? are you able to verify the uboot pinmux settings are getting properly applied before Linux loads?

Regards,

Nick

Thanks Nick for your answer,

I've found the info saying MCU needs to be in priviledge mode to access this register.

So I used uboot to check the pull up/down reconfiguration of my IO. Uboot uses the same device tree as the kernel.

When I use the md and mw command I in uboot I manage to control the pull up/ down of the IO

Hit any key to stop autoboot: 0
=> md.l 0x44E109A4 1
44e109a4: 00000027 '...
=> mw.l 0x44E109A4 1
=> mw.l 0x44E109A4 0x37
=> md.l 0x44E109A4 1
44e109a4: 00000037 7...
=> mw.l 0x44E109A4 0x2F
=> md.l 0x44E109A4 1
44e109a4: 0000002f /...
=>

So I don't understand why my configuration (without pull down) from dts is not taken into account by the kernel and uboot?

I need to configure my IO as I/P without pull down between it is drived by a open drain output
I use the below line in my dts
0x1a4 (PIN_INPUT | MUX_MODE7) /* (C13) mcasp0_fsr.gpio3[19] */

Sébastien

Hello Sébastien,

Maybe I misunderstood. Are you doing this pinmux setting in uboot device tree or Linux device tree?

Please post a snippet of the device tree that includes the pinmux setting, and the node that references the pinmux setting. Note that in the Linux device tree, pinmux settings are not applied unless they are referenced by a device tree node.

For example, look in arch/arm/boot/dts/am335x-evm.dts:
pinmux settings under i2c0_pins: pinmux_i2c0_pins {}
will not get applied unless they are referenced in their associated device tree node. You can see the reference in
&i2c0 {
...
pinctrl-0 = <&i2c0_pins>;
...
}

Regards,

Nick

Hello Sébastien,

Glad you figured out the problem! Thanks for replying with your solution, that helps future customers who find your thread.

Regards,

Nick