[A06] Suspend to ram is working

It’s finally here, following 6 months of experiments and failures.

A06 now suspends to ram, which means <100mA power draw.
I’m estimating >2day standby time, need testing.

As much as I want to provide ready-to-use packages… Currently it’s a bit rough and only for ArchLinux.
@guu I’m looking forward to clockworkpi team to integrate this to Armbian.
@m4xm4n it’s (partially) a PKGBUILD so I guess it’s easy for Manjaro :slight_smile:

The gradients of successful A06 suspend:

  • Hardware
  • Kernel
    • [success] mainline kernel
    • [too old for current Arch userspace] rockchip BSP 4.19
  • Kernel’s interface to PSCI
    • [success] Rockchip’s kernel patch to interface with ATF (SIP)
    • [no gpio configuration] standard PSCI interface only
  • bootloader (BL33)
    • [success] mainline u-boot
    • [doesn’t compile] Rockchip’s u-boot
  • Trusted firmware (ATF, BL31)
    • [success] Rockchip’s closed-source trusted firmware, modify RKTRUST/RK3399TRUST.ini and remove BL32 (optee)
    • [kernel panic] Rockchip’s closed-source trusted firmware
    • [does not detect wakeup interrupt] upstream ATF
    • [does detect wakeup interrupt, stuck at M0 firmware] modded upstream ATF
  • Second stage loader
    • [success] Rockchip’s closed-source miniloader
    • [passes resume M0 firmware and power-up FSM, but power draw stuck at 300mA, kernel not resumed] u-boot SPL/TPL

I’ve tried almost every possible combination… and all of a sudden the screen lights up indicating a successful resume from deep sleep. I had to check twice to make sure it’s not s2idle fooling me :slight_smile:

Kernel side patches: arch-linux-arm-clockworkpi-a06/linux-clockworkpi-a06 at main · yatli/arch-linux-arm-clockworkpi-a06 · GitHub
U-boot: arch-linux-arm-clockworkpi-a06/uboot-clockworkpi-a06 at main · yatli/arch-linux-arm-clockworkpi-a06 · GitHub
Guide: uboot+miniloader: doc/README.rockchip · master · U-Boot / U-Boot · GitLab

  • Modify rkbin/RKTRUST/RK3399TRUST.ini:
--- a/RKTRUST/RK3399TRUST.ini
+++ b/RKTRUST/RK3399TRUST.ini
@@ -8,9 +8,7 @@ SEC=1
 PATH=bin/rk33/rk3399_bl31_v1.35.elf
 ADDR=0x00040000
 [BL32_OPTION]
-SEC=1
-PATH=bin/rk33/rk3399_bl32_v2.10.bin
-ADDR=0x08400000
+SEC=0
 [BL33_OPTION]
 SEC=0
 [OUTPUT]

Guess I need to buy a second A06 for uConsole!

TODO

  • Hibernate doesn’t work
  • Figure out how rk808 interrupt is connected, so we can have RTC timer wakeup
    • Always feel something wrong about rk808 – it should be always powered on by VCC-RTC as long as there’s a battery, right?
  • [Done] VCC_5v remains active. This means the keyboard + any attached usb devices are powered (in my case, an internal usb hub)
  • [Done ](oops) clean up the devicetree – currently the power key is mapped as “UP” key…
    • Trigger only for negative edge
    • Disable axp22x-pek – they fire multiple suspend/resume signals so sometimes it goes to sleep again right after resume.
  • Wifi/BT/Serial wakeup possible?
    • Yes, there are host wakeup signals connected correctly
12 Likes

(reserved for future updates)

What R124?

USB VBUS power control mod

Note, connect the R116 left side pad to a R10K. Verify with a multimeter that it is NOT connected to R117!

Note, connect R508 left side pad, or the power chip pin. Make sure it’s not connected to the right side pad which is 5V!

Battery life test, no USB VBUS mod

2022-12-2 01:42:51 100%
2022-12-2 08:26:54 90%
2022-12-2 11:06:02 89%
2022-12-2 12:25:01 87%
2022-12-2 13:35:47 86%
2022-12-2 15:50:46 79%
2022-12-2 18:35:15 70%
2022-12-2 21:47:34 62%
2022-12-2 22:54:00 57%
2022-12-2 23:53:51 53%
2022-12-3 00:47:18 50%
2022-12-3 01:47:36 45%
2022-12-3 03:04:20 39%
2022-12-3 13:25:29 5%
2022-12-3 13:42:54 4%
2022-12-3 14:46:05 3%
2022-12-3 15:24:10 3%

Very likely it will do >2days…
Edit: uh oh the fuel gauge not very linear.
We may need to add support for axp228 battery capacity calibration.

Current projection:
image

