-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rk3328: suspend to ram causes immediate panic on ddr4 #11
Comments
Cc @jwerner-chromium |
Sorry, I'm really just on this maintainer list for rk3399 and don't know anything about the other SoCs. I should maybe remove myself now that most development happens elsewhere. |
Hi @pgwipeout just curious if this is still an issue at your end? As there was no clear answer from community is there any chance you could investigate and push a change for resolving? |
Unfortunately it is still very much an issue, and only one that can be resolved by either Rockchip or a third party with access to their internal restricted documentation. I suspect it's the same problem that rk3399 experienced with the ddr4 controller, but the memory layout is different between rk3328 and rk3399 so any possible fix cannot be ported directly over. Is Rockchip aware of this method of reporting bugs yet? |
Hi I asked maintainers https://trustedfirmware-a.readthedocs.io/en/latest/about/maintainers.html#rockchip-platform-port on July 9th 2024 and pinged again on Aug 26th but got no answer. I can ping again but I'm unlikely to do better than this! |
Please add [email protected], [email protected], [email protected], and [email protected]. The three rock-chip's emails are current contributors to TF-A and Jimmy Brisson authored the rk3399 fix. Also, please add me, [email protected]. |
Kever Yang [email protected] Wed, Nov 27, 2024 at 9:22 PM Thanks for your report. From the output log, we know that the TF-A works fine for init flow, but somehow reset/reboot happen, an no more info. The code should work at the first, so it may not need any "internal restricted documentation" for this issue. Since you have both kernel source and TF-A source, could you help to add some more debug info so that we can narrow down the issue so that our engineer can really help.
As a engineer, we know that if we want to debug the issue, we have to reproduce it first, since rockchip engineers are mostly working on vendor U-Boot/kernel/TF-A/System, and rk3328 is a platform long time ago, so it's not so easy to setup the same debug environment as you have, so it will be great help if you can help to narrow down the issue first. Thanks,
|
Peter Geis [email protected] Sun, Dec 1, 2024 at 5:37 PM Good Evening Kever, I attempted to dig into this when I originally submitted my bug report and built a debug version of TF-A. From the stack trace at the end of this message, x30 points to the following: Going back to the last version that had a meaningful change to rk3328 pmu.c (v1.4 prior to commit 6bf0e07) results in a failure to boot.
|
Peter Geis [email protected] Tue, Dec 3, 2024 at 6:21 PM I recommend adding console_set_scope(&console, CONSOLE_FLAG_BOOT | CONSOLE_FLAG_RUNTIME | CONSOLE_FLAG_CRASH); to plat/rockchip/common/bl31_plat_setup.c, so the debug console works correctly. Without this only the crash context is functional. It would seem the issue is occurring after the transition to the sram_suspend function. I haven't found a safe way to print debug I'm pretty certain rk3328 sleep has never worked on DDR4, this issue started years ago when opportunistic sleep was enabled for arm64 boards. (Around 2019, when I retired the board because I didn't have the time to debug it). In an attempt to rule out configuration or hardware, I switched to using the rkbin bl31 image. It also immediately reboots, but it throws an interrupt before doing so, suggesting it is reaching suspend and immediately waking up and the wakeup is what is failing. The interrupt (interrupt 97) makes little sense, as that points to sdmmc_dectn_in_flt according to the TRM. I found GRF_SIG_DETECT_CON, which is fully disabled, but there was a pending sdmmc_detectn_neg_irq in GRF_SIG_DETECT_STATUS. I cleared the interrupt and verified it remained cleared, but interrupt 97 still fired again when attempting to sleep. I'm not certain if I'm chasing the correct register for this interrupt. See the below for the rkbin sleep attempt. Very Respectfully,
|
When suspending to ram on the rk3328 running ddr4 ram (roc-cc-rk3328) the board immediate reboots with no error produced. This issue does not occur on the rk3328 running ddr3 (rock64).
The text was updated successfully, but these errors were encountered: