Dtoverlay, gpio-shutdown and gpio-poweroff options not working?

Product support balenaOS
1

Hello,

I am setting up our first balena containerized application. We have dockerfile and 4 containerized services. After quite a bit of effort I have managed to get all of services up and running, looking good.

However, I am having problems getting dtoverlay to work for 2 GPIO pins used to communicate with connected hardware co-coordinating shutting the whole system down.

We are using the following overlays:

dtoverlay=gpio-poweroff,gpiopin=24,active_low=1
dtoverlay=gpio-shutdown,gpio_pin=4,active_low="y"

I have added these values to the balena image before booting (I have also tried using web ui to assign the values)…

Anyway: I can see from the host os ‘/boot/config.txt’ does not contain these values. However, I do see that /mnt/boot/config.txt (resin-boot/config.txt) have the appropriate entries in these files.

These overlays DO NOT take effect in the balenaOS image that I have set up. However, our own image running on straight raspian work as expected.

I have run out of things to try, logs to read or anything else that may give me a clue.

Can somebody please help give me a clue what could be going wrong, or how I might go about debugging this further?

All help in greatly appreciated in advance!

Thank You!

3

Hey @rustyeddy. The values should indeed show in /mnt/boot/config.txt, as that’s the in-use config.txt file, the /boot/config.txt is a default one, that got shipped with the OS, and we are considering removing from the future, that it is also confusing. You should be concerned only with the former one, that does contain the values as you mention.

I’ve just tried this out, followin the readme:

Based on this one:

  • gpio-poweroff is a pin that at the end of the shutdown should have a certain voltage value
  • gpio-shutdown is a pin that can be used to initiate a shutdown.

I was playing with the pins a bit, but so far it seems working exactlu as expected. What I tried are these two:

dtoverlay=gpio-shutdown,gpio_pin=4,active_low=1

Touching the relevant pin shuts down the device (quickly). Once managed to catch the message:

Oct 14 11:10:35 010335c systemd-logind[708]: Power key pressed.

and thus that’s further signal that things work as expected

For the gpio-poweroff, reading that readme, it needs a custom dt-blob.bin for active_low to work, so I didn’t enable that, just

dtoverlay=gpio-poweroff,gpiopin=24

At the end of the shutdown, when the device is off, I did measure 3.3V (high) on the relevant pin as expected.

I’ve also tried other pins, and seem to be all working correctly.

Thus I suggest removing the active_low from gpio-poweroff if possible, and try it like that.
Also, in the dashboard, if you want to add multiple dtoverlay values, you can add them as comma-separated strings (similarly how RESIN_HOST_CONFIG_dtparam is by default for multiple values,), ie. setting a configuration variable RESIN_HOST_CONFIG_dtoverlay with value "gpio-poweroff,gpiopin=24","gpio-shutdown,gpio_pin=4,active_low=1" will result in

dtoverlay=gpio-poweroff,gpiopin=24
dtoverlay=gpio-shutdown,gpio_pin=4,active_low=1

at /mnt/boot/config.txt.

Hope this helps, and when you recheck it will work for you properly! Please let us know if you have any questions!

5

@imrehg, Thank You for the reply. I will test with 'active_low=‘y’" just as you did in attempt to accomplish the same results. As it it seems like it should pretty much “just work”…

I did neglect to mention that I am trying to get an RPI-2 going, I do not know that would make a difference.

I will double over my tracks and attempt to reproduction the exxpected outcome.

In the meantime, Perhaps we will need to engage in your professional services in case I do not make any progress… If so, how would I initiate a project to ensure we get our dtoverlays working correctly, if that is possible?

Thank You!

6

OK, I officially signed up for the support package, I’ll take this conversation to that channel…

I did try walking through this again, but it did not behave as expected… I’m sure I’m doing something silly…

8

So, just for the record, I have signed up for paid support, up to this point even paid support does not seem to be able to get these overlay’s to work.

I have even built a minimal app consisting of a docker-compose.yml and a single container/Dockerfile. I am not convinced the overlay’s are being applied from the /mnt/boot/config.txt file when the image boots…

9

@imrehg Perhaps you can share what you did to get your overlay to work?

Thank You!

11

(at)imrehg Perhaps you can share what you did to get your overlay to work?

