Skip to main content

I can answer this.

sudo chown root.gpio /dev/mem

This changes the owner and group of /dev/mem to root and gpio respectively.

sudo chmod g+rw /dev/mem

then gives the group read write access to this /dev/mem object.

The /dev/mem object is basically the entire memory space on the system. This means that now the group gpio, and everyone in it, can read and write to the memory space.

Now, in the memory space are many things, including CPU registers. When you toggle GPIO pins, you are changing a bit in one of these registers. The kicker is, you need to be sure you do it correctly or bad bad things can happen to your system.

To help protect the entire memory space, the powers that be mapped just the memory parts that we need to work with the GPIO bits to /dev/gpiomem. This in effect masks/shields the rest of the memory space from being access and only allows the GPIO bits to be accessed. This allows access to the GPIO memory addresses and disallows any other parts of the memory, such as memory currently being used by any other programs.

In effect, this blows a hole in both security and system stability protections to allow access to the GPIO stuff, as well as the rest of the memory, but only to the users in group GPIO, which Pi is a member of.

In the future, drivers such as the bcm2835 library and wiringPi will be updated more (some updates are already happening) and the apps that are built on top of those tools will get further updated and then in the future, hopefully all this GPIO hassle as root will disappear.

Until then you have two choices, open up the /dev/mem to group gpio as read/write, or run as root, which has full read write to all of /dev/mem.

Hope that makes sense.

There are currently still some many issues where you still need to run as root. For example, using the node-red-contrib-dht-sensor module, which depends on the node-dht-sensor, which depends on BCM2835. It seg-faults using /dev/gpiomem as it has some bugs still either in node-dht-sensor or in /dev/gpiomem or the way they are working together. I don't know which is the case, but it will get worked out eventually. When BCM2835 runs as 'non-root' and /dev/gpiomem exists, it tries to use /dev/gpiomem instead of /dev/mem, so opening the /dev/mem to group gpio doesn't help. Bummer.

I can answer this.

sudo chown root.gpio /dev/mem

This changes the owner and group of /dev/mem to root and gpio respectively.

sudo chmod g+rw

then gives the group read write access to this /dev/mem object.

The /dev/mem object is basically the entire memory space on the system. This means that now the group gpio, and everyone in it, can read and write to the memory space.

Now, in the memory space are many things, including CPU registers. When you toggle GPIO pins, you are changing a bit in one of these registers. The kicker is, you need to be sure you do it correctly or bad bad things can happen to your system.

To help protect the entire memory space, the powers that be mapped just the memory parts that we need to work with the GPIO bits to /dev/gpiomem. This in effect masks/shields the rest of the memory space from being access and only allows the GPIO bits to be accessed. This allows access to the GPIO memory addresses and disallows any other parts of the memory, such as memory currently being used by any other programs.

In effect, this blows a hole in both security and system stability protections to allow access to the GPIO stuff, as well as the rest of the memory, but only to the users in group GPIO, which Pi is a member of.

In the future, drivers such as the bcm2835 library and wiringPi will be updated more (some updates are already happening) and the apps that are built on top of those tools will get further updated and then in the future, hopefully all this GPIO hassle as root will disappear.

Until then you have two choices, open up the /dev/mem to group gpio as read/write, or run as root, which has full read write to all of /dev/mem.

Hope that makes sense.

There are currently still some many issues where you still need to run as root. For example, using the node-red-contrib-dht-sensor module, which depends on the node-dht-sensor, which depends on BCM2835. It seg-faults using /dev/gpiomem as it has some bugs still either in node-dht-sensor or in /dev/gpiomem or the way they are working together. I don't know which is the case, but it will get worked out eventually. When BCM2835 runs as 'non-root' and /dev/gpiomem exists, it tries to use /dev/gpiomem instead of /dev/mem, so opening the /dev/mem to group gpio doesn't help. Bummer.

I can answer this.

sudo chown root.gpio /dev/mem

This changes the owner and group of /dev/mem to root and gpio respectively.

sudo chmod g+rw /dev/mem

then gives the group read write access to this /dev/mem object.

The /dev/mem object is basically the entire memory space on the system. This means that now the group gpio, and everyone in it, can read and write to the memory space.

Now, in the memory space are many things, including CPU registers. When you toggle GPIO pins, you are changing a bit in one of these registers. The kicker is, you need to be sure you do it correctly or bad bad things can happen to your system.

