On Thu, 19 May 2022, Peter Geis wrote: > On Thu, May 19, 2022 at 11:47 AM Lee Jones <lee.jo...@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.jo...@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. > > > > > > > > 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 kind enough to point me to the u-boot/TF-A prints please? > > > > > > > Would you be willing to run make savedefconfig from your mainline > > > > setup and share the result? > > > > > > u-boot or TF-A? > > > > Looks as though savedefconfig aren't u-boot or TF-A commands, so I'm > > guessing you mean kernel: > > > > https://termbin.com/rtr2 > > make savedefconfig causes the make system to output a defconfig file > in your current tree directory. It's a part of the kernel make system, > which also works in U-Boot mainline since it utilizes the same system. > It's how the configs in configs/ are generated.
Yes, I know what savedefconfig does. :) > I can use that simplified config to examine your current setup. I'm afraid it's not as easy as that. The build system I'm using is wrapped up in Android build-system-ness. I'll have a look to see if I can roll a defconfig by hand some how. > Or if you want to just host a git repository of your current U-Boot > mainline tree with an intact .config, that works as well. Okay, so it's the u-boot defconfig you're after. And Mainline, right, not our Android one? -- Lee Jones [李琼斯] Principal Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
