George Hawkins Posted May 9, 2019 Posted May 9, 2019 So the question is "why does disconnecting and reconnecting power cause a shutdown SBC to boot?" If I have an SBC and I shut it down (e.g. using "shutdown now") then it enters an inactive state. However, I haven't done anything with the power supply - the board is still powered. So what changes in the state of the board as a result of cycling the power? If nothing changed then it would continue in the same inactive state as before? But instead, it boots up when power is restored. I'm guessing the answer varies by board. On the Raspberry Pi it seems that on doing a shutdown the shutdown process writes a volatile magic number that can be read by the bootloader - so shutdown and reboot are indistinguishable except for this magic value, In both cases the system essentially reboots and it's the bootloader that decides what happens next. If it can read the magic value then it puts the system into a very low power state, i.e. essentially shutdown. If the magic value isn't present (or has been lost as a result of being power cycled) then the bootloader instead lets the normal boot sequence continue. On the Pi, the shutdown has only really paused the boot sequence - if you pull the GPIO3 pin low then the processor is brought out of its lower power state and the boot sequence continues. Interestingly/oddly I can't find any really definitive reference for this behavior - it just seems to be generally well known (e.g. it's described in this Github comment by the Kodi developer popcornmix). Is this typical behavior or is there similar typical behavior that's observed by many SBCs? I'm interested as I have a Jetson Nano and I want to determine how one might get it to boot after it's been shutdown, without actively having to disconnect and reconnect the USB power supply. What typically changes in the state of the board as a result of power cycling and is there generally a way to achieve this without doing a power cycle? I'm most interested in safe approaches that don't involve power cycling, e.g. pulling GPIO3 low on a running Pi does nothing, i.e. is safe, it's only when it's been shutdown that it does something interesting and allows the boot sequence to proceed. I asked this question on the Nvidia Nano forums but didn't get very far. I thought people on the Armbian forums, with experience of many SBCs and their behavior during shutdown and boot, might have some insight.
chrisf Posted May 10, 2019 Posted May 10, 2019 Most SBC's don't have proper power management. As an example of the Raspberry Pi, when you do a software shutdown, the main VideoCore processor is still running, waiting for you to wake it back up with the GPIO pin. When you first apply power, it's not in that state. There is no non-volatile memory to remember the previous state. Power consumption in the soft-off state isn't much lower than idle. In PC's this is stored in the BIOS's battery backed SRAM. The motherboards controller chip (usually some kind of microcontroller, Apple call theirs the "SMC") is what manages the power for the whole system. monitoring the power button, enabling and disabling power rails and resetting the CPU. SBC's don't tend to have that. They just have a PMIC chip and the SoC.
sfx2000 Posted May 27, 2019 Posted May 27, 2019 Interesting question - what's the use case that is being handled here? With RPi - keep in mind that the ARM's and Linux run as a guest device to VC4 and Threadx, and VC4 controls the GPIO bus, not the ARM(s) - so what happens on RPi, might not be consistent with other boards that break out the 40-pin interface. Look at J40 on the Jetson carrier board... as indicated in the Jetson Nano User Guide Hope this helps... sfx
sfx2000 Posted May 27, 2019 Posted May 27, 2019 30 minutes ago, sfx2000 said: With RPi - keep in mind that the ARM's and Linux run as a guest device to VC4 and Threadx, and VC4 controls the GPIO bus, not the ARM(s) - so what happens on RPi, might not be consistent with other boards that break out the 40-pin interface. In some ways, I think Jetson is similar to the BCM20xx series on Pi - the GPU runs the house, not the ARM's, they're just the guests of the GPU... which makes sense, as the GPU is the driver for memory bandwidth. There's a Cortex-A7 on Jetson that runs power management, and it works alongside the HW PMIC, which is where J40 breaks out for things... Anyways - review the L4T docs, along with the Jetson TX1 developer documents. https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide%2Fintroduction.html%23
Recommended Posts