[opensuse-arm] vcio, STRICT_DEVMEM
Well, at least I have a vcio module that builds now, we'll see it if it also works. The code for using the PWM to generate control signals for a line of WS2812Bs also uses /dev/mem to access the Raspi hardware - with the openSUSE kernel, this is blocked by CONFIG_STRICT_DEVMEM. I don't see any kernel argument or switch to disable that restriction. (I tried strict_devmem=0, didn't work). I'm rebuilding a kernel without CONFIG_STRICT_DEVMEM, but I can't help wondering if we shouldn't have a dedicated kernel optimized for use on the Raspi? Using kernel-default seems silly. -- Per Jessen, Zürich (11.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 10/03/2019 19:35, Per Jessen wrote:
Well, at least I have a vcio module that builds now, we'll see it if it also works.
It seems that there is another thread on this mailing list, but I wasn't able to find it. What do you want to achieve?
The code for using the PWM to generate control signals for a line of WS2812Bs also uses /dev/mem to access the Raspi hardware - with the openSUSE kernel, this is blocked by CONFIG_STRICT_DEVMEM. I don't see any kernel argument or switch to disable that restriction. (I tried strict_devmem=0, didn't work).
I'm rebuilding a kernel without CONFIG_STRICT_DEVMEM, but I can't help wondering if we shouldn't have a dedicated kernel optimized for use on the Raspi? Using kernel-default seems silly.
In general you can provide patches against openSUSE kernel configuaration if there is anything you think it should be enabled/disabled. STRICT_DEVMEM is a security feature so IMHO there should be a good reason to disable it. From your email I understand that you want to access PWM via /dev/mem. That looks wrong. The PWMs should be accessed through the sysfs. Can you please give some more background on what you want to do and how you try to achieve that? Regards, Matthias -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Matthias Brugger wrote:
On 10/03/2019 19:35, Per Jessen wrote:
Well, at least I have a vcio module that builds now, we'll see it if it also works.
It seems that there is another thread on this mailing list, but I wasn't able to find it. What do you want to achieve?
Hi Matthias, nothing too complex I hope, I just want to control a series of WS2812 LEDs, using the code/utilities from https://github.com/jgarff/rpi_ws281x
The code for using the PWM to generate control signals for a line of WS2812Bs also uses /dev/mem to access the Raspi hardware - with the openSUSE kernel, this is blocked by CONFIG_STRICT_DEVMEM. I don't see any kernel argument or switch to disable that restriction. (I tried strict_devmem=0, didn't work).
I'm rebuilding a kernel without CONFIG_STRICT_DEVMEM, but I can't help wondering if we shouldn't have a dedicated kernel optimized for use on the Raspi? Using kernel-default seems silly.
In general you can provide patches against openSUSE kernel configuaration if there is anything you think it should be enabled/disabled.
Cool, I might well make some suggestions.
STRICT_DEVMEM is a security feature so IMHO there should be a good reason to disable it. From your email I understand that you want to access PWM via /dev/mem. That looks wrong. The PWMs should be accessed through the sysfs.
Yes, I get the idea of /dev/mem, but I see lots of code for Raspis that is using /dev/mem ? None of what I have seen even mentions having to disable STRICT_DEVMEM.
Can you please give some more background on what you want to do and how you try to achieve that?
For controlling the WS2812, I need to transmit data at around 800kHz - with libgpiod, I was only able to generate a waveform of about 400kHz (on a gpio). I gave that up and then I stumbled on https://github.com/jgarff/rpi_ws281x which looks to be the right way to go. That code expects to use /dev/vcio for talking to the GPU mailbox as well as /dev/mem for working with the PWM. -- Per Jessen, Zürich (5.3°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Per Jessen wrote:
Matthias Brugger wrote:
On 10/03/2019 19:35, Per Jessen wrote:
Well, at least I have a vcio module that builds now, we'll see it if it also works.
It seems that there is another thread on this mailing list, but I wasn't able to find it. What do you want to achieve?
Hi Matthias,
nothing too complex I hope, I just want to control a series of WS2812 LEDs, using the code/utilities from
Well, for what's worth - using the vcio code from here: http://www.macs.hw.ac.uk/~hwloidl/hackspace/linux/drivers/char/broadcom/vcio... (I forget exactly where I found it, probably on github). I built the vcio module, seems to work fine. Then I built the kernel without STRICT_DEVMEM and I can now control a string of WS2812 LEDs. -- Per Jessen, Zürich (3.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Per,
-----Original Message----- From: Per Jessen <per@jessen.ch> Sent: 12 March 2019 08:58 To: opensuse-arm@opensuse.org Subject: Re: [opensuse-arm] vcio, STRICT_DEVMEM
Per Jessen wrote:
Matthias Brugger wrote:
On 10/03/2019 19:35, Per Jessen wrote:
Well, at least I have a vcio module that builds now, we'll see it if it also works.
It seems that there is another thread on this mailing list, but I wasn't able to find it. What do you want to achieve?
Hi Matthias,
nothing too complex I hope, I just want to control a series of WS2812 LEDs, using the code/utilities from
Well, for what's worth -
using the vcio code from here:
http://www.macs.hw.ac.uk/~hwloidl/hackspace/linux/drivers/char/broadco m/vcio.c (I forget exactly where I found it, probably on github).
I built the vcio module, seems to work fine. Then I built the kernel without STRICT_DEVMEM and I can now control a string of WS2812 LEDs.
Thanks for your feedback! The vcio module can probably be upstreamed, or at least packaged in OBS, I guess. Thanks, Guillaume IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. N�����r��y隊Z)z{.�櫛맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.�櫛�0�����Ǩ�
On 12/03/2019 09:04, Guillaume Gardet wrote:
Hi Per,
-----Original Message----- From: Per Jessen <per@jessen.ch> Sent: 12 March 2019 08:58 To: opensuse-arm@opensuse.org Subject: Re: [opensuse-arm] vcio, STRICT_DEVMEM
Per Jessen wrote:
Matthias Brugger wrote:
On 10/03/2019 19:35, Per Jessen wrote:
Well, at least I have a vcio module that builds now, we'll see it if it also works.
It seems that there is another thread on this mailing list, but I wasn't able to find it. What do you want to achieve?
Hi Matthias,
nothing too complex I hope, I just want to control a series of WS2812 LEDs, using the code/utilities from
I had a look on that code and it looks like a hack to me.
Well, for what's worth -
using the vcio code from here:
http://www.macs.hw.ac.uk/~hwloidl/hackspace/linux/drivers/char/broadco m/vcio.c (I forget exactly where I found it, probably on github).
I built the vcio module, seems to work fine. Then I built the kernel without STRICT_DEVMEM and I can now control a string of WS2812 LEDs.
Thanks for your feedback! The vcio module can probably be upstreamed, or at least packaged in OBS, I guess.
I don't think this is the right approach for upstream. If we want to control these leds, then we should write a kernel driver which uses the mbox and not implement detection etc in user-space. If you want to use a LED matrix, then I think this is a good candidate for a tinydrm driver in the kernel. Best regards, Matthias -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Matthias Brugger wrote:
On 12/03/2019 09:04, Guillaume Gardet wrote:
Hi Per,
-----Original Message----- From: Per Jessen <per@jessen.ch> Sent: 12 March 2019 08:58 To: opensuse-arm@opensuse.org Subject: Re: [opensuse-arm] vcio, STRICT_DEVMEM
Per Jessen wrote:
Matthias Brugger wrote:
On 10/03/2019 19:35, Per Jessen wrote:
Well, at least I have a vcio module that builds now, we'll see it if it also works.
It seems that there is another thread on this mailing list, but I wasn't able to find it. What do you want to achieve?
Hi Matthias,
nothing too complex I hope, I just want to control a series of WS2812 LEDs, using the code/utilities from
I had a look on that code and it looks like a hack to me.
I can't really comment - of the couple of projects I looked at (related to ws2812), this looked the most complete/useful.
I built the vcio module, seems to work fine. Then I built the kernel without STRICT_DEVMEM and I can now control a string of WS2812 LEDs.
Thanks for your feedback! The vcio module can probably be upstreamed, or at least packaged in OBS, I guess.
I don't think this is the right approach for upstream. If we want to control these leds, then we should write a kernel driver which uses the mbox and not implement detection etc in user-space. If you want to use a LED matrix, then I think this is a good candidate for a tinydrm driver in the kernel.
again, I can't really comment on what is right or good - so just my observations: getting the vcio module to work was no big deal, just required a bit of research - I think even a relative newbie would manage to get it to work. About STRICT_DEVMEM - had I been able to disable with a kernel argument, that would have been really nice. In 2008, Bernhard Walle @ suse also proposed a sysctl "dev.mem.restricted", but I guess that didn't go through. -- Per Jessen, Zürich (5.0°C) member, openSUSE Heroes. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 12/03/2019 11:16, Per Jessen wrote:
Matthias Brugger wrote:
On 12/03/2019 09:04, Guillaume Gardet wrote:
Hi Per,
-----Original Message----- From: Per Jessen <per@jessen.ch> Sent: 12 March 2019 08:58 To: opensuse-arm@opensuse.org Subject: Re: [opensuse-arm] vcio, STRICT_DEVMEM
Per Jessen wrote:
Matthias Brugger wrote:
On 10/03/2019 19:35, Per Jessen wrote: > Well, at least I have a vcio module that builds now, we'll see it > if it also works. >
It seems that there is another thread on this mailing list, but I wasn't able to find it. What do you want to achieve?
Hi Matthias,
nothing too complex I hope, I just want to control a series of WS2812 LEDs, using the code/utilities from
I had a look on that code and it looks like a hack to me.
I can't really comment - of the couple of projects I looked at (related to ws2812), this looked the most complete/useful.
I built the vcio module, seems to work fine. Then I built the kernel without STRICT_DEVMEM and I can now control a string of WS2812 LEDs.
Thanks for your feedback! The vcio module can probably be upstreamed, or at least packaged in OBS, I guess.
I don't think this is the right approach for upstream. If we want to control these leds, then we should write a kernel driver which uses the mbox and not implement detection etc in user-space. If you want to use a LED matrix, then I think this is a good candidate for a tinydrm driver in the kernel.
again, I can't really comment on what is right or good - so just my observations:
getting the vcio module to work was no big deal, just required a bit of research - I think even a relative newbie would manage to get it to work.
Well what I wanted to say is: openSUSE uses the mainline kernel. If you want your LED matrix to work out-of-the-box with openSUSE then you (or someone) will need to find a solution that works with upstream. The solution that raspbian gives us does not full fill this criteria. IMHO: - We don't want to discover the HW from user-space reading the device-tree compatible etc. - We don't want to access the mailbox driver from user-space to control a PWM, we want to do that in the kernel and use the sysfs - We don't want to implement a frame buffer in userspace that get's passed through the mailbox driver to the kernel. Instead we want to use tinydrm that exposes a frame buffer to us. And, if needed, have a userspace library (for C, golang, you name it) that interacts with that device. Just in case someone with a LED matrix wants to get this working upstream :) Regards, Matthias
About STRICT_DEVMEM - had I been able to disable with a kernel argument, that would have been really nice. In 2008, Bernhard Walle @ suse also proposed a sysctl "dev.mem.restricted", but I guess that didn't go through.
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (3)
-
Guillaume Gardet -
Matthias Brugger -
Per Jessen