fix support for linkit Smart 7688 on openWRT 18.06

[novski]

I noticed that libmraa is broken on linkit smart 7688 on openWRT 18.06. (+) I get an error in logread:libmraa initialised for platform 'Unknown platform' of type 98. The syslog way of debuging does not work as openWRT 18.06 does not support it.

Im not sure at what point this package stoped working. It could be a mraa v2 or a openWRT/LEDE merge issue.

Who can help me debug that?

I have seen that @sergev has once made a PR for previous versions. Please let me know if you are able to fix it.

regards, novski

---

This is the full output after trying to start the python test:

v2.0.0
Traceback (most recent call last):
  File "mraa-test-simple.py", line 11, in <module>
    pin = mraa.Gpio(2)
  File "/usr/lib/python3.7/site-packages/mraa.py", line 391, in __init__
    _mraa.Gpio_swiginit(self, _mraa.new_Gpio(pin, owner, raw))
ValueError: Invalid GPIO pin specified

and this is the full logread:

Sun Sep 22 08:52:15 2019 local1.notice libmraa[1448]: libmraa version v2.0.0 initialised by user 'root' with EUID 0
Sun Sep 22 08:52:15 2019 local1.err libmraa[1448]: linkit map: unable to open /dev/mem
Sun Sep 22 08:52:15 2019 local1.notice libmraa[1448]: gpio: platform doesn't support chardev, falling back to sysfs
Sun Sep 22 08:52:15 2019 local1.notice libmraa[1448]: libmraa initialised for platform 'Unknown platform' of type 98
Sun Sep 22 08:52:15 2019 local1.err libmraa[1448]: gpio: init: pin 2 beyond platform pin count (0)

[alext-mkrs]

The syslog way of debugging is exactly what you've pasted as a logread :)

Anyway, looks like that new OS version disables /dev/mem - as many modern distros do - and that upsets the library setup flow, right here, so the platform isn't getting fully initialized.

At the moment I have no time to analyze this in more detail, sorry, so @sergev, do you have any idea how else it could be initialized if /dev/mem is inaccessible?

@novski - if that's an option (you'll need to rebuild the kernel), you could probably simply flip the respective kernel option, but I admit that's not the best way to go about that, rather a quick-and-dirty one to make it work until a longer-term solution is found

[novski]

As this device should in the end be used as a IoT board i don't think it's a good idea to make it work in a developer agnostic kernel root debug access mode. That s what i read in your link: If this option is disabled, you allow userspace (root) access to all of memory, including kernel and userspace memory. Accidental access to this is obviously disastrous, but specific access can be used by people debugging the kernel. I will ask if somebody of openWRT dev`s can suggest another solution here.

[nxhack]

https://bugs.openwrt.org/index.php?do=details&task_id=1496&status%5B0%5D=&pagenum=4

Did you try enabling CONFIG_KERNEL_DEVMEM in the OpenWrt toplevel .config? ("Global build settings" → "Kernel build options" → "/dev/mem virtual device support" in make menuconfig)? Settings in toplevel .config take precedence over kernel .config.

[novski]

Thanks for the path. I tried that now and got a different error:

root@OpenWrt:/sys/class/gpio# logread | grep mraa
Wed Sep 25 19:00:51 2019 local1.notice libmraa[1474]: libmraa version v2.0.0 initialised by user 'root' with EUID 0
Wed Sep 25 19:00:51 2019 local1.notice libmraa[1474]: gpio: platform doesn't support chardev, falling back to sysfs
Wed Sep 25 19:00:51 2019 local1.notice libmraa[1474]: libmraa initialised for platform 'LinkIt Smart 7688' of type 17
Wed Sep 25 19:00:51 2019 local1.err libmraa[1474]: gpio: init: pin 2 not capable of gpio

Looks like the /dev/mem virtual device support is not the only thing that blocks working with mraa. But that seems to make it work better...

Is somebody familiar with such a errorcode or message?

[novski]

oh just noticed that pin2 is not mapped it works!

Still i'm a bit cautious. Wondering: How big is the security hole i'm opening with /dev/mem?

[alext-mkrs]

Glad it works for you.

As for the "security hole", well, one anyway has to be root to use that due to typical filesystem permissions on that character device. Not a huge justification, but still :) Essentially that's just not the best security practice as it provides too much access to userspace where normally a kernel driver with more limited API must exist - so it violates the principle of least privilege.

You can try flipping the CONFIG_STRICT_DEVMEM and CONFIG_IO_STRICT_DEVMEM to "y", which limit the exposed address ranges while preserving the /dev/mem device (governed by CONFIG_DEVMEM) itself.

[novski]

for anyone comming across this you also have to add kmod-pwm-mediatek-ramips if you whant pwm to work...

[tianlx2018]

I got the same problem when I try to operate gpio with python,here is the log

Wed Feb 16 11:47:11 2022 local1.notice libmraa[2510]: libmraa version v2.2.0 initialised by user 'root' with EUID 0 Wed Feb 16 11:47:11 2022 local1.notice libmraa[2510]: gpio: platform doesn't support chardev, falling back to sysfs Wed Feb 16 11:47:11 2022 local1.notice libmraa[2510]: libmraa initialised for platform 'LinkIt Smart 7688' of type 17 Wed Feb 16 11:47:11 2022 local1.err libmraa[2510]: gpio12: init: Failed to write to 'export': Invalid argument Wed Feb 16 11:47:11 2022 kern.warn kernel: [ 286.997807] export_store: invalid GPIO 12

I guess the reason is "platform doesn't support chardev"

In contrast to openwrt 15.04,the log is Tue Sep 27 12:11:50 2016 local1.notice libmraa[1598]: libmraa version v0.8.0 initialised by user 'root' with EUID 0 Tue Sep 27 12:11:50 2016 local1.notice libmraa[1598]: libmraa initialised for platform 'LinkIt Smart 7688' of type 9