pderocco
Posts: 7
Joined: Wed Dec 12, 2012 10:42 pm

Order of overlay loading during boot

Mon Oct 01, 2018 1:59 am

I have a tentative circuit for power switching the RPi CM3 that behaves like the power switching in a PC:

1) Pressing the button while the power is off turns it on;
2) Pressing the button again in the early stages of the boot turns it off;
3) Pressing the button once the system has enabled write access to the file system activates a shutdown request;
4) Holding the button unconditionally forces the power off after five seconds.

The circuit can be powered from the coin cell that runs the RTC while off, and from the wall power while on.

Since the function of the button must change at a particular point in the boot, I'm wondering if this is possible using the gpio-poweroff and gpio-shutdown overlays. I should be able to configure the latter so that the weak pullup on GPIO 26 keeps it low in the early boot, then it is driven high when the overlay initializes, and then low again when shutdown is complete. But there are two questions:

1) Is it guaranteed that overlays are loaded and initialized before the root file system is mounted as read/write?
2) Is there a way to control the order of overlays, so that gpio-shutdown is ready to respond to a shutdown request before gpio-poweroff has told my circuit to change the button function?

pderocco
Posts: 7
Joined: Wed Dec 12, 2012 10:42 pm

Re: Order of overlay loading during boot

Mon Oct 01, 2018 8:02 am

One more question:

3) Is it guaranteed that when gpio-shutdown is initialized, there is an actual shutdown procedure that will shut things down? Or is there a short period when the GPIO has been configured to invoke some code enabled by the overlay, but it isn't actually able to do the shutdown?

I'm even seeing a race problem for me. I would like the shutdown to trigger the gpio-poweroff function, but that would involve installing it first, which means that there would be a short time in which my button is configured to assert a shutdown request before gpio-shutdown has been installed. Drat.

Does anyone have any insights into this? Or am I completely misunderstanding how device tree overlays are handled?

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1907
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Order of overlay loading during boot

Mon Oct 01, 2018 9:03 am

A1 and A2) Device Tree overlays applied by the firmware (via config.txt) become part of the main Device Tree, so the question becomes one of the order of initialisation of the kernel and its devices, rather than the overlays. It isn't generally possible to control the order of device initialisation except (in some cases) by modifying the drivers to make them load early, or by using a blacklist and forcing a specific module order, making them load late.

The gpio-poweroff driver is built into the kernel and loaded very early. The gpio-keys driver that implements gpio-shutdown is a module and loaded after the rootfs goes read/write. Making gpio-keys load earlier may be possible, but there has to be a system process running to detect the power-off key being pressed and trigger a shutdown, so it probably won't make any practical difference.

More fundamental, though, is the fact that gpio-poweroff doesn't trigger a power down. Instead, fhe gpio-shutdown and gpio-poweroff overlays work together:
* gpio-shutdown allows a shutdown to be started by a GPIO, and
* gpio-poweroff indicates to external circuitry that the shutdown has completed and it is safe to switch off the power.

Unless you are really short of GPIOs and feel up to using some tricky analogue circuitry to allow a single GPIO to be used first for input then for output, it is much simpler to give each overlay a different GPIO.
The 5-second hard shutdown feature would then be implemented with an RC network or timer IC.

pderocco
Posts: 7
Joined: Wed Dec 12, 2012 10:42 pm

Re: Order of overlay loading during boot

Mon Oct 01, 2018 11:43 pm

PhilE wrote:
Mon Oct 01, 2018 9:03 am
The gpio-poweroff driver is built into the kernel and loaded very early. The gpio-keys driver that implements gpio-shutdown is a module and loaded after the rootfs goes read/write. Making gpio-keys load earlier may be possible, but there has to be a system process running to detect the power-off key being pressed and trigger a shutdown, so it probably won't make any practical difference.
Thanks, that's good info.

Let's see if I've got this right. Initially, a falling edge on GPIO3 will do nothing. Once gpio-keys is loaded, a falling edge on GPIO3 will send a power key event, but it goes into the bit bucket. Once systemd has started a process that listens for the power key event, a falling edge on GPIO3 will send that event, and that process will run a script that tells systemd to shut the system down.

It sounds like none of these occurrences are buffered in any way, so it isn't sufficient just to hold GPIO3 low and wait for something to happen, or even to generate an edge after gpio-keys is loaded. It sounds like an actual falling edge must be generated after both gpio-keys is loaded and systemd has started the shutdown monitoring process. Is that right?

If that's true, then I have no choice but to assume it's never safe to yank the power, and to assume that something will be ready to respond to a shutdown request soon but not necessarily right now. The only solution I see is to have my circuit generate a pulse train that keeps trying to initiate a shutdown until it eventually responds. The easiest thing to do would be to gate some existing clock into GPIO3--the Ethernet/USB chip has both 25MHz and 24MHz available. Do you think that hitting an IRQ GPIO at that rate would bring the system to its knees?

pderocco
Posts: 7
Joined: Wed Dec 12, 2012 10:42 pm

Re: Order of overlay loading during boot

Tue Oct 02, 2018 10:06 pm

Actually, I have a better way. I have a Kinetis K26 in my project already, for providing a USB device port. Since it boots up almost instantly, I can have it do any kind of power-down logic I want in firmware, including pulsing the GPIO 3 on the RPi CM3 at some more reasonable rate like 4Hz. Now that I think of it, it can even have it emulate the RTC chip I was going to use, and save a buck.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1907
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Order of overlay loading during boot

Wed Oct 03, 2018 8:29 am

I think that's going to work out better for you. You could possibly even use the K26 to monitor the state of another GPIO to work out if the kernel has started to boot, and just forcing the power off in the case it doesn't.

pderocco
Posts: 7
Joined: Wed Dec 12, 2012 10:42 pm

Re: Order of overlay loading during boot

Thu Oct 04, 2018 1:31 am

Sounds good. Thanks a lot for your help.

Return to “Device Tree”