Port-arm archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: impossible to access /dev/mem on RPi B+ [Was: Sound issues on RPi B+, Jun's latest image]




On 13 Mar 2015, at 11:33, Jean-Baka Domelevo Entfellner <domelevo%gmail.com@localhost> wrote:

Thank you, Michael and Radoslaw, for your answers. See below...

On Fri, Mar 13, 2015 at 12:01 PM, Radoslaw Kujawa <radoslaw.kujawa%c0ff33.net@localhost> wrote:
It's a totally terrible idea to access low level SoC registers from within user-space program. DON'T do that. It's a bad design and completely unsecure. As Michael mentioned, the default securelevel setting prevents this (for a good reason).

If you want to utilise GPIO, then investigate the kernel API we are providing for this (see gpio(4) man page). Patch your program to use it instead of /dev/mem!

I get your point about security concerns, you are right, I am now running at securitylevel = 1, which disallows access to /dev/mem. I will take my time to go through gpio(4), but for now I really don't have time and I would like to do a quick test with my RPi running at securitylevel=0. I have been struggling so far to prevent rc or init to raise the securitylevel from 0 to 1, it seems I can't see where it happens, I have patched /etc/rc/d/securelevel so that it doesn't raise it, I have set the securelevel to 0 in /etc/rc.conf, but amazingly for some reason it gets to 1 maybe after /etc/rc.d/securelevel changes it to 0, so I don't really know what brings the securitylevel up to the value 1.

I _know_ it's very bad, and I don't overlook your advice, but could you please help me understand what is in the way?

You need to recompile your kernel with INSECURE config option set, as Michael stated before.

See the rc.conf(5) man page and its explanation of securelevel variable, secmodel_securelevel(9) for explanation of how exactly it is raised and how INSECURE affects this. 

(2) Concerning audio output, everything is fine now, except that I have no clue how to control the volume level and that it is impossible to do it from within mplayer (no error output, but controls are ineffective).

Please check if the volume level is controllable with mixerctl command.

I tried, but here is what I have:

rpi# mixerctl -a -v
outputs.master=77,77 volume
inputs.dac=77,77 volume

These values where all set to 128 at the beginning, I could modify them but without any effect on the actual audio volume. I see that when I raise/lower the volume from within mplayer, the values seen by mixerctl change accordingly, but the hardware doesn't seem to listen to any of these orders... :(

Well then, either something is broken, or something changed between normal RPI and RPI+. I think the driver was ever only tested on normal RPI? I think jmcneill@ would know since he wrote this.

-- 
Best regards,
Radoslaw Kujawa





Home | Main Index | Thread Index | Old Index