enble boot after power loss/restore

[dkebler]

Wanting the board to power when power is connected (i.e. after power is restored after power loss)

Hmmm....  I have a one RP64 that starts this way.  I dug out my spare and it does not without hitting the power button.  

Maybe there is a jumper that needs to be set.  It was so long ago I set the first board up I can't remember and I don't see anything at the wiki that says to set a jumper for this.

Little help please.

[Rocklobster]

Wanting the board to power when power is connected (i.e. after power is restored after power loss)

Hmmm....  I have a one RP64 that starts this way.  I dug out my spare and it does not without hitting the power button.  

Maybe there is a jumper that needs to be set.  It was so long ago I set the first board up I can't remember and I don't see anything at the wiki that says to set a jumper for this.

Little help please.

Are both boards using identical setups. Same OS booting from SD card.

[dkebler]

Wanting the board to power when power is connected (i.e. after power is restored after power loss)

Hmmm....  I have a one RP64 that starts this way.  I dug out my spare and it does not without hitting the power button.  

Maybe there is a jumper that needs to be set.  It was so long ago I set the first board up I can't remember and I don't see anything at the wiki that says to set a jumper for this.

Little help please.

Are both boards using identical setups. Same OS booting from SD card.

Have latest armbian on emmc but I don't think the module or os is the issue.   As a test I pulled the emmc card.   Then plug in power.   Older unit (it's in a pine 64 NAS box with SATA card) powers (e.g. lights on ethernet port light, drives spin up, fans on).   This new board (with nothing attached) doens't without pressing  power and reset (at the same time, weird).      Now put emmc back in.   Exact same behavior

If it had a bios like an amd board it's just go into cmos and set this.   But I just never remember having to set anything like this (jumper, something from serial interface) on R64Pro

[ok38]

Hello,

I have the same issue, did you found how to fix the issue ?

I flashed the SPI with u-boot mainline of Sigmaris to be able to boot on PCIe SATA card. I have a 12V 5A EU power supply. I also tried to flash with Ayufan but the board won't initialize boot sequence (even if I unplug all extension board) unless I press power button.

Do you have any idea ?

Thank you.

[ok38]

OK, I found. I just needed to add RTC battery.

Thanks.

[gechu]

OK, I found. I just needed to add RTC battery.

Thanks.

I ordered a RTC BACKUP BATTERY HOLDER - CR-2032. But it still doesn't resume automatically after power failure.

Did you get the RTC BACKUP BATTERY HOLDER – 2 X AAA?

[dkebler]

Ok so now I have four rockpro64 boards available for testing. Only this one stubborn board refuses to boot after power loss. I must hold down the on/off button for 3 seconds, then short press then it will start.

The offending board is year plus old but has not been in service. Of the 4 two are brand new and the other is the same vintage (no problems with it).

So what could be the reasons that this one board (and only this board) not power up after power loss? It's telling that I can't just hit the on/off button once for it to boot. I must "shutown" the board first with a long press and start again with a short press.

Makes me think that some bootstrap circuit/firmware is hung on poswerloss power on vs power on via the button. At this point it's a bummer not a brick. I won't be able to use it headless/unattended if I can't get to start after power loss.

[gechu]

Good to see that I'm not alone in having a Rockpro64 board that does not behave properly. Here's a writeup of where I am in my investigation work. Patience is running low

Reading about ARM trusted firmware, a part of it appears to be related to power management ARM Power State Coordination Interface - Platform Design Document.

While you could build a u-boot for the device, pre-build binaries seems to be available here: Arm Trusted Firmware (TF-A) for rk3399, as well as from Sigmaris.

I'm running OpenWrt (22.x), and it uses arm-trusted-firmware-rockchip version 2.3, whereas the latest version is 2.6. When I've tried running something different than OpenWrt, the LAN port didn't work reliably (i.e. using Armbian).

I've added a PCIE Intel I350-T4 NIC to my Rockpro64. And bought a RTC battery (RTC BACKUP BATTERY HOLDER - CR-2032), because I read someone had success enabling automatic resume from power failure using it. But it didn't work. Raised a support ticket to pin64, which is still in progress.

In the Manjaro release, they make use of atf 2.6, and a patch that would enable suspend/resume (not sure it has any impact on this issue though).

Here's instructions to patch u-boot from OpenWrt (not specific to rockpro64). However, these instructions from Manjaro to patch u-boot I guess could be adopted to patch u-boot in OpenWrt.

And here's info from Manjaro community how the RockPro64 has a built in BOOTROM, which checks for valid boot sectors on different devices.

Rockpro64 uses rk808 for managing RTC, you could instruct it to create a wake-alarm every 30 second, that (I assume) would try to wake the device in case it gets into a shutdown state due to a power failure. I haven't tried, but perhaps if there is no power at the time of a wake-alarm, then the device may not boot, and perhaps there's no functionality to retry missed alarms. To be tried though.
Read more about how RTC wake-alarms works at firefly wiki.

EDIT: Also wanted to add a link to Automatically run after power recovery - but it is way too advanced for me.

[dkebler]

@gechu, thanks all good information.

One of the comments in last link(thread) had me thinking I've seen the green led lit for a bit even after disconnecting the barrel connector (meaning some residual energy stored in the board (caps and such).

In my former testing of all four boards I just unpluged, waited a second and plugged back in. So I did a few trials and if I set a timer for 1min then the board would BOOT every time on plugging back in the barrel connector.

Ok that's better. Of course a power "blib" might result in the board not coming back up but a regular power outage should come back up. So something is not quite the same on that board as the others where I can unplug and plug quickly and they will boot.

Makes me want to put a 20K resistor between 5V pin and ground see if having a "bleed" would "fix" the issue. Worst case if this can happen I can use an esp32 as a watchdoog and if board doesn't come up the watchdog an give it a good 1 min power off power cycle.

Well at least now I know it is not firmware (u-boot/spi) related. I didn't think it was because I had shorted pins 23 and 25 which is supposed to bypass spi booting and that didn't change a thing.

[gechu]

Are you thinking about this watchdog ESP32 Reset Circuit?