Hi,
I am trying to change pin mux settings from inside a kernel module.
However, I have not been able to find reliable information on how to do that on the BeagleBone. Everything I have been able to find is only referencing the BeagleBoard, and which does not seem to apply to the BeagleBone.
Can anybody point me in the right direction?
I don’t want to do this from u-boot because I want to be able to load the driver module into a standard BeagleBone distribution and not depend on a customized image.
Thanks in advance,
Hermann
Anyone?
I got Open Embedded to build the kernel module so far, which I then can load successfully into the BeagleBone, however, at the moment without pin muxing.
I’d just need to know which headers I need to include for pin muxing (e.g. Do I go with plat/mux.h or do I need something more specific to the AM335x? And where do I get the definitions for the pin offsets, which seem to be only in kernel/arch/arm/mach-omap2/mux33xx.h (but that file seems to have its own - different - way of doing pin muxing)?), and which functions I need to use to do that task from a kernel module.
I’ve already tried setting up the mux settings from u-boot, which mostly worked, but some of the settings seem to get overwritten by something else during the boot process, even though those pins are not used. At least a dump of /sys/kernel/debug/omap_mux/board/core shows some of the GPMC pins in mode 7, not mode 1 or 4 as I had configured them.
Cheers,
Hermann
mux for the bone is done in arch/arm/mach-omap2/board-am335xevm.c
Thanks for the info!
That file is really evasive, in existing only after the “patch” task on the kernel target and before it is completed (upon which the file is removed again).
Anyway, it confirmed what was overwriting my pin mux settings I had set in u-boot, since the mux changes that file does exactly correspond to the pins that did not match what I had set up in u-boot.
Sigh, and it also seems that I can pretty much forget making a driver for a “stock” distribution that will work with my hardware, since the board-am335xevm.c file for example registers the w1 driver right in the middle of the GPMC_AD pins, and the bone tester uses another one of those pins. Am I correct in assuming I won’t get around making modifications to that file?
Unfortunately, so far I have limited understanding of the OE build process, but if I wanted to modify that file that in a “proper” way, would I be on the right track in creating an own “sources/meta-hermann” folder containing a recipe loosely based on “sources/meta-ti/recipes-kernel/linux/linux-ti33x-psp_3.2.bb”, which seems to create and patch the board-am335xevm.c file?
Cheers,
Hermann