[U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Peter Geis]

On Thu, May 19, 2022 at 10:56 AM Lee Jones <lee.jones at 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:
>
> https://pastebin.ubuntu.com/p/fdPjmmqBDM/

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
hang is exactly where you expect to hang with a non-functional TF-A. I
enable some additional prints in my U-Boot tree to know exactly what
gets loaded during SPL. There are also debug prints you can enable in
TPL to get the setup results.

Would you be willing to run make savedefconfig from your mainline
setup and share the result?

>
> https://pastebin.ubuntu.com/p/hwmBzxDBgc/
>
> Thanks again for your insight.
>
> Kind regards,
> Lee
>
> --
> Lee Jones [李琼斯]
> Principal Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog