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.
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:
Touching the relevant pin shuts down the device (quickly). Once managed to catch the message:
Oct 14 11:10:35 010335c systemd-logind: 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
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
@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?
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…
(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.
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
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?
@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.
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.
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!
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.