On Thu, 19 May 2022, Lee Jones wrote:
On Thu, 19 May 2022, Peter Geis wrote:
On Thu, May 19, 2022 at 11:47 AM Lee Jones lee.jones@linaro.org wrote:
On Thu, 19 May 2022, Lee Jones wrote:
On Thu, 19 May 2022, Peter Geis wrote:
On Thu, May 19, 2022 at 10:56 AM Lee Jones lee.jones@linaro.org wrote:
> > > > It's not clear how this issue (present 3 years ago) was finally > > > > resolved. From the thread, it looks as if the fix might have made its > > > > way into ATF, but I'm 87.6% sure ATF is not running on this platform > > > > (yet). > > > > > > The rk3399 SoC has a hardware bug where the power domains are not > > > reset upon a soft reset. This leads to situations like this one where > > > power domains are shut down during shutdown but aren't restored on > > > reboot. > > > > I assume this isn't something we can patch in the kernel driver? > > As far as I know it's being worked on by others, I have some ideas for > this as well but I've been focused on rk356x lately.
Thanks for the update.
> > > Mainline TF-A was patched to force all power domains online > > > when a soft reboot is triggered, which solved that issue. > > > > Okay, this is what I figured. > > > > > What particular issues are you having initializing modern u-boot on > > > this device? > > > > This is the output: https://pastebin.ubuntu.com/p/d5DmsSBnrR/ > > > > Speaking with one of the guys who supports RockPi 4 in AOSP, he > > suspects the DDR settings. Apparently settings for older SoCs > > sometimes get clobbered when support for newer SoCs is added. > > The rk3399 TPL code is specific to the rk3399 and it really hasn't > been touched much recently. I'm using the latest Mainline U-Boot on > both my Rockpro64 and Pinephone-Pro. I don't see TF-A being loaded, > which should happen between: > > Trying to boot from BOOTROM > Returning to boot ROM... > > Otherwise it just looks like the TPL code doesn't like being in a > single channel configuration. Does the 2GB model just forgo the second > ram chip? Or is this actually a 4GB model and it isn't detecting the > second chip in both downstream and mainline? Could you include the > TPL/SPL portion of downstream's output?
TPL/SPL are mostly silent on the downstream build:
https://pastebin.ubuntu.com/p/m2bBdjF8Wq/
Not sure if it helps at all, but ArmBian is pretty noisy:
Weird that downstream and mainline are being built with none of the debug stuff enabled. Armbian clearly shows the initial setup occuring correctly, and that it's a 4GB board. It's using both the Rockchip miniloader with a Rockchip TF-A blob as well.
> > I am yet to investigate the u-boot story in any detail. > > > > It's on my TODO list for today. > > > > > Is there a particular reason it isn't using Mainline TF-A? > > > > We're not using Trusted Firmware yet. > > This platform does not work at all without TF-A. Optee is optional. > Either you are using the downstream blob from Rockchip or Mainline > built yourself. Personally I prefer using Mainline everything. If you > build Mainline U-Boot without TF-A it will throw a warning at the end > that says the created binary is non-functional.
Right. Played a lot with this today.
Our build was using TF-A which was built-in to the primary loader.
I had 2 interesting results today. No idea how to explain them.
First one was with Mainline u-boot and Mainline TF-A, which found, but was seemingly unable to boot the kernel:
https://pastebin.ubuntu.com/p/9HRhPyfjYK/
The second interesting result I had was using our downstream u-boot with Mainline TF-A. It booted perfectly from cold, but managed to get stuck in the TPL on soft reboot in a very similar way to the one I reported earlier when not booting with TF-A ("Channel 1: col error"):
Mainline TF-A defaults to 115200 for its uart messages, so you need to either A. pass the uart config from U-Boot to TF-A with a platform config option (unreliable in my experience), B. change U-Boot to 115200, or C. change TF-A to 1.5M (the path I take). Your mainline
Hopefully this is enough:
diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h index ba83242eb..24ad94ae7 100644 --- a/plat/rockchip/rk3399/rk3399_def.h +++ b/plat/rockchip/rk3399/rk3399_def.h @@ -17,7 +17,8 @@ /**************************************************************************
- UART related constants
**************************************************************************/ -#define RK3399_BAUDRATE 115200 +//#define RK3399_BAUDRATE 115200 +#define RK3399_BAUDRATE 1500000 #define RK3399_UART_CLOCK 24000000
/******************************************************************************
Yes, that is sufficient.
That's interesting. Would this change result in me now being able to see the console output from this (apparently) failed attempt:
https://pastebin.ubuntu.com/p/9HRhPyfjYK/
However the result is the same as the downstream kernel where it fails in the TPL on soft reboot:
https://pastebin.ubuntu.com/p/TZBYqTMCnN/
No TF-A messages seen though still.
Is it possible that u-boot only runs TF-A on cold boot? Seems odd.
What was the extra logging you mentioned before?