PicoCOM4 (linux) GPIOs not all usable?

      PicoCOM4 (linux) GPIOs not all usable?

      Hello.
      I'm working with PicoCOM4 (Linux) and i'm using many GPIO pins.
      I have problems with some pins. If i open the pins with the driver some GPIOs are ok and some cannot be opened.
      Example of Pins which cannot be opened:
      J11-24,65,66,67,68
      The Software-numbers are (GPIO Reference Card 1.3) 192,33,34,35,36
      If i do (for example):
      # echo 192 > /sys/class/gpio/export
      i get: write error: device or resource busy.
      The Pins are occupied.
      Is this J11-24=USB, J11-65,66,67=LCD?
      But for example J11-51 (SW:101) is also LCD and i use it as Input and it works.
      Have i to disable USB, LCD or anything else?
      If yes how can i do this?
      Thanks

      Re: PicoCOM4 (linux) GPIOs not all usable?

      Yes, these pins are occupied with dedicated functions by default. And you have guessed it, these are USB and LCD. So you have to switch off these dedicated functions to be able to use these pins.

      In menuconfig:

      Source Code

      1. LCD: Device Drivers -> Graphics support -> Support for frame buffer drivers (say 'n' here)
      2. -> Backlight & LCD device support (say 'n' here)
      3. -> Display device support -> Display panel/monitor support (say 'n' here)
      4. USB: Device Drivers -> USB support (say 'n' here)


      The reason why you can use some pins and some not is this:

      In Linux there is currently a shift to a more generic handling of SOC (System-on-chip) hardware. In the past, every SOC manufacturer provided his own set of functions to access the SOC hardware (GPIOs, dedicated functions, etc.). So there was quite a lot of functionality implemented in multiple versions, once from each SOC vendor. This caused quite some anger about two or three years ago and Linus Torwalds, the boss of all Linux, said that he would throw out all ARM stuff if this won't get better. From then on, the ARM people and SOC manufacturers worked better together and introduced some generic functions to access such common things like GPIOs in a hardware-independent way. This was also the birth of the Device Trees, a generic way to describe the hardware platform to allow using the same Linux kernel for many many boards with the same CPU core, no matter what specific SOC, like it has always been the case for x86 hardware.

      This conversion is still going on. Some new interfaces are already rather common usage in the kernel (like generic handling of GPIOs and clocks), some things are still rather young (like generic handling of multimedia features, pin multiplexing, DMA-capable memory allocators, device trees), and some things are yet to come. With each kernel version, more drivers are converted to the "new" style.

      However the kernel used on the PicoCOM4 is from a time rather at the beginning of this conversion. So only a few pins are handled by the new generic GPIO interface. In this case if we request a pin as internal GPIO, then this pin is locked and can not be used as external user GPIO. These are the pins you have problems with. But this is generally correct, because the pin is actually in use by a device driver and it is good that you can not steal this pin from the driver and use it as an external GPIO. But the other pins are allocated by the older SOC-specific interface and are therefore not locked for GPIO. So these pins can (incorrectly) be activated as an external user GPIO, despite the fact that they serve a dedicated function of a device driver at the moment. These are the pins you do not have a problem with.

      So the correct way of doing things is to deactivate the dedicated function that is running on these pins in the configuration and then these pins can safely be used as external GPIOs.

      Your F&S Support Team
      F&S Elektronik Systeme GmbH
      As this is an international forum, please try to post in English.
      Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

      Re: PicoCOM4 (linux) GPIOs not all usable?

      Hello.
      Thanks for your explication.
      With menuconfig you mean the configuration of the kernel?
      I have to build a own kernel?
      Isn't it possible to deactivate this parts on a running system with the shell?
      Something like unmount, unbind or another hack?
      I liked to avoid to build an own kernel because until now we use your kernel.
      I'm just building my own filesystem.
      Thanks.
      A. Nebgen

      Re: PicoCOM4 (linux) GPIOs not all usable?

      "Nebgen" wrote:

      With menuconfig you mean the configuration of the kernel?
      I have to build a own kernel?

      Yes, and yes.

      Isn't it possible to deactivate this parts on a running system with the shell?
      Something like unmount, unbind or another hack?

      This is the ultimate goal that should and will be reached with Device Trees. By changing the Device Tree (e.g. within U-Boot), it is possible to activate some device or deactivate some device, without having to modify and recompile the kernel. However this is not yet the case with our boards. At the moment you actually have to remove the device driver from the kernel by changing the kernel configuration.

      Well this is not completely true. You can also build most of the drivers as kernel modules that can be loaded and unloaded at runtime. Then you could leave a device off by just not loading the appropriate kernel module. On the other hand this is somewhat more complicated in the normal case, as you always have to load one or more kernel modules before you can start using a device. Therefore we currently don't use this feature and have everything compiled fix into the kernel.

      I liked to avoid to build an own kernel because until now we use your kernel.
      I'm just building my own filesystem.

      Building the kernel is easier than the root filesystem. Just unpack the kernel source, say

      Source Code

      1. make picocom4_defconfig
      2. make menuconfig
      3. [now modify the settings]
      4. make


      After a few minutes you have the new kernel in directory arch/arm/boot. That's all.

      Your F&S Support Team
      F&S Elektronik Systeme GmbH
      As this is an international forum, please try to post in English.
      Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.