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

[Lee Jones <lee.jones@linaro.org>]

> > > > 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/

> > 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"):

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