To help protect the entire memory space, the powers that be mapped just the memory parts that we need to work with the GPIO bits to /dev/gpiomem. This in effect masks/shields the rest of the memory space from being access and only allows the GPIO bits to be accessed. This allows access to the GPIO memory addresses and disallows any other parts of the memory, such as memory currently being used by any other programs.

In effect, this blows a hole in both security and system stability protections to allow access to the GPIO stuff, as well as the rest of the memory, but only to the users in group GPIO, which Pi is a member of.

In the future, drivers such as the bcm2835 library and wiringPi will be updated more (some updates are already happening) and the apps that are built on top of those tools will get further updated and then in the future, hopefully all this GPIO hassle as root will disappear.

Until then you have two choices, open up the /dev/mem to group gpio as read/write, or run as root, which has full read write to all of /dev/mem.

Hope that makes sense.

There are currently still some many issues where you still need to run as root. For example, using the node-red-contrib-dht-sensor module, which depends on the node-dht-sensor, which depends on BCM2835. It seg-faults using /dev/gpiomem as it has some bugs still either in node-dht-sensor or in /dev/gpiomem or the way they are working together. I don't know which is the case, but it will get worked out eventually. When BCM2835 runs as 'non-root' and /dev/gpiomem exists, it tries to use /dev/gpiomem instead of /dev/mem, so opening the /dev/mem to group gpio doesn't help. Bummer.

I can answer this.

sudo chown root.gpio /dev/mem

This changes the owner and group of /dev/mem to root and gpio respectively.

sudo chmod g+rw

then gives the group read write access to this /dev/mem object.

The /dev/mem object is basically the entire memory space on the system. This means that now the group gpio, and everyone in it, can read and write to the memory space.

Now, in the memory space are many things, including CPU registers. When you toggle GPIO pins, you are changing a bit in one of these registers. The kicker is, you need to be sure you do it correctly or bad bad things can happen to your system.

To help protect the entire memory space, the powers that be mapped just the memory parts that we need to work with the GPIO bits to /dev/memgpiogpiomem. This in effect masks/shields the rest of the memory space from being access and only allows the GPIO bits to be accessed. This allows access to the GPIO memory addresses and disallows any other parts of the memory, such as memory currently being used by any other programs.

In effect, this blows a hole in both security and system stability protections to allow access to the GPIO stuff, as well as the rest of the memory, but only to the users in group GPIO, which Pi is a member of.

In the future, drivers such as the bcm2835 library and wiringPi will be updated more (some updates are already happening) and the apps that are built on top of those tools will get further updated and then in the future, hopefully all this GPIO hassle as root will disappear.

Until then you have two choices, open up the /dev/mem to group gpio as read/write, or run as root, which has full read write to all of /dev/mem.

Hope that makes sense.

There are currently still some many issues where you still need to run as root. For example, using the node-red-contrib-dht-sensor module, which depends on the node-dht-sensor, which depends on BCM2835. It seg-faults using /dev/memgpiogpiomem as it has some bugs still either in node-dht-sensor or in /dev/memgpiogpiomem or the way they are working together. I don't know which is the case, but it will get worked out eventually. When BCM2835 runs as 'non-root' and /dev/memgpiogpiomem exists, it tries to use /dev/memgpiogpiomem instead of /dev/mem, so opening the /dev/mem to group gpio doesn't help. Bummer.

I can answer this.

sudo chown root.gpio /dev/mem

This changes the owner and group of /dev/mem to root and gpio respectively.

sudo chmod g+rw

then gives the group read write access to this /dev/mem object.

The /dev/mem object is basically the entire memory space on the system. This means that now the group gpio, and everyone in it, can read and write to the memory space.

Now, in the memory space are many things, including CPU registers. When you toggle GPIO pins, you are changing a bit in one of these registers. The kicker is, you need to be sure you do it correctly or bad bad things can happen to your system.

To help protect the entire memory space, the powers that be mapped just the memory parts that we need to work with the GPIO bits to /dev/memgpio. This in effect masks/shields the rest of the memory space from being access and only allows the GPIO bits to be accessed. This allows access to the GPIO memory addresses and disallows any other parts of the memory, such as memory currently being used by any other programs.

In effect, this blows a hole in both security and system stability protections to allow access to the GPIO stuff, as well as the rest of the memory, but only to the users in group GPIO, which Pi is a member of.

In the future, drivers such as the bcm2835 library and wiringPi will be updated more (some updates are already happening) and the apps that are built on top of those tools will get further updated and then in the future, hopefully all this GPIO hassle as root will disappear.

