Update BoneScript for BeagleBone Blue

GoogleGroups
1

I’m in the process of updating BoneScript to use the GPIO pins and the red and green LEDs on the Blue[1].
The are two gpio connectors, GP0 and GP1, so I’m labeling the pins
GP0_3, GP0_4, GP0_5 and GP0_6. This is because the first two pins on each connector is ground and 3.3V, so the 3rd pin is the first GPIO pin.
I also have GP1_3 and GP1_4. GP1_5 is the RED_LED and GP1_6 is the GREEN_LED, so I don’t define them.

So far I have the Red and Green LEDs working. I just had to adjust for the different path in /sys/class/leds

The GPIO pins are a bigger challenge.

GP0_4 and GP0_6 map to P9_23 and P9_28 respectively, making them easy to do.
The rest are tricky to do since none of them have a pinmux in /sys/devices/platform/ocp and BoneScript wants to be sure the pinmux is set correctly.
My hackaround is check for a pinmux and if not found, ignore the mux and hope it’s set correctly.
What’ the correct why to do this? That is, how do I set the pinmuxes for gpios 57, 116, 98, and 97?

I have a second problem that comes from running as debian, not root. Let’s say we are setting the pinMode for GP0_3 which is gpio 57,
bonescript checks /sys/class/gpio to see if gpio57/value is there, if not it writes 57 to /sys/class/gpio/export and gpio57 appears.
This works fine.
Next it writes “out” to gpio57/direction. This fails because of write permissions. But it you rerun the BoneScript it succeeds. It appears to be a timing problem. BoneScript is writing to the file before the OS can set the permissions so debian to write to it.
How do we fix this?

Thanks…

–Mark

[1] GitHub - MarkAYoder/bonescript: Scripting tools for the BeagleBoard and BeagleBone

2

I’m in the process of updating BoneScript to use the GPIO pins and the red and green LEDs on the Blue[1].
The are two gpio connectors, GP0 and GP1, so I’m labeling the pins
GP0_3, GP0_4, GP0_5 and GP0_6. This is because the first two pins on each connector is ground and 3.3V, so the 3rd pin is the first GPIO pin.
I also have GP1_3 and GP1_4. GP1_5 is the RED_LED and GP1_6 is the GREEN_LED, so I don’t define them.

So far I have the Red and Green LEDs working. I just had to adjust for the different path in /sys/class/leds

The GPIO pins are a bigger challenge.

GP0_4 and GP0_6 map to P9_23 and P9_28 respectively, making them easy to do.
The rest are tricky to do since none of them have a pinmux in /sys/devices/platform/ocp and BoneScript wants to be sure the pinmux is set correctly.
My hackaround is check for a pinmux and if not found, ignore the mux and hope it’s set correctly.
What’ the correct why to do this? That is, how do I set the pinmuxes for gpios 57, 116, 98, and 97?

I’m creating a new master pin list based on show-pins.pl. That script is currently smart enough to list off the driver that owns the pinmux, so you can see how that works. If it is a “pinmux_helper”, then you can write the “state” sysfs entry with “gpio”, “gpio_pu” or “gpio_pd” by the cape-universal convention.

There needs to be some parallel updates to the am335x-boneblue.dts source to add the various helper modes. Further, I had thought that the “0” entry would be selected by default, so I removed the redundant “default” mode, but it seems there might be something important about the name, so I need to put those back using the defaults based on the assigned connector functions.

I have a second problem that comes from running as debian, not root. Let’s say we are setting the pinMode for GP0_3 which is gpio 57,
bonescript checks /sys/class/gpio to see if gpio57/value is there, if not it writes 57 to /sys/class/gpio/export and gpio57 appears.
This works fine.
Next it writes “out” to gpio57/direction. This fails because of write permissions. But it you rerun the BoneScript it succeeds. It appears to be a timing problem. BoneScript is writing to the file before the OS can set the permissions so debian to write to it.
How do we fix this?

Could be ugly, but we could look for either udev or filesystem events, at least in the asynchronous case. Perhaps more brute force would be to use a test permissions in a loop with a timeout.

Because the permissions problem is being solved with udev, we are going to have challenges. This issue response has some instructive thoughts: https://github.com/rear/rear/issues/791

A kernel patch to set the default permissions different might be preferred.