Fixing Fast-GPIO for Omega2/2+



  • Hey, just got my order for both of these devices and I'm pleased with them.

    In my journey yesterday I've tried the Fast-GPIO with the out-of-the-box firmware and it worked on both the 2 and the 2+.

    However, later on I discovered the Console and it suggested I upgrade the firmware, so I did it on both devices. After doing some modifications (installing PHP, Node-RED, etc) I discovered that the Fast-GPIO program doesn't work anymore.

    No matter what I do, read/write/pwm.. it just throws a "segmentation fault". Now, first thing I did was some research, and I found out it's a bug with /dev/mem not existing, which I confirmed by doing a "cat /dev/mem" which returned that it doesn't exist.

    Of course, a simple fix would be downgrading the firmware, which I did. I actually tried b141 all the way to b152 and the problem persists in ALL of them. How is this possible? It's even acknowledged as an official bug but it wasn't addressed in any of these versions?

    I know I could use gpioctrl, but I don't know how to make it return (in the serial terminal -- for PHP) just a LOW/HIGH or 0/1, which Fast-GPIO was able to do..

    So my questions are:

    1. Is there a way to manually fix /dev/mem (installing a package or enabling a kernel module somehow), without recompiling a custom firmware. If yes, how?
    2. Does your Fast-GPIO work? If yes, what's the full version that you run? (ex. 0.19 bXYZ)


  • @Marcel-Neculae said in Fixing Fast-GPIO for Omega2/2+:

    So my questions are:

    1. Is there a way to manually fix /dev/mem (installing a package or enabling a kernel module somehow), without recompiling a custom firmware. If yes, how?

    No.

    1. Does your Fast-GPIO work? If yes, what's the full version that you run? (ex. 0.19 bXYZ)

    0.1.6 b137 is the last version where it was working.



  • @Marcel-Neculae said in Fixing Fast-GPIO for Omega2/2+:

    I know I could use gpioctrl, but I don't know how to make it return (in the serial terminal -- for PHP) just a LOW/HIGH or 0/1, which Fast-GPIO was able to do..

    I don't have the particular system in front of me to try it, but if your need is not speed, have you tried the traditional /sys/class/gpio mechanism where you echo a pin number onto the export node and then get a direction and value node in a directory for that pin? You can interact with those with echo, shell redirects and cat so would think you could with other languages as well.

    Or is that interface broken, too?



  • That interface isn't broken.



  • @Chris-Stratton I have to try it. I'm not looking to anything close to real-time. ~500ms delays are ok.

    I'll have to give it a go tomorrow. Thanks for the hint! 🙂



  • Playing with an Omega2+ on the Expansion Dock. Running ver 0.1.9 b149. I wanted to try and get the onboard RGB LED to do something. The documentation says to use “expled” on the command line to control the LED. I typed the example given: expled 0xF21133. I got the following error message:

    root@Omega-B1CB:/# expled 0xf21133
    Setting LEDs to: f21133
    Duty: 6 94 80
    [ 2076.611819]
    do_page_fault(): sending SIGSEGV to fast-gpio for invalid read access from 00000600
    [ 2076.620650] epc = 00401d51 in fast-gpio[400000+3000]
    [ 2076.625758] ra = 00401a89 in fast-gpio[400000+3000]
    [ 2076.630800]
    [ 2076.651778]
    do_page_fault(): sending SIGSEGV to fast-gpio for invalid read access from 00000600
    [ 2076.660657] epc = 00401d51 in fast-gpio[400000+3000]
    [ 2076.665773] ra = 00401a89 in fast-gpio[400000+3000]
    [ 2076.670814]
    root@Omega-B1CB:[ 2076.681765]
    do_page_fault(): sending SIGSEGV to fast-gpio for invalid read access from 00000600/#
    [ 2076.691591] epc = 00401d51 in fast-gpio[400000+3000]
    [ 2076.696888] ra = 00401a89 in fast-gpio[400000+3000]
    [ 2076.701950]

    I can control the GPIOs that control the LED using “gpioctl”. However, “fast-gpio” fails.

    root@Omega-B1CB:/# fast-gpio set-output 17
    [ 2380.917440]
    do_page_fault(): sending SIGSEGV to fast-gpio for invalid read access from 00000600
    [ 2380.926344] epc = 00401d51 in fast-gpio[400000+3000]
    [ 2380.931416] ra = 00401a89 in fast-gpio[400000+3000]
    [ 2380.936458]
    Segmentation fault
    root@Omega-B1CB:/# fast-gpio set 17 0
    [ 2409.573969]
    do_page_fault(): sending SIGSEGV to fast-gpio for invalid read access from 00000600
    [ 2409.582862] epc = 00401d51 in fast-gpio[400000+3000]
    [ 2409.587929] ra = 00401a89 in fast-gpio[400000+3000]
    [ 2409.592990]
    Segmentation fault

    “gpiomux” also does not work.

    root@Omega-B1CB:/# omega2-ctrl gpiomux get
    unable to open mmap fileroot@Omega-B1CB:/#

    It really would be nice if the examples in the documentation actually worked. Does anybody at Onion ever try this stuff before posting the docs ?

    I am also having an issue trying to use SPI with Python. I add the "import onionPy" statement. When I run the script I get an error message that tells me "onionSpi" is not a valid import. This is right out of the using SPI with Python guide. How do I fix these ?



  • Clearly anything that depends on /dev/mem is broken in that build.

    Question remains if the /sys/class/gpio and/or /sys/class/leds interfaces with whatever modes the pinmux is booting in would work for your purpose.

    If not, you're either stuck until they get you a working build, or in the territory of needing to look at alternative software stacks.



  • Hello All,

    This bug exists.
    Firmware shipped 0.1.5 b130.
    fast-gpio works.
    I upgraded firmware, fast-gpio gives segmentation fault.

    Please fix firmware and release patch.

    regards,



  • FWIW: On my Omega2 with firmware 0.1.9 b149 the "expled 0xf21133" command doesn't show any errors and what seems like the desired output:

    Setting LEDs to: f21133
    Duty: 6 94 80

    However the colour of the RGB LED is changed (even when GPIO ports 15, 16, 17 are set to output mode).



Looks like your connection to Community was lost, please wait while we try to reconnect.