Battery life test, with USB VBUS mod (kbd off in suspend):

2022-12-23 01:39:02 100% – good luck!

4 Likes

Amazing work! Can’t wait to try it out!

1 Like

yay a cool chart :grin:
moar! \o/

Data still being updated :smiley:

Edit: well yeah, about two days.
Can probably get a little bit more if we halt the STM32 on the keyboard.

2 Likes

You are a steely-eyed missile man.

I salute you sir for your persistence in pursuing this :wink: . From my side I can only confirm I can reproduce your success with s2ram on my end.

BTW when entering suspend I see the following warning in dmesg:

[ 4472.480511] clk_spi4 already disabled
[ 4472.480589] WARNING: CPU: 2 PID: 105265 at drivers/clk/clk.c:963 clk_core_disable+0xa4/0xb0
[ 4472.480622] Modules linked in: brcmfmac brcmutil cdc_acm panel_cwd686 hci_uart btbcm
[ 4472.480662] CPU: 2 PID: 105265 Comm: systemd-sleep Tainted: G        W       T  6.0.11-devterm-r2+ #4
[ 4472.480672] Hardware name: Clockworkpi A06 (DT)
[ 4472.480679] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 4472.480690] pc : clk_core_disable+0xa4/0xb0
[ 4472.480698] lr : clk_core_disable+0xa4/0xb0
[ 4472.480704] sp : ffff8000094f3a40
[ 4472.480708] x29: ffff8000094f3a40 x28: ffff000000a788f8 x27: ffff80000868a264
[ 4472.480722] x26: 0000000000000002 x25: ffff800009130a7c x24: ffff800009250c78
[ 4472.480735] x23: 0000000000000000 x22: ffff8000092c5000 x21: ffff0000014c1a80
[ 4472.480748] x20: ffff000000392300 x19: ffff000000392300 x18: fffffffffffc9ff0
[ 4472.480761] x17: 000000040044ffff x16: 00100072b5503510 x15: 0000000000000028
[ 4472.480774] x14: 00000000000003f0 x13: 0a64656c62617369 x12: 642079646165726c
[ 4472.480788] x11: ffff800009130fe0 x10: 2d2d2d2d2d2d2d2d x9 : ffff8000094f3a40
[ 4472.480801] x8 : ffff800009130f98 x7 : ffff8000094f3830 x6 : 000000000000000d
[ 4472.480813] x5 : ffff0000f7770850 x4 : 0000000000000000 x3 : 0000000000000027
[ 4472.480825] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000068aa3f00
[ 4472.480839] Call trace:
[ 4472.480843]  clk_core_disable+0xa4/0xb0
[ 4472.480852]  clk_disable+0x30/0x50
[ 4472.480861]  rockchip_spi_suspend+0x34/0x70
[ 4472.480875]  dpm_run_callback+0x50/0xf4
[ 4472.480886]  __device_suspend_noirq+0xe4/0x23c
[ 4472.480896]  dpm_noirq_suspend_devices+0x13c/0x220
[ 4472.480904]  dpm_suspend_noirq+0x24/0xa0
[ 4472.480913]  suspend_enter+0x80/0x2f4
[ 4472.480928]  suspend_devices_and_enter+0x15c/0x1fc
[ 4472.480938]  enter_state+0x200/0x288
[ 4472.480949]  pm_suspend+0x58/0xd0
[ 4472.480959]  state_store+0x8c/0x110
[ 4472.480968]  kobj_attr_store+0x18/0x30
[ 4472.480979]  sysfs_kf_write+0x44/0x54
[ 4472.480993]  kernfs_fop_write_iter+0x118/0x1b0
[ 4472.481004]  vfs_write+0x208/0x2f0
[ 4472.481015]  ksys_write+0x68/0xf4
[ 4472.481022]  __arm64_sys_write+0x1c/0x2c
[ 4472.481031]  invoke_syscall.constprop.0+0x50/0xf0
[ 4472.481044]  do_el0_svc+0x58/0x160
[ 4472.481052]  el0_svc+0x38/0xf0
[ 4472.481064]  el0t_64_sync_handler+0xbc/0x140
[ 4472.481074]  el0t_64_sync+0x18c/0x190
[ 4472.481084] ---[ end trace 0000000000000000 ]---
[ 4472.481134] ------------[ cut here ]------------

There is another similar warning next, this time however it reads “clk_spi4 already unprepared”. Do you also see it?

2 Likes

@tworaz glad you reproduced successful s2ram!

Yes, it looks like the spi4 clock is being suspended multiple times – same on my end. Probably some race conditions (like not locking a mutex when suspending spi) or problematic base device tree definition.

As far as I can tell, it may cause this first suspend to fall back to s2idle, but this error is gone for subsequent suspend cycles.