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

[Peter Geis <pgwipeout@gmail.com>]

On Thu, May 19, 2022 at 1:36 PM Peter Geis <pgwipeout@gmail.com> wrote:
>
> On Thu, May 19, 2022 at 1:23 PM 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 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:
> > > > > > > >
> > > > > > > > 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
> > > > > >
> > > > > > 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.
>
> I'm convinced that TF-A is not functional on your mainline config. No,
> TF-A will execute on any reset that triggers SPL, as SPL loads TF-A
> and jumps to it as part of the FIT load.
>
> >
> > What was the extra logging you mentioned before?
>
> This is what my rockpro64 looks like with TF-A executing. Note I've
> enabled a bit of extra TF-A debugging, normally it just prints out the
> TF-A version number. TF-A reports itself as BL31.
>
> U-Boot TPL 2022.04-rc2-00234-g017a8901ae3a-dirty (Mar 02 2022 - 18:36:55)
> Channel 0: LPDDR4, 50MHz
> BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> Channel 1: LPDDR4, 50MHz
> BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> 256B stride
> lpddr4_set_rate: change freq to 400000000 mhz 0, 1
> lpddr4_set_rate: change freq to 800000000 mhz 1, 0
> Trying to boot from BOOTROM
> Returning to boot ROM...
> rockchip_sdram_size ff320308 32c1f2c1
> rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0
> rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0
> SDRAM base=0, size=100000000
>
> U-Boot SPL 2022.04-rc2-00234-g017a8901ae3a-dirty (Mar 02 2022 - 18:36:55 -0500)
> Trying to boot from MMC2
> NOTICE:  BL31: v2.6(release):v2.6-138-g929f064f69d0-dirty
> NOTICE:  BL31: Built : 11:27:48, Feb  2 2022
> INFO:    GICv3 with legacy support detected.
> INFO:    ARM GICv3 driver initialized in EL3
> INFO:    Maximum SPI INTID supported: 287
> INFO:    plat_rockchip_pmu_init(1710): pd status 3e
> INFO:    BL31: Initializing runtime services
> INFO:    BL31: Preparing for EL3 exit to normal world
> INFO:    Entry point address = 0x200000
> INFO:    SPSR = 0x3c9
>
>
> U-Boot 2022.04-rc2-00234-g017a8901ae3a-dirty (Mar 02 2022 - 18:36:55 -0500)
>
> SoC: Rockchip rk3399
> Reset cause: POR
> Model: Pine64 RockPro64 v2.1
> DRAM:  rockchip_sdram_size ff320308 32c1f2c1
> rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0
> rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0
> SDRAM base=0, size=100000000
> 3.9 GiB
> PMIC:  RK808
> Core:  292 devices, 29 uclasses, devicetree: separate
> MMC:   mmc@fe310000: 3, mmc@fe320000: 1, mmc@fe330000: 0
> Loading Environment from SPIFlash... SF: Detected gd25q128 with page
> size 256 Bytes, erase size 4 KiB, total 16 MiB
> *** Warning - bad CRC, using default environment
>
> I'm currently pulling the rk3399-rock-pi-4b.dts that's in mainline
> linux to build a quick image for you, if you're interested.

I see that mainline U-Boot has support already for this device. So I'm
building a debug image for you with that.

>
> >
> > --
> > Lee Jones [李琼斯]
> > Principal Technical Lead - Developer Services
> > Linaro.org │ Open source software for Arm SoCs
> > Follow Linaro: Facebook | Twitter | Blog

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip