yatli
December 1, 2022, 6:37am
1
It’s finally here, following 6 months of experiments and failures .
A06 now suspends to ram, which means <100mA power draw.
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
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
Kernel side patches: arch-linux-arm-clockworkpi-a06/linux-clockworkpi-a06 at main · yatli/arch-linux-arm-clockworkpi-a06 · GitHub arch-linux-arm-clockworkpi-a06/uboot-clockworkpi-a06 at main · yatli/arch-linux-arm-clockworkpi-a06 · GitHub 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!
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
14 Likes
yatli
December 1, 2022, 6:38am
2
(reserved for future updates)
2022-12-2 01:42:51 100%
Very likely it will do >2days…
Current projection:
TIME
BATT
1/30/23 9:26 PM
100
1/31/23 2:51 AM
100
1/31/23 5:33 AM
100
1/31/23 8:00 AM
100
1/31/23 4:33 PM
93
1/31/23 8:53 PM
89
2/1/23 4:15 AM
83
2/1/23 8:18 AM
79
2/1/23 8:55 PM
69
2/2/23 12:23 AM
66
2/2/23 8:07 AM
59
2/2/23 11:16 AM
56
2/2/23 9:44 PM
47
2/2/23 11:07 PM
45
2/3/23 3:23 AM
41
2/3/23 6:58 PM
2
So, it lasted from 1/30/23 9:26 PM to 2/3/23 6:58 PM, shy of FOUR DAYS.
5 Likes
m4xm4n
December 1, 2022, 3:18pm
3
Amazing work! Can’t wait to try it out!
1 Like
pkr
December 2, 2022, 6:06pm
4
yay a cool chart
yatli
December 2, 2022, 6:09pm
5
Data still being updated
Edit: well yeah, about two days.
2 Likes
You are a steely-eyed missile man.
tworaz
December 7, 2022, 12:07pm
7
I salute you sir for your persistence in pursuing this
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
yatli
December 7, 2022, 1:01pm
8
@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.
pkr
August 26, 2023, 3:47am
9
Kinda late to the party, but…
accidentally desoldered r509 instead of r508 and had to put it back on… I’ve never soldered anything so small before
4 Likes
. From my side I can only confirm I can reproduce your success with s2ram on my end.