Until then you have two choices, open up the /dev/mem to group gpio as read/write, or run as root, which has full read write to all of /dev/mem.

Hope that makes sense.

There are currently still some many issues where you still need to run as root. For example, using the node-red-contrib-dht-sensor module, which depends on the node-dht-sensor, which depends on BCM2835. It seg-faults using /dev/memgpio as it has some bugs still either in node-dht-sensor or in /dev/memgpio or the way they are working together. I don't know which is the case, but it will get worked out eventually. When BCM2835 runs as 'non-root' and /dev/memgpio exists, it tries to use /dev/memgpio instead of /dev/mem, so opening the /dev/mem to group gpio doesn't help. Bummer.

I can answer this.

sudo chown root.gpio /dev/mem

This changes the owner and group of /dev/mem to root and gpio respectively.

sudo chmod g+rw

then gives the group read write access to this /dev/mem object.

The /dev/mem object is basically the entire memory space on the system. This means that now the group gpio, and everyone in it, can read and write to the memory space.

Now, in the memory space are many things, including CPU registers. When you toggle GPIO pins, you are changing a bit in one of these registers. The kicker is, you need to be sure you do it correctly or bad bad things can happen to your system.

To help protect the entire memory space, the powers that be mapped just the memory parts that we need to work with the GPIO bits to /dev/gpiomem. This in effect masks/shields the rest of the memory space from being access and only allows the GPIO bits to be accessed. This allows access to the GPIO memory addresses and disallows any other parts of the memory, such as memory currently being used by any other programs.

In effect, this blows a hole in both security and system stability protections to allow access to the GPIO stuff, as well as the rest of the memory, but only to the users in group GPIO, which Pi is a member of.

In the future, drivers such as the bcm2835 library and wiringPi will be updated more (some updates are already happening) and the apps that are built on top of those tools will get further updated and then in the future, hopefully all this GPIO hassle as root will disappear.

Until then you have two choices, open up the /dev/mem to group gpio as read/write, or run as root, which has full read write to all of /dev/mem.

Hope that makes sense.

There are currently still some many issues where you still need to run as root. For example, using the node-red-contrib-dht-sensor module, which depends on the node-dht-sensor, which depends on BCM2835. It seg-faults using /dev/gpiomem as it has some bugs still either in node-dht-sensor or in /dev/gpiomem or the way they are working together. I don't know which is the case, but it will get worked out eventually. When BCM2835 runs as 'non-root' and /dev/gpiomem exists, it tries to use /dev/gpiomem instead of /dev/mem, so opening the /dev/mem to group gpio doesn't help. Bummer.

I can answer this.

sudo chown root.gpio /dev/mem

'sudo chown root.gpio /dev/mem' ThisThis changes the owner and group of '/dev/mem'/dev/mem to rootroot and gpiogpio respectively.

sudo chmod g+rw

'sudo chmod g+rw' then gives the group read write access to this '/dev/mem'/dev/mem object.

The '/dev/mem'/dev/mem object is basically the entire memory space on the system. This means that now the group gpiogpio, and everyone in it, can read and write to the memory space.

Now, in the memory space are many things, including cpuCPU registers. When you toggle GPIO pins, you are changing a bit in one of these registers. The kicker is, you need to be sure you do it correctly or bad bad things can happen to your system.

To help protect the entire memory space, the powers that be mapped just the memory parts that we need to work with the GPIO bits to '/dev/memgpio'/dev/memgpio. This in effect masks/shields the rest of the memory space from being access and only allows the GPIO bits to be accessed. This allows access to the GPIO memory addresses and dissallowsdisallows any other parts of the memory, such as memory currently being used by any other programs.

In effect, this blows a hole in both security and system stability protections to allow access to the GPIO stuff, as well as the rest of the memory, but only to the users in group GPIO, which PIPi is a member of.

In the future, drivers such as the bcm2835bcm2835 library and wiringPiwiringPi will be updated more (some updates are already happening) and the apps that are built on top of those tools will get futhurfurther updated and then in the future, hopefellyhopefully all this GPIO hastlehassle as root will dissapeardisappear.

Until then you have two choices, open up the /dev/mem/dev/mem to group gpiogpio as read/write, or run as root, which has full read write to all of /dev/mem/dev/mem.

Hope that makes sense :).