Reading the internal and public thread notes from imrehg, it looks like there wasn’t any special trick, so to speak. Something that occurs to me is whether you might have been attempting to edit the /mnt/boot/config.txt file directly, instead of adding the dtoverlay settings via the web dashboard. The balena supervisor running on the device will overwrite the /mnt/boot/config.txt file with settings added to the web dashboard, so it is necessary to add the settings to the dashboard – imrehg mentioned the comma-separated syntax to use.

13

I believe I mentioned previously, that we are seeing updates to the web dashboard fail. I am not editing /mnt/boot/config.txt directly.

I had opened access for support perhaps, the output

14

Sent previous response to soon, I meant to say that I opened access for support yesterday. I assume somebody could have quickly checked to verify the updates I did.

As previously reported, the changes I made to dtparams in the web console caused a reboot of the device, once the device had rebooted I could see the /mnt/boot/config.txt on the newly rebooted system was update accordingly. (with no editing
from me).

Also, I am interested to here about
@imrehg setup and how it may have differed from what we have…

At this point, it does not seem like anybody has any ideas on why our balenaOS devices dtoverlay fails?

Looking forward to some clues!

Thanks,

  • rusty
17

Hi, I am re-posting the findings of a teammate here:

On a RPi2 running OS v2.43.0+rev1, I added the Device variable RESIN_HOST_CONFIG_dtoverlay with the following content:
“gpio-poweroff,gpiopin=24,active_low=1”,“gpio-shutdown,gpio_pin=4,active_low=1”

When I connect GPIO4 to ground, the board shuts down and GPIO24 is set to low.
Otherwise, when board is running, GPIO24 is high by default.

This is the contents of my config.txt:

root@806c68e:~# cat /mnt/boot/config.txt 
avoid_warnings=1
disable_splash=1
dtoverlay=gpio-poweroff,gpiopin=24,active_low=1
dtoverlay=gpio-shutdown,gpio_pin=4,active_low=1
dtparam=i2c_arm=on
dtparam=spi=on
dtparam=audio=on
gpu_mem=16

So everything works as expected. The application running shouldn’t matter, because this is an OS feature.

When connecting GPIO4 to ground, board becomes Offline in dashboard.

Also, it takes about 30s for the GPIO24 to become low after connecting GPIO4 to ground.

19

@majorz Thank You for posting a working version, I will verify this today.

So this means the online dashboard entries for Device and Fleet configuration of ‘dtparam’ is Broken, the Balena documentation must also be fixed, accordingly. One must NOT use the documented procedure. Rather, we must set the variable directly.

Thanks for figuring this out.

  • rusty

Whereas I need to ignore the ‘dtparams’ as

20

I do not think the dashboard functionality is broken. Can you please let us know how exactly you enter dtoverlay settings from the dashboard?

22

In the dashboard on ‘fleet configuration’, I used the entry ‘Define DT params’ I placed the following entry:

“gpio-poweroff,gpiopin=24,active_low=1”,“gpio-shutdown,gpio_pin=4,active_low=1”

Which the documentation says to do.

That does not work.

23

One more thing, there is no “dtoverlay” settings on the dashboard that I can find. I was using the ‘dtparams’ setting.

24

That’s start to makes sense now. You need to define it - RESIN_HOST_CONFIG_dtoverlay. Below the section you are using now. Please let us know if that works for you.

I think it should probably be exposed though on the dashboard by default like the dtparams. I will ping my team about this.

Thanks,
Zahari

27

I think even more important, the documentation should be updated to reflect the current reality. The documentation is misleading as is, which resulted in about about 4-5 days time to get this problem resolved, in no small part due to time differences.

All the same, Thank You for posting correct procedure. I will test this tomorrow when I am with the equipment again.

  • rusty
28

Hey @rustyeddy I’m just checking out our documentation, specifically the section on Setting device tree overlays. Could you clarify what changes you’re proposing here? Reading through the docs seems to tie up with what you did to get this working but if there’s another page let me know or add an issue directly in the docs repo and we’ll make sure it gets updated!

30

Thanks for the help, I have missed the distinction between dtparams and it usage in the Dashboard vs. creating a separate dtoverlay custom value. I am still not clear on the difference, but it works so I guess, “who cares”.

In hindsight I should have inferred that I was NOT to use the dtparms entry.