Memory Mapped GPIO, has the addressing changed?


Has anyone found a solution to this?

I am mapping /dev/mem and setting the GPIO input / output in a similar fashion to the referenced example by the OP.

From dmesg I see
[267773.389824] Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6f71134

In a TI forum I came across

“You need to make sure that the appropriate McSPI functional (CM_FCLKEN1_CORE) and interface (CM_ICLKEN1_CORE) clocks are enabled before reading the McSPI registers.”

Is this solution - especially since I am not using SPI? What exactly does it mean?



You need to activate the low-level GPIO hardware (ie: take it out of
reset and provide a clock). The easiest way to do this is to export a
GPIO pin using the sysfs interface. You can then talk to anything
else in that group of pins via direct register access.

Note that there are two hardware groups. GPIO bank 0 is on it's own,
and banks 1, 2, and 3 are grouped together.

- --
Charles Steinkuehler

Unfortunately enabling setting pinmuxing for GPIOs does not turn on
the GPIO modules. The easiest way to enable them is to export one pin
from each of the problematic GPIO blocks. You can use the following


Thank you,

I tried and it worked.

I ran the from first.
Then, I ran the Beagle_GPIO_test compiled from
I could see the Pin P8-46 is changed from 3.3v to 0v.
Hope this will help others who are using or trying to use the mmap to configure the pin using C/C++.

Thank you,