There are currently still some many issues where you still need to run as rootroot. For example, using the node-red-contrib-dht-sensornode-red-contrib-dht-sensor module, which depends on the node-dht-sensornode-dht-sensor, which depends on BCM2835. It seg-faults using /dev/memgpio/dev/memgpio as it has some bugs still either in node-dht-sensornode-dht-sensor or in /dev/memgpio/dev/memgpio or the way they are working together. I don't know which is the case, but it will get worked out eventually. When BCM2835 runs as 'non-root' and /dev/memgpio/dev/memgpio exists, it tries to use /dev/memgpio/dev/memgpio instead of /dev/mem/dev/mem, so opening the /dev/mem/dev/mem to group gpiogpio doesn't help. Bummer.

I can answer this.

'sudo chown root.gpio /dev/mem' This changes the owner and group of '/dev/mem' to root and gpio respectively.

'sudo chmod g+rw' then gives the group read write access to this '/dev/mem' object.

The '/dev/mem' object is basically the entire memory space on the system. This means that now the group gpio, and everyone in it, can read and write to the memory space.

Now, in the memory space are many things, including cpu registers. When you toggle GPIO pins, you are changing a bit in one of these registers. The kicker is, you need to be sure you do it correctly or bad bad things can happen to your system.

To help protect the entire memory space, the powers that be mapped just the memory parts that we need to work with the GPIO bits to '/dev/memgpio'. This in effect masks/shields the rest of the memory space from being access and only allows the GPIO bits to be accessed. This allows access to the GPIO memory addresses and dissallows any other parts of the memory, such as memory currently being used by any other programs.

In effect, this blows a hole in both security and system stability protections to allow access to the GPIO stuff, as well as the rest of the memory, but only to the users in group GPIO, which PI is a member of.

In the future, drivers such as the bcm2835 library and wiringPi will be updated more (some updates are already happening) and the apps that are built on top of those tools will get futhur updated and then in the future, hopefelly all this GPIO hastle as root will dissapear.

Until then you have two choices, open up the /dev/mem to group gpio as read/write, or run as root, which has full read write to all of /dev/mem.

Hope that makes sense :)

There are currently still some many issues where you still need to run as root. For example, using the node-red-contrib-dht-sensor module, which depends on the node-dht-sensor, which depends on BCM2835. It seg-faults using /dev/memgpio as it has some bugs still either in node-dht-sensor or in /dev/memgpio or the way they are working together. I don't know which is the case, but it will get worked out eventually. When BCM2835 runs as 'non-root' and /dev/memgpio exists, it tries to use /dev/memgpio instead of /dev/mem, so opening the /dev/mem to group gpio doesn't help. Bummer.

I can answer this.

sudo chown root.gpio /dev/mem

This changes the owner and group of /dev/mem to root and gpio respectively.

sudo chmod g+rw

then gives the group read write access to this /dev/mem object.

The /dev/mem object is basically the entire memory space on the system. This means that now the group gpio, and everyone in it, can read and write to the memory space.

Now, in the memory space are many things, including CPU registers. When you toggle GPIO pins, you are changing a bit in one of these registers. The kicker is, you need to be sure you do it correctly or bad bad things can happen to your system.

To help protect the entire memory space, the powers that be mapped just the memory parts that we need to work with the GPIO bits to /dev/memgpio. This in effect masks/shields the rest of the memory space from being access and only allows the GPIO bits to be accessed. This allows access to the GPIO memory addresses and disallows any other parts of the memory, such as memory currently being used by any other programs.

In effect, this blows a hole in both security and system stability protections to allow access to the GPIO stuff, as well as the rest of the memory, but only to the users in group GPIO, which Pi is a member of.

In the future, drivers such as the bcm2835 library and wiringPi will be updated more (some updates are already happening) and the apps that are built on top of those tools will get further updated and then in the future, hopefully all this GPIO hassle as root will disappear.

Until then you have two choices, open up the /dev/mem to group gpio as read/write, or run as root, which has full read write to all of /dev/mem.

Hope that makes sense.

There are currently still some many issues where you still need to run as root. For example, using the node-red-contrib-dht-sensor module, which depends on the node-dht-sensor, which depends on BCM2835. It seg-faults using /dev/memgpio as it has some bugs still either in node-dht-sensor or in /dev/memgpio or the way they are working together. I don't know which is the case, but it will get worked out eventually. When BCM2835 runs as 'non-root' and /dev/memgpio exists, it tries to use /dev/memgpio instead of /dev/mem, so opening the /dev/mem to group gpio doesn't help. Bummer.

added 586 characters in body
Source Link
Loading
Source Link
Loading