Bug 82243 (e92532b8@opayq.com) - unable to write value on a gpio
Summary: unable to write value on a gpio
Status: RESOLVED NOTOURBUG
Alias: e92532b8@opayq.com
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: ARM Linux (All)
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-06 10:44 UTC by camo
Modified: 2014-08-11 09:59 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Overview of the commands under discussion (70.90 KB, text/plain)
2014-08-06 10:44 UTC, camo
Details

Description camo 2014-08-06 10:44:31 UTC
Created attachment 104144 [details]
Overview of the commands under discussion

I have an ARM(little endian) arm926t embedded system using a 2.6.39 kernel that I switch from Busybox to systemd (using buildroot). On Busybox I was able to write the value of a specific gpio pin via userspace with
# echo 0 > /sys/class/gpio/gpio104/value
nevertheless when I switch to systemd keeping all the other configuration parameters in buildroot, then the command doesnt work anymore. Also there is no feedback from the system stating that the operation is not valid, it looks as if it works but the value doesn't change. if I execute
# more /sys/class/gpio/gpio104/value
1
Not 0 as I requested. The same command works on Busybox but not on the new systemd. I also if the value maybe was beeing set but not displayed so I connected an osciloscope to the gpio pin, but as in the software, the value doesn't change.

The only difference between the two systems is the PID 1 i.e. systemd vs busybox. Also, with systemd the pin that I want to use is automatically set on on boot and then later is switch off (by itself) when systemd starts. This behaviour was also not present when using busybox.
Comment 1 Lennart Poettering 2014-08-11 09:59:35 UTC
systemd does not touch the gpio subsystem, and does not know anything about it. This bug is certainly not in systemd.

Maybe your startup scripts need updating since systemd starts in parallel that was previously ordered? Anyway, this is not a bug in systemd, and shouldn't be tracked here, hence closing.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.