0

I'm currently trying to develop an expansion board for BeagleBoard-xM, and an unusual bug came to my attention: This board has a PINMUX which is being managed by pinctrl-single, which reports me, that the MUX i set up in my device tree works as expected, this same set up is done in u-boot as well. Still, the corresponding GPIO cannot see what voltage is on the pin. This pin works well with omap_mux on an older kernel, and the pin right next to it in numbering works well with both kernels.

My question is, how can i check the content of the corresponding register in linux? (which can reached by its physical address)

Gergő Horváth
  • 1
  • If the register is memory-mapped via the physical address, then `mmap()`ing the correct page of `/dev/mem` (which uses physical addresses) might work as a quick and dirty solution for getting the value from user space. See e.g. http://stackoverflow.com/questions/13124271/driving-beaglebone-gpio-through-dev-mem. Access the register via a pointer-to-`volatile`. – Ulfalizer Apr 15 '15 at 18:14
  • What version of Linux? On mine `mount -t debugfs debug /sys/kernel/debug` and `cat /sys/kernel/debug/pin-ctrl/pinctrl-handles`, etc. seems to give some information. The physical MUX registers will not be exposed. – artless noise Apr 15 '15 at 18:14
  • @artless-noise mainline 4.0-rc7, i checked this this already, and it reports the right thing, but the pin still seems to be in a different mode. – Gergő Horváth Apr 16 '15 at 07:51
  • @ulfalizer thank you, i will try this now and report back in a few minutes – Gergő Horváth Apr 16 '15 at 07:52
  • I let you know, i went with @ulfalizer 's solution and checked both the pinmux and gpio registers, and everything seemed alright. The problem was caused by a faulty IC on the board, which caused it's VCC to drop below 1V, causing that it's pins could not hit the SOC's hi-level voltage threshold. Replacing the faulty component solved the problem. Thank you for your kind help! – Gergő Horváth Apr 16 '15 at 11:07

0 Answers0