Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround
On Thu, May 19, 2022 at 1:36 PM Peter Geis wrote: > > On Thu, May 19, 2022 at 1:23 PM Lee Jones 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 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 > > > > > > > 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... > > > > > > > > > >
Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround
On Thu, May 19, 2022 at 1:23 PM Lee Jones 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 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 > > > > > > 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 >
Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround
On Thu, May 19, 2022 at 11:47 AM Lee Jones 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 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 a
Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround
On Thu, May 19, 2022 at 10:56 AM Lee Jones 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
Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround
On Thu, May 19, 2022 at 4:17 AM Lee Jones wrote: > > On Wed, 18 May 2022, Peter Geis wrote: > > On Wed, May 18, 2022 at 7:56 AM Lee Jones wrote: > > > > > > Looping int a few relevant/active kernel people/lists for full coverage. > > > > > > On Sun, 01 Dec 2019, Hugh Cole-Baker wrote: > > > > > On 29 Nov 2019, at 01:06, Vasily Khoruzhick > > > > > wrote: > > > > > On Thu, Nov 28, 2019 at 4:59 PM Kever Yang > > > > > wrote: > > > > >> > > > > >> Hi Vasily, > > > > >> > > > > >> On 2019/11/28 下午11:51, Vasily Khoruzhick wrote: > > > > >>> On Thu, Nov 28, 2019 at 1:23 AM Kever Yang > > > > >>> wrote: > > > > >>>> Hi Vasily, > > > > >>>> > > > > >>>> I think this should not be needed, see comments below. > > > > >>> Hi Kever, > > > > >>> > > > > >>> I've spent 2 weeks of my evenings debugging this issue but > > > > >> > > > > >> I can understand you work pretty hard on make it work, it's not so > > > > >> easy > > > > >> to identify the root cause > > > > >> > > > > >> some times, thanks very much for working on this. > > > > >> > > > > >>> unfortunately I don't have a proper fix. This is the only solution > > > > >>> that makes my rockpro64 reboot reliably with mainline u-boot and > > > > >>> ATF. > > > > >>> See my comments below. > > > > > > > > I also had a problem where Linux would hang or panic after rebooting, > > > > with > > > > mainline u-boot and ATF on a rockpro64. This patch does fix the issue > > > > for me, > > > > I have tested it by performing 10 reboots from Linux in a row and I've > > > > seen > > > > no hangs or panics. > > > > > > > > I noticed the Armbian project have recently included a patch to ATF [1] > > > > which > > > > switches all power domains on before ATF performs a soft reset. I have > > > > also > > > > tested using u-boot mainline, without any patches to u-boot, but > > > > including ATF > > > > patched with your reset fix [2] and the Armbian power domains patch > > > > [1]. This > > > > also fixes the same hanging on reboot issue for me without > > > > modifications to > > > > u-boot, I've also tested 10 reboots in a row with this ATF and seen no > > > > hangs. > > > > > > > > So this u-boot patch may not be needed if ATF is patched instead to > > > > switch > > > > power domains on before soft reset. > > > > > > > > FWIW, when I was able to see panic messages from Linux when it panicked > > > > on > > > > boot, the call trace always seemed to include rockchip_pd_power_off() > > > > [3]. > > > > > > > > [1] > > > > https://github.com/armbian/build/blob/master/patch/atf/atf-rk3399/switch-power-domains-on-before-reset.patch > > > > [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2512 > > > > [3] https://gist.github.com/sigmaris/c0e155c8cb0a325d84f549185f9a568c > > > > > > This last paste looks remarkably similar to an issue currently seen on > > > the Radxa ROCK Pi 4B (RK3399) during power-up after a soft reboot > > > (`sudo reboot`) is issued. We're presently running v5.15.35 [0]. > > > > Good Evening, > > Hi, Peter, > > Thank you so much for your reply. > > > That's definitely not stock v5.15.35, it's been tagged as an android kernel. > > 5.15.35-android13-5-00092-g525d77310a20 > > It's not stock, no. > > Although the differences from RockPi's perspective are minimal. > > The main difference is the way the kernel is configured. > > It's GKI: > > > https://android.googlesource.com/kernel/common/+/refs/heads/android13-5.15/arch/arm64/configs/gki_defconfig > > Plus a few non-GKI specifics: > > > https://android.googlesource.com/kernel/common/+/refs/heads/android13-5.15/arch/arm64/configs/rockpi4_gki.fragment Ah, so close enough to not matter much. > > > > It's not clear how this issue (present 3 years ago) was finally > > > resolved. From the thread
Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround
On Wed, May 18, 2022 at 7:56 AM Lee Jones wrote: > > Looping int a few relevant/active kernel people/lists for full coverage. > > On Sun, 01 Dec 2019, Hugh Cole-Baker wrote: > > > On 29 Nov 2019, at 01:06, Vasily Khoruzhick wrote: > > > On Thu, Nov 28, 2019 at 4:59 PM Kever Yang > > > wrote: > > >> > > >> Hi Vasily, > > >> > > >> On 2019/11/28 下午11:51, Vasily Khoruzhick wrote: > > >>> On Thu, Nov 28, 2019 at 1:23 AM Kever Yang > > >>> wrote: > > >>>> Hi Vasily, > > >>>> > > >>>> I think this should not be needed, see comments below. > > >>> Hi Kever, > > >>> > > >>> I've spent 2 weeks of my evenings debugging this issue but > > >> > > >> I can understand you work pretty hard on make it work, it's not so easy > > >> to identify the root cause > > >> > > >> some times, thanks very much for working on this. > > >> > > >>> unfortunately I don't have a proper fix. This is the only solution > > >>> that makes my rockpro64 reboot reliably with mainline u-boot and ATF. > > >>> See my comments below. > > > > I also had a problem where Linux would hang or panic after rebooting, with > > mainline u-boot and ATF on a rockpro64. This patch does fix the issue for > > me, > > I have tested it by performing 10 reboots from Linux in a row and I've seen > > no hangs or panics. > > > > I noticed the Armbian project have recently included a patch to ATF [1] > > which > > switches all power domains on before ATF performs a soft reset. I have also > > tested using u-boot mainline, without any patches to u-boot, but including > > ATF > > patched with your reset fix [2] and the Armbian power domains patch [1]. > > This > > also fixes the same hanging on reboot issue for me without modifications to > > u-boot, I've also tested 10 reboots in a row with this ATF and seen no > > hangs. > > > > So this u-boot patch may not be needed if ATF is patched instead to switch > > power domains on before soft reset. > > > > FWIW, when I was able to see panic messages from Linux when it panicked on > > boot, the call trace always seemed to include rockchip_pd_power_off() [3]. > > > > [1] > > https://github.com/armbian/build/blob/master/patch/atf/atf-rk3399/switch-power-domains-on-before-reset.patch > > [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2512 > > [3] https://gist.github.com/sigmaris/c0e155c8cb0a325d84f549185f9a568c > > This last paste looks remarkably similar to an issue currently seen on > the Radxa ROCK Pi 4B (RK3399) during power-up after a soft reboot > (`sudo reboot`) is issued. We're presently running v5.15.35 [0]. Good Evening, That's definitely not stock v5.15.35, it's been tagged as an android kernel. 5.15.35-android13-5-00092-g525d77310a20 > > 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. Mainline TF-A was patched to force all power domains online when a soft reboot is triggered, which solved that issue. What particular issues are you having initializing modern u-boot on this device? Is there a particular reason it isn't using Mainline TF-A? I've also run into issues on rk356x where the regulator powering a power domain isn't powered due to a soft reset, which also causes faults like this. Set your main regulators to always-on and see if it helps with the issue. Very Respectfully, Peter Geis > > Note that the u-boot we're using is also quite old: > > U-Boot 2019.10-09248-g8511c75bb4 (Jan 08 2020 - 17:13:03 -0800) > > ... so this could easily be the root cause. The current plan is to > try to update this ASAP. However early attempts are yet to result in > a successful boot. > > I see that Brian recently added a few patches related to PD/DVFS, but > again, these appear to be ATF related. > > Would anyone be able to shed some light onto this for me please? > > As always, any help would be gratefully received. > > Kind regards, > Lee > > [0] > Full reboot log can be seen at: https://pastebin.ubuntu.com/p/MjZP2V6kQ3/ > > [0.699736][T1]
Re: [PATCH v1 06/11] rockchip: handle bootrom recovery mode in spl
On Mon, Mar 14, 2022 at 7:59 AM Philipp Tomsich
wrote:
>
> On Tue, 22 Feb 2022 at 02:31, Peter Geis wrote:
> >
> > Fixup the bootrom recovery mode code to function in spl, so we can
> > handle recovery mode in case u-boot loading is broken.
> >
> > Signed-off-by: Peter Geis
> > ---
> > arch/arm/mach-rockchip/Makefile| 6 +++---
> > arch/arm/mach-rockchip/boot_mode.c | 4 +++-
> > arch/arm/mach-rockchip/rk3568/rk3568.c | 23 +++
> > 3 files changed, 29 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/mach-rockchip/Makefile
> > b/arch/arm/mach-rockchip/Makefile
> > index 00aef0ecee6a..53aff25ce8f6 100644
> > --- a/arch/arm/mach-rockchip/Makefile
> > +++ b/arch/arm/mach-rockchip/Makefile
> > @@ -15,13 +15,13 @@ obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> >
> > obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> >
> > -ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
> > -
> > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > # inside of boot_mode.c when CONFIG_BOOT_MODE_REG is 0. This way,
> > # we can have the preprocessor correctly recognise both 0x0 and 0
> > # meaning "turn it off".
> > -obj-y += boot_mode.o
> > +obj-$(CONFIG_ARCH_ROCKCHIP) += boot_mode.o
> > +
> > +ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
> > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > obj-$(CONFIG_MISC_INIT_R) += misc.o
> > endif
> > diff --git a/arch/arm/mach-rockchip/boot_mode.c
> > b/arch/arm/mach-rockchip/boot_mode.c
> > index 1a1a887fc2cd..43cb369465a2 100644
> > --- a/arch/arm/mach-rockchip/boot_mode.c
> > +++ b/arch/arm/mach-rockchip/boot_mode.c
> > @@ -51,7 +51,7 @@ __weak int rockchip_dnl_key_pressed(void)
> > ret = -ENODEV;
> > uclass_foreach_dev(dev, uc) {
> > if (!strncmp(dev->name, "saradc", 6)) {
> > - ret = adc_channel_single_shot(dev->name, 1, &val);
> > + ret = adc_channel_single_shot(dev->name, 0, &val);
>
> This looks like an unrelated change (i.e., doesn't correlate with the
> commit message). Should this go into a separate patch in the same
> series?
Makes sense, I can separate out this change.
>
> > break;
> > }
> > }
> > @@ -89,6 +89,7 @@ int setup_boot_mode(void)
> > boot_mode = readl(reg);
> > debug("%s: boot mode 0x%08x\n", __func__, boot_mode);
> >
> > +#if !defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
> > /* Clear boot mode */
> > writel(BOOT_NORMAL, reg);
> >
> > @@ -102,6 +103,7 @@ int setup_boot_mode(void)
> > env_set("preboot", "setenv preboot; ums mmc 0");
> > break;
> > }
> > +#endif
> >
> > return 0;
> > }
> > diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c
> > b/arch/arm/mach-rockchip/rk3568/rk3568.c
> > index 22eeb77d41fa..4e23feb9417f 100644
> > --- a/arch/arm/mach-rockchip/rk3568/rk3568.c
> > +++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
> > @@ -104,3 +104,26 @@ int arch_cpu_init(void)
> > #endif
> > return 0;
> > }
> > +
> > +#ifdef CONFIG_SPL_BUILD
> > +
> > +void __weak led_setup(void)
> > +{
> > +}
> > +
> > +void spl_board_init(void)
> > +{
> > + led_setup();
> > +
> > +#if defined(SPL_DM_REGULATOR)
> > + /*
> > +* Turning the eMMC and SPI back on (if disabled via the Qseven
> > +* BIOS_ENABLE) signal is done through a always-on regulator).
> > +*/
> > + if (regulators_enable_boot_on(false))
> > + debug("%s: Cannot enable boot on regulator\n", __func__);
> > +#endif
> > +
> > + setup_boot_mode();
> > +}
> > +#endif
> > --
> > 2.25.1
> >
Re: [PATCH v1 06/11] rockchip: handle bootrom recovery mode in spl
On Mon, Mar 14, 2022 at 5:10 AM Kever Yang wrote:
>
> Hi Peter,
Good Morning,
>
> On 2022/2/22 09:31, Peter Geis wrote:
> > Fixup the bootrom recovery mode code to function in spl, so we can
> > handle recovery mode in case u-boot loading is broken.
> I don't understand what do you mean about "Fixup the bootrom recovery
> mode code"?
> I would like to make SPL simple and small enough so that it can fit all
> kinds of SoCs.
This actually brings mainline's behavior into line with Rockchip's u-boot's.
Having SPL handle this also means if a broken u-boot is flashed, we
can recover it on devices that don't have removable storage.
Also, channel 1 is incorrect per Rockchip's documentation about the
maskrom key, following their reference designs channel 0 is always the
maskrom channel.
> I believe there are other modules to coming after saradc if we enable
> boot_mode in SPL,
> the SPL may become bloatware later.
I added a toggle that allows turning on or off SARADC in SPL.
> So please remove the boot mode relate patches so that other patches need
> by rk3568 can be
> merge first.
>
> Thanks,
> - Kever
Always,
Peter
> >
> > Signed-off-by: Peter Geis
> > ---
> > arch/arm/mach-rockchip/Makefile| 6 +++---
> > arch/arm/mach-rockchip/boot_mode.c | 4 +++-
> > arch/arm/mach-rockchip/rk3568/rk3568.c | 23 +++
> > 3 files changed, 29 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/mach-rockchip/Makefile
> > b/arch/arm/mach-rockchip/Makefile
> > index 00aef0ecee6a..53aff25ce8f6 100644
> > --- a/arch/arm/mach-rockchip/Makefile
> > +++ b/arch/arm/mach-rockchip/Makefile
> > @@ -15,13 +15,13 @@ obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> >
> > obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> >
> > -ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
> > -
> > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > # inside of boot_mode.c when CONFIG_BOOT_MODE_REG is 0. This way,
> > # we can have the preprocessor correctly recognise both 0x0 and 0
> > # meaning "turn it off".
> > -obj-y += boot_mode.o
> > +obj-$(CONFIG_ARCH_ROCKCHIP) += boot_mode.o
> > +
> > +ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
> > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > obj-$(CONFIG_MISC_INIT_R) += misc.o
> > endif
> > diff --git a/arch/arm/mach-rockchip/boot_mode.c
> > b/arch/arm/mach-rockchip/boot_mode.c
> > index 1a1a887fc2cd..43cb369465a2 100644
> > --- a/arch/arm/mach-rockchip/boot_mode.c
> > +++ b/arch/arm/mach-rockchip/boot_mode.c
> > @@ -51,7 +51,7 @@ __weak int rockchip_dnl_key_pressed(void)
> > ret = -ENODEV;
> > uclass_foreach_dev(dev, uc) {
> > if (!strncmp(dev->name, "saradc", 6)) {
> > - ret = adc_channel_single_shot(dev->name, 1, &val);
> > + ret = adc_channel_single_shot(dev->name, 0, &val);
> > break;
> > }
> > }
> > @@ -89,6 +89,7 @@ int setup_boot_mode(void)
> > boot_mode = readl(reg);
> > debug("%s: boot mode 0x%08x\n", __func__, boot_mode);
> >
> > +#if !defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
> > /* Clear boot mode */
> > writel(BOOT_NORMAL, reg);
> >
> > @@ -102,6 +103,7 @@ int setup_boot_mode(void)
> > env_set("preboot", "setenv preboot; ums mmc 0");
> > break;
> > }
> > +#endif
> >
> > return 0;
> > }
> > diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c
> > b/arch/arm/mach-rockchip/rk3568/rk3568.c
> > index 22eeb77d41fa..4e23feb9417f 100644
> > --- a/arch/arm/mach-rockchip/rk3568/rk3568.c
> > +++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
> > @@ -104,3 +104,26 @@ int arch_cpu_init(void)
> > #endif
> > return 0;
> > }
> > +
> > +#ifdef CONFIG_SPL_BUILD
> > +
> > +void __weak led_setup(void)
> > +{
> > +}
> > +
> > +void spl_board_init(void)
> > +{
> > + led_setup();
> > +
> > +#if defined(SPL_DM_REGULATOR)
> > + /*
> > + * Turning the eMMC and SPI back on (if disabled via the Qseven
> > + * BIOS_ENABLE) signal is done through a always-on regulator).
> > + */
> > + if (regulators_enable_boot_on(false))
> > + debug("%s: Cannot enable boot on regulator\n", __func__);
> > +#endif
> > +
> > + setup_boot_mode();
> > +}
> > +#endif
Re: [PATCH v1 00/11] rockchip fixes and extend rk3568 support
On Mon, Mar 14, 2022 at 4:56 AM Kever Yang wrote: > > Hi Peter, > > Thanks for your patchset. > > Seems like some of the driver module author does not include in the > patch cc list, I would suggest you to use scripts/get_maintainer.pl > instead of add cc manually I do use scripts/get_maintainer.pl automatically, which fails hilariously at the cover letter. I then bring anyone who's listed as a maintainer into the cover letter as well as the mailing lists manually by running it on the entire patch series. If someone is missing, then the maintainers file isn't grabbing them. I saw a patch recently to help with that. > > tools/patman/patman is a very wonderful tool, you can have a try :) I'll look into this! > > > Thanks, > > - Kever Always, Peter > > On 2022/2/22 09:31, Peter Geis wrote: > > to: Simon Glass > > to: Philipp Tomsich > > to: Kever Yang > > to: Lukasz Majewski > > to: Sean Anderson > > to: Peng Fan > > to: Jaehoon Chung > > to: Heiko Stübner > > cc: u-boot@lists.denx.de > > > > Good Evening, > > > > The following is a few patches for rockchip mainline u-boot support. > > Patches 1-3 are fixes for the rk3568 reset handler, rockchip emmc dma to > > sram, and building the rockchip-sfc driver. > > Patch 4 adds a sanity check for the minimum sfc frequency. > > Patch 5 and 6 add adc support to spl and enable the rockchip recovery > > handler in spl, before attempting to load u-boot. > > Patch 7 enables rk3568 spl bootrom device detection. > > Patch 8 enables automatic clock gating and other power saving features > > on rk3568, which solves the chip running hotter compared to downstream. > > Patch 9 and 10 move the dwc3 platform data to the chip specific code and > > enable dwc3 otg support on rk3568. > > Patch 11 is an RFC patch for fixing ram detection on rk3568. Downstream > > goes about this a different way, where they implemented a special > > library to handle this. > > > > Please review and *especially test* patch 11. > > > > Very Respectfully, > > Peter Geis > > > > Peter Geis (11): > >clk: rockchip: rk3568: fix reset handler > >mmc: sdhci: allow disabling sdma in spl > >spi: rockchip-sfc: fix building rockchip-sfc > >spi: rockchip-sfc: sanity check minimum freq > >spl: support adc drivers in spl > >rockchip: handle bootrom recovery mode in spl > >rockchip: rk3568: add boot device detection > >rockchip: rk3568: enable automatic clock gating > >rockchip: move dwc3 config to chip specific handler > >rockchip: rk3568: add dwc3 otg support > >[RFC] rockchip: rk356x: attempt to fix ram detection > > > > arch/arm/mach-rockchip/Kconfig | 1 + > > arch/arm/mach-rockchip/Makefile| 6 +- > > arch/arm/mach-rockchip/board.c | 24 -- > > arch/arm/mach-rockchip/boot_mode.c | 4 +- > > arch/arm/mach-rockchip/rk3399/rk3399.c | 29 +++ > > arch/arm/mach-rockchip/rk3568/rk3568.c | 112 + > > arch/arm/mach-rockchip/sdram.c | 19 +++-- > > common/board_f.c | 7 ++ > > common/spl/Kconfig | 5 ++ > > drivers/Makefile | 1 + > > drivers/clk/rockchip/clk_rk3568.c | 2 + > > drivers/mmc/Kconfig| 7 ++ > > drivers/mmc/sdhci.c| 6 +- > > drivers/spi/rockchip_sfc.c | 6 ++ > > include/configs/rk3568_common.h| 5 ++ > > 15 files changed, 197 insertions(+), 37 deletions(-) > >
Re: [PATCH v1 03/11] spi: rockchip-sfc: fix building rockchip-sfc
On Mon, Mar 14, 2022 at 4:47 AM Kever Yang wrote: > > Hi Peter, Good Morning, > > On 2022/2/22 09:31, Peter Geis wrote: > > The rockchip-sfc driver is missing an include to build correctly. > > > I think this driver builds OK and has been tested by other developer, > could you share what kind of build environment do you using and what > issue did you meet? If you enable debugging, the dev_dbg functions are not included due to header cleanups. dm/device_compat.h provides them. > > > Thanks, > > - Kever Always, Peter > > > > > Signed-off-by: Peter Geis > > --- > > drivers/spi/rockchip_sfc.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/spi/rockchip_sfc.c b/drivers/spi/rockchip_sfc.c > > index e098acac..851a6482985b 100644 > > --- a/drivers/spi/rockchip_sfc.c > > +++ b/drivers/spi/rockchip_sfc.c > > @@ -12,6 +12,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include
Re: [PATCH v1 11/11] [RFC] rockchip: rk356x: attempt to fix ram detection
On Fri, Mar 11, 2022 at 9:25 PM Simon Glass wrote:
>
> Hi Peter,
>
> On Mon, 21 Feb 2022 at 18:31, Peter Geis wrote:
> >
> > This patch attempts to fix ram detection on rk3568.
> > Prior to this, the rk3568 incorrectly detected 8gb ram as 2gb.
> > On top of this, the board panics when u-boot accesses ram above 4gb.
> >
> > Fix this by correcting ram detection in hopefully a backwards compatable
> > way, and extend board_f.c to enforce an upper limit on the ram u-boot
> > uses.
> > This allows us to limit the ram u-boot accesses, while passing the
> > correctly detected size to follow on software (eg linux).
> >
> > This has been tested on rk3566 2gb, 4gb, and 8gb configurations, as well
> > as rk3399 4gb configurations.
> >
> > I do not have other configurations available, and I do not have the
> > insights into rockchip ram handling to tell if this is the correct way
> > to go about this.
> >
> > Signed-off-by: Peter Geis
> > ---
> > arch/arm/mach-rockchip/Kconfig | 1 +
> > arch/arm/mach-rockchip/rk3568/rk3568.c | 29 ++
> > arch/arm/mach-rockchip/sdram.c | 19 +++--
> > common/board_f.c | 7 +++
> > include/configs/rk3568_common.h| 5 +
> > 5 files changed, 55 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
> > index 92f35309e4a6..58393cc623f8 100644
> > --- a/arch/arm/mach-rockchip/Kconfig
> > +++ b/arch/arm/mach-rockchip/Kconfig
> > @@ -264,6 +264,7 @@ config ROCKCHIP_RK3568
> > select SYSCON
> > select BOARD_LATE_INIT
> > imply ROCKCHIP_COMMON_BOARD
> > + imply OF_SYSTEM_SETUP
> > help
> > The Rockchip RK3568 is a ARM-based SoC with quad-core Cortex-A55,
> > including NEON and GPU, 512K L3 cache, Mali-G52 based graphics,
> > diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c
> > b/arch/arm/mach-rockchip/rk3568/rk3568.c
> > index ef6bc67a88b0..8d2a59bc649d 100644
> > --- a/arch/arm/mach-rockchip/rk3568/rk3568.c
> > +++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
> > @@ -5,6 +5,7 @@
> >
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -187,3 +188,31 @@ int board_usb_init(int index, enum usb_init_type init)
> > #endif /* CONFIG_USB_DWC3_GADGET */
> >
> > #endif /* CONFIG_USB_GADGET */
> > +
> > +#ifdef CONFIG_OF_SYSTEM_SETUP
> > +int ft_system_setup(void *blob, struct bd_info *bd)
> > +{
> > + int ret;
> > + int areas = 1;
> > + u64 start[2], size[2];
> > +
> > + /* Reserve the io address space. */
> > + if (gd->ram_top > SDRAM_UPPER_ADDR_MIN) {
>
> Can you put SDRAM_UPPER_ADDR_MIN and SDRAM_LOWER_ADDR_MAX into the
> device tree, perhaps?
This is the part of the patch series that gets really cludgy and I'm
not proud of it.
Essentially this is a cleaner implementation of what downstream does.
The issue is u-boot panics if it tries to access ram above 4G on this chip.
Combined with the MMIO address space below 4G, the available memory
map gets to be quite a mess.
I did try to keep it backwards compatible with the previous chips however.
The rk356x has 2G, 4G, and 8G boards in the wild.
I'll play a bit with a device tree method, to see if I can make it
make sense though.
>
>
> > + start[0] = gd->bd->bi_dram[0].start;
> > + size[0] = SDRAM_LOWER_ADDR_MAX - gd->bd->bi_dram[0].start;
> > +
> > + /* Add the upper 4GB address space */
> > + start[1] = SDRAM_UPPER_ADDR_MIN;
> > + size[1] = gd->ram_top - SDRAM_UPPER_ADDR_MIN;
> > + areas = 2;
> > +
> > + ret = fdt_set_usable_memory(blob, start, size, areas);
> > + if (ret) {
> > + printf("Cannot set usable memory\n");
> > + return ret;
> > + }
> > + }
> > +
> > + return 0;
> > +};
> > +#endif
> > diff --git a/arch/arm/mach-rockchip/sdram.c b/arch/arm/mach-rockchip/sdram.c
> > index 705ec7ba6450..52974e6dc333 100644
> > --- a/arch/arm/mach-rockchip/sdram.c
> > +++ b/arch/arm/mach-rockchip/sdram.c
> > @@ -3,6 +3,8 @@
> > * Copyright (C) 2017 Rockchip Electronics Co., Ltd.
> > */
> >
> > +#define DEBUG
> > +
> > #include
> > #include
> >
Re: [PATCH v1 10/11] rockchip: rk3568: add dwc3 otg support
On Fri, Mar 11, 2022 at 9:25 PM Simon Glass wrote: > > On Mon, 21 Feb 2022 at 18:31, Peter Geis wrote: > > > > Add the required platform data to the rk3568 chip config, in order to > > support dwc3 otg on this chip. > > > > Signed-off-by: Peter Geis > > --- > > arch/arm/mach-rockchip/rk3568/rk3568.c | 29 ++ > > 1 file changed, 29 insertions(+) > > > > Reviewed-by: Simon Glass > > Seems that this info should be in the device tree. I agree, but unless I'm missing something it seems the dwc3 otg code can only take platform data right now.
Re: [PATCH v1 06/11] rockchip: handle bootrom recovery mode in spl
On Fri, Mar 11, 2022 at 9:25 PM Simon Glass wrote:
>
> Hi Peter,
>
> On Mon, 21 Feb 2022 at 18:31, Peter Geis wrote:
> >
> > Fixup the bootrom recovery mode code to function in spl, so we can
> > handle recovery mode in case u-boot loading is broken.
> >
> > Signed-off-by: Peter Geis
> > ---
> > arch/arm/mach-rockchip/Makefile| 6 +++---
> > arch/arm/mach-rockchip/boot_mode.c | 4 +++-
> > arch/arm/mach-rockchip/rk3568/rk3568.c | 23 +++
> > 3 files changed, 29 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/mach-rockchip/Makefile
> > b/arch/arm/mach-rockchip/Makefile
> > index 00aef0ecee6a..53aff25ce8f6 100644
> > --- a/arch/arm/mach-rockchip/Makefile
> > +++ b/arch/arm/mach-rockchip/Makefile
> > @@ -15,13 +15,13 @@ obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
> >
> > obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
> >
> > -ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
> > -
> > # Always include boot_mode.o, as we bypass it (i.e. turn it off)
> > # inside of boot_mode.c when CONFIG_BOOT_MODE_REG is 0. This way,
> > # we can have the preprocessor correctly recognise both 0x0 and 0
> > # meaning "turn it off".
> > -obj-y += boot_mode.o
> > +obj-$(CONFIG_ARCH_ROCKCHIP) += boot_mode.o
> > +
> > +ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
> > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > obj-$(CONFIG_MISC_INIT_R) += misc.o
> > endif
> > diff --git a/arch/arm/mach-rockchip/boot_mode.c
> > b/arch/arm/mach-rockchip/boot_mode.c
> > index 1a1a887fc2cd..43cb369465a2 100644
> > --- a/arch/arm/mach-rockchip/boot_mode.c
> > +++ b/arch/arm/mach-rockchip/boot_mode.c
> > @@ -51,7 +51,7 @@ __weak int rockchip_dnl_key_pressed(void)
> > ret = -ENODEV;
> > uclass_foreach_dev(dev, uc) {
> > if (!strncmp(dev->name, "saradc", 6)) {
> > - ret = adc_channel_single_shot(dev->name, 1, &val);
> > + ret = adc_channel_single_shot(dev->name, 0, &val);
> > break;
> > }
> > }
> > @@ -89,6 +89,7 @@ int setup_boot_mode(void)
> > boot_mode = readl(reg);
> > debug("%s: boot mode 0x%08x\n", __func__, boot_mode);
> >
> > +#if !defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
>
> Can you use if() ?
>
> > /* Clear boot mode */
> > writel(BOOT_NORMAL, reg);
> >
> > @@ -102,6 +103,7 @@ int setup_boot_mode(void)
> > env_set("preboot", "setenv preboot; ums mmc 0");
> > break;
> > }
> > +#endif
> >
> > return 0;
> > }
> > diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c
> > b/arch/arm/mach-rockchip/rk3568/rk3568.c
> > index 22eeb77d41fa..4e23feb9417f 100644
> > --- a/arch/arm/mach-rockchip/rk3568/rk3568.c
> > +++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
> > @@ -104,3 +104,26 @@ int arch_cpu_init(void)
> > #endif
> > return 0;
> > }
> > +
> > +#ifdef CONFIG_SPL_BUILD
>
> Do you need that?
I intended this to fire only once during SPL, but I suppose it
wouldn't make much of a difference if it fired again.
>
> > +
> > +void __weak led_setup(void)
> > +{
> > +}
> > +
> > +void spl_board_init(void)
> > +{
> > + led_setup();
> > +
> > +#if defined(SPL_DM_REGULATOR)
>
> You need a CONFIG_ prefix there.
>
> But better:
>
> if (CONFIG_IS_ENABLED(DM_REGULATOR))
Thanks!
>
> > + /*
> > +* Turning the eMMC and SPI back on (if disabled via the Qseven
> > +* BIOS_ENABLE) signal is done through a always-on regulator).
> > +*/
> > + if (regulators_enable_boot_on(false))
> > + debug("%s: Cannot enable boot on regulator\n", __func__);
> > +#endif
> > +
> > + setup_boot_mode();
> > +}
> > +#endif
> > --
> > 2.25.1
> >
>
> Regards,
> Simon
Re: [PATCH v1 07/11] rockchip: rk3568: add boot device detection
On Fri, Mar 11, 2022 at 9:25 PM Simon Glass wrote:
>
> Hi Peter,
>
> On Mon, 21 Feb 2022 at 18:31, Peter Geis wrote:
> >
> > Enable rk3568 spl to detect which device it was booted from.
> >
> > Signed-off-by: Peter Geis
> > ---
> > arch/arm/mach-rockchip/rk3568/rk3568.c | 8
> > 1 file changed, 8 insertions(+)
> >
>
> Reviewed-by: Simon Glass
>
> I think a better way would be to put an option in the U-Boot config node,
> like:
>
> boot-devices = <&sdhci_0 &spi_flash &sd>;
This would certainly solve the problem of needing to constantly update
the boot devices each time a dts sync occurs.
I'm still learning my way around u-boot's method of handling
device-trees vs linux's method.
>
> > diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c
> > b/arch/arm/mach-rockchip/rk3568/rk3568.c
> > index 4e23feb9417f..5f239d89a7a9 100644
> > --- a/arch/arm/mach-rockchip/rk3568/rk3568.c
> > +++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
> > @@ -7,6 +7,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -23,6 +24,7 @@
> > #define SGRF_SOC_CON4 0x10
> > #define EMMC_HPROT_SECURE_CTRL 0x03
> > #define SDMMC0_HPROT_SECURE_CTRL 0x01
> > +
> > /* PMU_GRF_GPIO0D_IOMUX_L */
> > enum {
> > GPIO0D1_SHIFT = 4,
> > @@ -43,6 +45,12 @@ enum {
> > UART2_IO_SEL_M0 = 0,
> > };
> >
> > +const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
> > + [BROM_BOOTSOURCE_EMMC] = "/sdhci@fe31",
> > + [BROM_BOOTSOURCE_SPINOR] = "/spi@fe30/flash@0",
> > + [BROM_BOOTSOURCE_SD] = "/mmc@fe2b",
> > +};
> > +
> > static struct mm_region rk3568_mem_map[] = {
> > {
> > .virt = 0x0UL,
> > --
> > 2.25.1
> >
>
> Regards,
> Simon
Re: [PATCH v1 01/11] clk: rockchip: rk3568: fix reset handler
On Fri, Mar 11, 2022 at 9:25 PM Simon Glass wrote:
>
> Hi Peter,
>
> On Mon, 21 Feb 2022 at 18:31, Peter Geis wrote:
> >
> > The reset handler for rk3568 is missing its private data. This leads to
> > an abort when a reset is triggered.
> >
> > Add the missing dev_set_priv to the rk3568 clk driver.
> >
> > Fixes: 4a262feba3a5 ("rockchip: rk3568: add clock driver")
> >
> > Signed-off-by: Peter Geis
> > ---
> > drivers/clk/rockchip/clk_rk3568.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/clk/rockchip/clk_rk3568.c
> > b/drivers/clk/rockchip/clk_rk3568.c
> > index d5e45e7602c7..c83ae22dc302 100644
> > --- a/drivers/clk/rockchip/clk_rk3568.c
> > +++ b/drivers/clk/rockchip/clk_rk3568.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -2934,6 +2935,7 @@ static int rk3568_clk_bind(struct udevice *dev)
> > glb_srst_fst);
> > priv->glb_srst_snd_value = offsetof(struct rk3568_cru,
> > glb_srsr_snd);
> > + dev_set_priv(sys_child, priv);
> > }
> >
> > #if CONFIG_IS_ENABLED(RESET_ROCKCHIP)
> > --
> > 2.25.1
> >
>
> You must not access priv data in the bind() handler as it doesn't
> exist yet. The malloc() in that function is incorrect.
Strange, this makes this driver match literally every other rockchip
clock driver.
A few examples:
https://elixir.bootlin.com/u-boot/latest/source/drivers/clk/rockchip/clk_rk3399.c#L1431
https://elixir.bootlin.com/u-boot/latest/source/drivers/clk/rockchip/clk_rk3368.c#L625
https://elixir.bootlin.com/u-boot/latest/source/drivers/clk/rockchip/clk_rk3328.c#L827
It's funny though, I thought this should reside completely within the
clock driver, because the sysreset handler is touching private cru
registers and I planned on moving it here.
Then I found this in the other drivers and went with this method for
consistency.
>
> You certainly must not set the priv data in there. See the lifecycle
> docs in driver model for how things are supposed to work.
>
> You can use plat data, so could move glb_srst_fst_value and
> glb_srst_snd_value to struct rk3568_clk_plat, although oddly that
> struct only exists if OF_PLATDATA is used.
>
> Quite confusing.
>
> Regards,
> Simon
Re: [PATCH v2] binman: support mkimage separate files
On Thu, Mar 10, 2022 at 2:36 PM Alper Nebi Yasak
wrote:
>
> On 06/03/2022 17:44, Peter Geis wrote:
> > On Sat, Mar 5, 2022 at 10:08 PM Simon Glass wrote:
> >> On Fri, 4 Mar 2022 at 12:56, Peter Geis wrote:
> >>> mkimage has the ability to process two files at the same time.
> >>> This is necessary for rk356x support as both TPL and SPL need to be
> >>> hashed individually in the resulting header.
> >>> It also eases support for rkspi as mkimage handles everything for making
> >>> the requisite file for maskrom loading.
> >>
> >> This makes me wonder if we should move that functoinality out of
> >> mkimage and into binman?
>
> I think we should have entry types for the formats mkimage supports,
> even if they're just stubs that run 'mkimage -T '. Primarily
> because I don't see 'mkimage' as a meaningful 'type' of an entry, but I
> don't know if there's a common format to all the types it supports.
> Creating stub entries would also let us switch to native implementations
> one by one if we want that later.
>
> > Rockchip rk32 and rk33 maskrom loading from SPI has a bug that causes
> > it to only load 2048 bytes out of each 4096 byte chunk.
> > RKSPI splits the TPL/SPL (the portion directly loaded by maskrom) into
> > 2048 chunks then pads each chunk with blank space so the image can
> > load correctly.
> > While it could be moved to binman, as far as I'm aware this is a
> > corner case and I don't know any other chip that would need this
> > functionality.
>
> Do you know if rk35xx chips have the same bug? Does rkspi also do the
> weird chunking for those when it maybe doesn't need to?
>From my limited testing, no rk35xx seems to have fixed this bug.
Thus this series gives me hope for "unified" images for SPI and MMC
where the offsets are the same, and the only thing that changes is the
TPL/SPL actually loaded in place.
>
> >>> Add a new flag "separate_files" for mkimage handling to gather the files
> >>> separately rather than combining them before passing them to mkimage.
> >>>
> >>> Signed-off-by: Peter Geis
> >>> ---
> >>> Changelog:
> >>> v2:
> >>> I've managed to move this all into mkimage.py as per Alper's suggestion.
> >>> I've added an example to the readme portion of the function.
> >>> mkimage,separate_files is now separate-files.
> >>>
> >>> tools/binman/etype/mkimage.py | 41 ---
> >>> 1 file changed, 38 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/tools/binman/etype/mkimage.py b/tools/binman/etype/mkimage.py
> >>> index 5f6def2287f6..0a86f904a2b7 100644
> >>> --- a/tools/binman/etype/mkimage.py
> >>> +++ b/tools/binman/etype/mkimage.py
> >>> @@ -17,6 +17,7 @@ class Entry_mkimage(Entry):
> >>> Properties / Entry arguments:
> >>> - datafile: Filename for -d argument
> >>> - args: Other arguments to pass
> >>> +- separate-files: Boolean flag for passing files individually.
> >>>
> >>> The data passed to mkimage is collected from subnodes of the mkimage
> >>> node,
> >>> e.g.::
> >>> @@ -42,20 +43,54 @@ class Entry_mkimage(Entry):
> >>> };
> >>> };
> >>>
> >>> +This calls mkimage to create a rksd image with a standalone ram init
> >>> +binary file and u-boot-spl.bin as individual input files. The output
> >>> from
> >>> +mkimage then becomes part of the image produced by binman.
> >>> +
> >>> +mkimage {
> >>> +args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
> >>> +separate-files;
> >>> +
> >>> +ddrl {
> >>> +type = "blob-ext";
> >>> +filename = "rk3568_ddr_1560MHz_v1.12.bin";
> >>> +};
> >>> +
> >>> +u-boot-spl {
> >>> +};
> >>> +};
> >>> +
> >>> """
> >>> def __init__(self, section, etype, node):
> >>> super().__init__(section, etype, node)
> >>> self._args = fdt_util.GetArgs(self._node, 'args')
> >>> +self._separate = fdt_
Re: [PATCH v2] binman: support mkimage separate files
On Sat, Mar 5, 2022 at 10:08 PM Simon Glass wrote:
>
> Hi Peter,
Good Morning,
>
> On Fri, 4 Mar 2022 at 12:56, Peter Geis wrote:
> >
> > mkimage has the ability to process two files at the same time.
> > This is necessary for rk356x support as both TPL and SPL need to be
> > hashed individually in the resulting header.
> > It also eases support for rkspi as mkimage handles everything for making
> > the requisite file for maskrom loading.
>
> This makes me wonder if we should move that functoinality out of
> mkimage and into binman?
Rockchip rk32 and rk33 maskrom loading from SPI has a bug that causes
it to only load 2048 bytes out of each 4096 byte chunk.
RKSPI splits the TPL/SPL (the portion directly loaded by maskrom) into
2048 chunks then pads each chunk with blank space so the image can
load correctly.
While it could be moved to binman, as far as I'm aware this is a
corner case and I don't know any other chip that would need this
functionality.
>
> >
> > Add a new flag "separate_files" for mkimage handling to gather the files
> > separately rather than combining them before passing them to mkimage.
> >
> > Signed-off-by: Peter Geis
> > ---
> > Changelog:
> > v2:
> > I've managed to move this all into mkimage.py as per Alper's suggestion.
> > I've added an example to the readme portion of the function.
> > mkimage,separate_files is now separate-files.
> >
> > tools/binman/etype/mkimage.py | 41 ---
> > 1 file changed, 38 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/binman/etype/mkimage.py b/tools/binman/etype/mkimage.py
> > index 5f6def2287f6..0a86f904a2b7 100644
> > --- a/tools/binman/etype/mkimage.py
> > +++ b/tools/binman/etype/mkimage.py
> > @@ -17,6 +17,7 @@ class Entry_mkimage(Entry):
> > Properties / Entry arguments:
> > - datafile: Filename for -d argument
> > - args: Other arguments to pass
> > +- separate-files: Boolean flag for passing files individually.
> >
> > The data passed to mkimage is collected from subnodes of the mkimage
> > node,
> > e.g.::
> > @@ -42,20 +43,54 @@ class Entry_mkimage(Entry):
> > };
> > };
> >
> > +This calls mkimage to create a rksd image with a standalone ram init
> > +binary file and u-boot-spl.bin as individual input files. The output
> > from
> > +mkimage then becomes part of the image produced by binman.
> > +
> > +mkimage {
> > +args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
> > +separate-files;
> > +
> > +ddrl {
> > +type = "blob-ext";
> > +filename = "rk3568_ddr_1560MHz_v1.12.bin";
> > +};
> > +
> > +u-boot-spl {
> > +};
> > +};
> > +
> > """
> > def __init__(self, section, etype, node):
> > super().__init__(section, etype, node)
> > self._args = fdt_util.GetArgs(self._node, 'args')
> > +self._separate = fdt_util.GetBool(self._node, 'separate-files')
> > self._mkimage_entries = OrderedDict()
> > self.align_default = None
> > self.ReadEntries()
> > +self.index = 0
> > +self.fname_tmp = str()
> >
> > def ObtainContents(self):
> > # Use a non-zero size for any fake files to keep mkimage happy
> > -data, input_fname, uniq = self.collect_contents_to_file(
> > -self._mkimage_entries.values(), 'mkimage', 1024)
> > -if data is None:
> > +if self._separate is False:
> > + data, input_fname, uniq = self.collect_contents_to_file(
> > + self._mkimage_entries.values(), 'mkimage', 1024)
> > + if data is None:
> > return False
> > +else:
> > + for entry in self._mkimage_entries.values():
>
> We can do:
>
> for index, entry in enumerate(self._mkimage_entries.values()):
>
> then you don't need self.index
Thanks!
>
> > +self.index = (self.index + 1)
> > +if (self.index > 2):
> > + print('BINMAN Warn: mkimage only supports a maximum of two
> > separate files')
>
> Can we use self.Raise() here instead? It seems like a fatal error.
> Also this check should go in ReadNode() since we don't want to die
> t
[PATCH v2] binman: support mkimage separate files
mkimage has the ability to process two files at the same time.
This is necessary for rk356x support as both TPL and SPL need to be
hashed individually in the resulting header.
It also eases support for rkspi as mkimage handles everything for making
the requisite file for maskrom loading.
Add a new flag "separate_files" for mkimage handling to gather the files
separately rather than combining them before passing them to mkimage.
Signed-off-by: Peter Geis
---
Changelog:
v2:
I've managed to move this all into mkimage.py as per Alper's suggestion.
I've added an example to the readme portion of the function.
mkimage,separate_files is now separate-files.
tools/binman/etype/mkimage.py | 41 ---
1 file changed, 38 insertions(+), 3 deletions(-)
diff --git a/tools/binman/etype/mkimage.py b/tools/binman/etype/mkimage.py
index 5f6def2287f6..0a86f904a2b7 100644
--- a/tools/binman/etype/mkimage.py
+++ b/tools/binman/etype/mkimage.py
@@ -17,6 +17,7 @@ class Entry_mkimage(Entry):
Properties / Entry arguments:
- datafile: Filename for -d argument
- args: Other arguments to pass
+- separate-files: Boolean flag for passing files individually.
The data passed to mkimage is collected from subnodes of the mkimage node,
e.g.::
@@ -42,20 +43,54 @@ class Entry_mkimage(Entry):
};
};
+This calls mkimage to create a rksd image with a standalone ram init
+binary file and u-boot-spl.bin as individual input files. The output from
+mkimage then becomes part of the image produced by binman.
+
+mkimage {
+args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
+separate-files;
+
+ddrl {
+type = "blob-ext";
+filename = "rk3568_ddr_1560MHz_v1.12.bin";
+};
+
+u-boot-spl {
+};
+};
+
"""
def __init__(self, section, etype, node):
super().__init__(section, etype, node)
self._args = fdt_util.GetArgs(self._node, 'args')
+self._separate = fdt_util.GetBool(self._node, 'separate-files')
self._mkimage_entries = OrderedDict()
self.align_default = None
self.ReadEntries()
+self.index = 0
+self.fname_tmp = str()
def ObtainContents(self):
# Use a non-zero size for any fake files to keep mkimage happy
-data, input_fname, uniq = self.collect_contents_to_file(
-self._mkimage_entries.values(), 'mkimage', 1024)
-if data is None:
+if self._separate is False:
+ data, input_fname, uniq = self.collect_contents_to_file(
+ self._mkimage_entries.values(), 'mkimage', 1024)
+ if data is None:
return False
+else:
+ for entry in self._mkimage_entries.values():
+self.index = (self.index + 1)
+if (self.index > 2):
+ print('BINMAN Warn: mkimage only supports a maximum of two
separate files')
+ return False
+input_fname = ['mkimage', str(self.index)]
+data, input_fname, uniq = self.collect_contents_to_file(
+[entry], ".".join(input_fname), 1024)
+if data is None:
+ return False
+self.fname_tmp = [''.join(self.fname_tmp),input_fname]
+ input_fname = ":".join(self.fname_tmp)
output_fname = tools.get_output_filename('mkimage-out.%s' % uniq)
if self.mkimage.run_cmd('-d', input_fname, *self._args,
output_fname) is not None:
--
2.25.1
Re: [RFC] [PATCH] binman: support mkimage split files
On Thu, Mar 3, 2022 at 4:17 PM Alper Nebi Yasak
wrote:
>
> On 01/03/2022 05:48, Peter Geis wrote:
> > Good Evening,
> >
> > I successfully tested your v2 patch series to create a bootable sdcard
> > image out of the box for rockpro64-rk3399.
> > Unfortunately, rk356x and rk3399-spi modes are broken, due to the
> > inability to pass multiple images to mkimage at the same time.
> > rk3399-spi mode is already supported manually, see:
> > https://elixir.bootlin.com/u-boot/v2022.04-rc3/source/doc/board/rockchip/rockchip.rst#L182
> >
> > rk356x is currently only supported manually, the image built by the old
> > Makefile method is non functional. (u-boot-rockchip.bin)
> >
> > Knowing absolutely nothing about python, I've hacked together something
> > that works for splitting the image in the way mkimage expects.
> > The file name passed to mkimage with the -d flag is:
> > ./mkimage.simple-bin.mkimage.1:./mkimage.simple-bin.mkimage.2
> >
> > I definitely don't expect this to be accepted as is, I just use it as an
> > example of what we need to fully support this in binman.
> > Adding the following allows me to build images automatically for rk356x:
> >
> > mkimage {
> > args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
> > mkimage,separate_files;
>
> Adding a property to toggle this sounds reasonable to me. The prefix
> might not be necessary, and I think dashes are preferred to underscores
> in property names.
Thanks! I thought including mkimage as a prefix was necessary to make
it clear what was happening, but on second thought it's in the mkimage
node.
>
> >
> > ddrl {
> > type = "blob-ext";
> > filename = "rk3568_ddr_1560MHz_v1.12.bin";
> > };
> >
> > u-boot-spl {
> > };
> > };
> >
> > This is my first attempt to use in-reply-to, so I hope this works.
>
> FYI, I see it as a reply to 00/25 of the series.
I appreciate the confirmation.
>
> >
> > Thanks,
> > Peter Geis
> >
> > Signed-off-by: Peter Geis
> > ---
> > tools/binman/entry.py | 43 ++-
> > tools/binman/etype/mkimage.py | 3 ++-
> > 2 files changed, 34 insertions(+), 12 deletions(-)
> >
> > diff --git a/tools/binman/entry.py b/tools/binman/entry.py
> > index 249f117ace56..48e552fc6af3 100644
> > --- a/tools/binman/entry.py
> > +++ b/tools/binman/entry.py
> > @@ -114,6 +114,8 @@ class Entry(object):
> > self.bintools = {}
> > self.missing_bintools = []
> > self.update_hash = True
> > +self.fname_tmp = str()
> > +self.index = 0
> >
> > @staticmethod
> > def FindEntryClass(etype, expanded):
> > @@ -1134,7 +1136,7 @@ features to produce new behaviours.
> > """
> > self.update_hash = update_hash
> >
> > -def collect_contents_to_file(self, entries, prefix, fake_size=0):
> > +def collect_contents_to_file(self, entries, prefix, fake_size=0,
> > separate=False):
> > """Put the contents of a list of entries into a file
> >
> > Args:
> > @@ -1152,13 +1154,32 @@ features to produce new behaviours.
> > str: Unique portion of filename (or None if no data)
> > """
> > data = b''
> > -for entry in entries:
> > -# First get the input data and put it in a file. If not
> > available,
> > -# try later.
> > -if not entry.ObtainContents(fake_size=fake_size):
> > -return None, None, None
> > -data += entry.GetData()
> > -uniq = self.GetUniqueName()
> > -fname = tools.get_output_filename(f'{prefix}.{uniq}')
> > -tools.write_file(fname, data)
> > -return data, fname, uniq
> > +if separate is False:
> > +for entry in entries:
> > +# First get the input data and put it in a file. If not
> > available,
> > +# try later.
> > +if not entry.ObtainContents(fake_size=fake_size):
> > +return None, None, None
> > +data += entry.GetData()
> > +uniq = self.GetUniqueName()
> > +fname = tools.get_output_filename(f'{prefix}.{uniq}')
> > +tools.write_file(fname, data)
> > +re
Re: [PATCH v2 23/25] rockchip: Support building the all output files in binman
On Thu, Mar 3, 2022 at 4:17 PM Alper Nebi Yasak
wrote:
>
> On 03/03/2022 01:16, Peter Geis wrote:
> > On Wed, Feb 23, 2022 at 6:04 PM Simon Glass wrote:
> >> diff --git a/arch/arm/dts/rockchip-u-boot.dtsi
> >> b/arch/arm/dts/rockchip-u-boot.dtsi
> >> index eae3ee715d..64e4466489 100644
> >> --- a/arch/arm/dts/rockchip-u-boot.dtsi
> >> +++ b/arch/arm/dts/rockchip-u-boot.dtsi
> >> @@ -17,13 +17,93 @@
> >> filename = "u-boot-rockchip.bin";
> >> pad-byte = <0xff>;
> >>
> >> - blob {
> >> - filename = "idbloader.img";
> >> +#ifdef CONFIG_TPL
> >> + mkimage {
> >> + args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
> >> +
> >> + u-boot-tpl {
> >> + };
> >> + };
> >> +
> >> + u-boot-spl {
> >> };
> >> +#elif defined(CONFIG_SPL) /* SPL only */
> >> + mkimage {
> >> + args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
> >> +
> >> + u-boot-spl {
> >> + };
> >> + };
> >> +#endif
> >> +#if defined(CONFIG_SPL_FIT) && defined(CONFIG_ARM64)
> >> + fit: fit {
> >> + description = "FIT image for U-Boot with bl31
> >> (TF-A)";
> >> + #address-cells = <1>;
> >> + fit,fdt-list = "of-list";
> >> + fit,external-offset = ;
> >
> > You need:
> > offset = ;
> > here or the image is located at the wrong location.
>
> Thanks for confirming this.
>
> > The image produced is not functional however, because it swaps the
> > firmware node with the loadable-1 node.
> > Working image:
> > Configuration 0 (config_1)
> > Description: rk3399-pinephone-pro.dtb
> > Kernel: unavailable
> > Firmware: atf_1
> > FDT: fdt_1
> > Loadables:uboot
> > atf_2
> > atf_3
> >
> > Non working image produced from this:
> > Configuration 0 (config-1)
> > Description: rk3399-rockpro64.dtb
> > Kernel: unavailable
> > Firmware: u-boot
> > FDT: fdt-1
> > Loadables:atf-1
> > atf-2
> > atf-3
>
> And also this. I encountered the same things on rk3399-gru-kevin,
> mentioned them in my reply [1] to v1 but I guess Simon missed it.
>
> [1] My reply to v1 of this patch
> https://lore.kernel.org/u-boot/d50a7e13-7113-8c95-1861-cbc6c1000...@gmail.com/
Yes, that's the solution I ended up with as well.
Funnily enough, it seems loadables has a limit of five items, meaning
the newest rk356x ATF images which have four binaries, u-boot, and
optee trigger an error.
>
> > Also, it still doesn't support passing two separate files to mkimage
> > at the same time, required for proper support of rk33xx_SPI generation
> > and for rk35xx in general.
>
> I got v1 of this booting from SPI, but on a board that doesn't use TPL.
> I see in doc/boards/rockchip.rst that one would indeed pass TPL+SPL to
> mkimage as two different files. I don't know how they're processed or
> anything about the rksd/rkspi formats though.
RKSPI mode splits the image up into 2048 chunks, and pads each chunk
with 2048 of blank space.
For some reason the rk32/rk33 bootrom SPI code reads only 2048 out of
each 4096 chunk.
Delightfully this seems to have been fixed in rk35xx.
>
> > Please see my standalone patch for what I hacked together to get that
> > working:
> > http://patchwork.ozlabs.org/project/uboot/patch/20220301024826.1228290-1-pgwipe...@gmail.com/
> > Note: those images are not functional either due to this issue.
> >
> > A wishlist item would be for it to produce the original idbloader.img
> > and u-boot.itb files, at least for now.
> >
> > Thanks!
> > Very Respectfully,
> > Peter Geis
Re: [PATCH v2 23/25] rockchip: Support building the all output files in binman
fit,data;
> +
> + tee-os {
> + };
> + };
> +
> + @fdt-SEQ {
> + description = "fdt-NAME";
> + compression = "none";
> + type = "flat_dt";
> + };
> + };
> +
> + configurations {
> + default = "@config-DEFAULT-SEQ";
> + @config-SEQ {
> + description = "NAME.dtb";
> + fdt = "fdt-SEQ";
> + firmware = "u-boot";
> + fit,loadables;
> + };
> + };
> + };
> +#else
> u-boot-img {
> offset = ;
> };
> +#endif /* CONFIG_ARM64 */
> };
> };
> #endif
> --
> 2.35.1.574.g5d30c73bfb-goog
>
The image produced is not functional however, because it swaps the
firmware node with the loadable-1 node.
Working image:
Configuration 0 (config_1)
Description: rk3399-pinephone-pro.dtb
Kernel: unavailable
Firmware: atf_1
FDT: fdt_1
Loadables:uboot
atf_2
atf_3
Non working image produced from this:
Configuration 0 (config-1)
Description: rk3399-rockpro64.dtb
Kernel: unavailable
Firmware: u-boot
FDT: fdt-1
Loadables:atf-1
atf-2
atf-3
Also, it still doesn't support passing two separate files to mkimage
at the same time, required for proper support of rk33xx_SPI generation
and for rk35xx in general.
Please see my standalone patch for what I hacked together to get that working:
http://patchwork.ozlabs.org/project/uboot/patch/20220301024826.1228290-1-pgwipe...@gmail.com/
Note: those images are not functional either due to this issue.
A wishlist item would be for it to produce the original idbloader.img
and u-boot.itb files, at least for now.
Thanks!
Very Respectfully,
Peter Geis
[RFC] [PATCH] binman: support mkimage split files
Good Evening,
I successfully tested your v2 patch series to create a bootable sdcard
image out of the box for rockpro64-rk3399.
Unfortunately, rk356x and rk3399-spi modes are broken, due to the
inability to pass multiple images to mkimage at the same time.
rk3399-spi mode is already supported manually, see:
https://elixir.bootlin.com/u-boot/v2022.04-rc3/source/doc/board/rockchip/rockchip.rst#L182
rk356x is currently only supported manually, the image built by the old
Makefile method is non functional. (u-boot-rockchip.bin)
Knowing absolutely nothing about python, I've hacked together something
that works for splitting the image in the way mkimage expects.
The file name passed to mkimage with the -d flag is:
./mkimage.simple-bin.mkimage.1:./mkimage.simple-bin.mkimage.2
I definitely don't expect this to be accepted as is, I just use it as an
example of what we need to fully support this in binman.
Adding the following allows me to build images automatically for rk356x:
mkimage {
args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
mkimage,separate_files;
ddrl {
type = "blob-ext";
filename = "rk3568_ddr_1560MHz_v1.12.bin";
};
u-boot-spl {
};
};
This is my first attempt to use in-reply-to, so I hope this works.
Thanks,
Peter Geis
Signed-off-by: Peter Geis
---
tools/binman/entry.py | 43 ++-
tools/binman/etype/mkimage.py | 3 ++-
2 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/tools/binman/entry.py b/tools/binman/entry.py
index 249f117ace56..48e552fc6af3 100644
--- a/tools/binman/entry.py
+++ b/tools/binman/entry.py
@@ -114,6 +114,8 @@ class Entry(object):
self.bintools = {}
self.missing_bintools = []
self.update_hash = True
+self.fname_tmp = str()
+self.index = 0
@staticmethod
def FindEntryClass(etype, expanded):
@@ -1134,7 +1136,7 @@ features to produce new behaviours.
"""
self.update_hash = update_hash
-def collect_contents_to_file(self, entries, prefix, fake_size=0):
+def collect_contents_to_file(self, entries, prefix, fake_size=0,
separate=False):
"""Put the contents of a list of entries into a file
Args:
@@ -1152,13 +1154,32 @@ features to produce new behaviours.
str: Unique portion of filename (or None if no data)
"""
data = b''
-for entry in entries:
-# First get the input data and put it in a file. If not available,
-# try later.
-if not entry.ObtainContents(fake_size=fake_size):
-return None, None, None
-data += entry.GetData()
-uniq = self.GetUniqueName()
-fname = tools.get_output_filename(f'{prefix}.{uniq}')
-tools.write_file(fname, data)
-return data, fname, uniq
+if separate is False:
+for entry in entries:
+# First get the input data and put it in a file. If not
available,
+# try later.
+if not entry.ObtainContents(fake_size=fake_size):
+return None, None, None
+data += entry.GetData()
+uniq = self.GetUniqueName()
+fname = tools.get_output_filename(f'{prefix}.{uniq}')
+tools.write_file(fname, data)
+return data, fname, uniq
+else:
+for entry in entries:
+self.index = (self.index + 1)
+if (self.index > 2):
+print('BINMAN Warn: mkimage only supports a maximum of two
separate files')
+break
+# First get the input data and put it in a file. If not
available,
+# try later.
+if not entry.ObtainContents(fake_size=fake_size):
+return None, None, None
+data = entry.GetData()
+uniq = self.GetUniqueName()
+fname =
tools.get_output_filename(f'{prefix}.{uniq}.{self.index}')
+tools.write_file(fname, data)
+self.fname_tmp = [''.join(self.fname_tmp),fname]
+fname = ':'.join(self.fname_tmp)
+uniq = self.GetUniqueName()
+return data, fname, uniq
diff --git a/tools/binman/etype/mkimage.py b/tools/binman/etype/mkimage.py
index 5f6def2287f6..ce5f6b6b543a 100644
--- a/tools/binman/etype/mkimage.py
+++ b/tools/binman/etype/mkimage.py
@@ -46,6 +46,7 @@ class Entry_mkimage(Entry):
def __init__(self, section, etype, node):
super().__init__(section, etype, node)
self._args = fdt_util.GetArgs(self._node, 'args')
+self._mkimage_separate = fdt_util.GetBool(self._node,
'mkimage,separate_files')
Re: Tips on porting a board from older u-boot versions
On Wed, Feb 23, 2022 at 5:13 PM Jayson Reis wrote:
>
> Hey there folks,
Good Evening,
> I just have at hands a board from Radxa, called Rock 3-A which has a rockchip
> RK3568, and they do provide a version of u-boot but rather old.
> As a fun side project, I am trying to port all things to the current master.
> I am still at really early stages, got a minimum .config that compiles for
> that board and using their provided TPL, I can load my compiled version of
> u-boot's SPL.
> After doing this, some questions came which I could not find on the docs or
> some other good resource for really beginners in all this embedded world.
> First, the initial SPL problem is because the DRAM is not configured, and I
> saw that there is a driver for that chip that uses dts for its configuration:
>
> drivers/ram/rockchip/sdram_rk3568.c
> static const struct udevice_id rk3568_dmc_ids[] = {
> { .compatible = "rockchip,rk3568-dmc" },
> { }
> };
>
> But searching the code, I could not find any dts that configures it that way,
> from where should I get this information? In some chips I found this
> configuration in .c, and .h files, ideally, where should they go?
> Also, about the dts, what is the right way to write them in the sense of, how
> do you find out the peripherals and their configuration? Is it from a data
> sheet or something like that?
> If you can point to any other documentation for beginners on how to port
> boards, it will be much appreciated.
rk356x support in mainline isn't currently viable, though it is close.
You may want to check out my gitlab, which maintains my currently out
of tree patches:
https://gitlab.com/pgwipeout/u-boot-quartz64
I recently submitted the first batch, which includes some fixes for
rk356x including ram detection (which is really broken currently).
Also, for building examples, check out my CI:
https://gitlab.com/pgwipeout/quartz64_ci
> Thank you in advance,
> Jayson
Very Respectfully,
Peter Geis
[PATCH v1 11/11] [RFC] rockchip: rk356x: attempt to fix ram detection
This patch attempts to fix ram detection on rk3568.
Prior to this, the rk3568 incorrectly detected 8gb ram as 2gb.
On top of this, the board panics when u-boot accesses ram above 4gb.
Fix this by correcting ram detection in hopefully a backwards compatable
way, and extend board_f.c to enforce an upper limit on the ram u-boot
uses.
This allows us to limit the ram u-boot accesses, while passing the
correctly detected size to follow on software (eg linux).
This has been tested on rk3566 2gb, 4gb, and 8gb configurations, as well
as rk3399 4gb configurations.
I do not have other configurations available, and I do not have the
insights into rockchip ram handling to tell if this is the correct way
to go about this.
Signed-off-by: Peter Geis
---
arch/arm/mach-rockchip/Kconfig | 1 +
arch/arm/mach-rockchip/rk3568/rk3568.c | 29 ++
arch/arm/mach-rockchip/sdram.c | 19 +++--
common/board_f.c | 7 +++
include/configs/rk3568_common.h| 5 +
5 files changed, 55 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 92f35309e4a6..58393cc623f8 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -264,6 +264,7 @@ config ROCKCHIP_RK3568
select SYSCON
select BOARD_LATE_INIT
imply ROCKCHIP_COMMON_BOARD
+ imply OF_SYSTEM_SETUP
help
The Rockchip RK3568 is a ARM-based SoC with quad-core Cortex-A55,
including NEON and GPU, 512K L3 cache, Mali-G52 based graphics,
diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c
b/arch/arm/mach-rockchip/rk3568/rk3568.c
index ef6bc67a88b0..8d2a59bc649d 100644
--- a/arch/arm/mach-rockchip/rk3568/rk3568.c
+++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -187,3 +188,31 @@ int board_usb_init(int index, enum usb_init_type init)
#endif /* CONFIG_USB_DWC3_GADGET */
#endif /* CONFIG_USB_GADGET */
+
+#ifdef CONFIG_OF_SYSTEM_SETUP
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+ int ret;
+ int areas = 1;
+ u64 start[2], size[2];
+
+ /* Reserve the io address space. */
+ if (gd->ram_top > SDRAM_UPPER_ADDR_MIN) {
+ start[0] = gd->bd->bi_dram[0].start;
+ size[0] = SDRAM_LOWER_ADDR_MAX - gd->bd->bi_dram[0].start;
+
+ /* Add the upper 4GB address space */
+ start[1] = SDRAM_UPPER_ADDR_MIN;
+ size[1] = gd->ram_top - SDRAM_UPPER_ADDR_MIN;
+ areas = 2;
+
+ ret = fdt_set_usable_memory(blob, start, size, areas);
+ if (ret) {
+ printf("Cannot set usable memory\n");
+ return ret;
+ }
+ }
+
+ return 0;
+};
+#endif
diff --git a/arch/arm/mach-rockchip/sdram.c b/arch/arm/mach-rockchip/sdram.c
index 705ec7ba6450..52974e6dc333 100644
--- a/arch/arm/mach-rockchip/sdram.c
+++ b/arch/arm/mach-rockchip/sdram.c
@@ -3,6 +3,8 @@
* Copyright (C) 2017 Rockchip Electronics Co., Ltd.
*/
+#define DEBUG
+
#include
#include
#include
@@ -98,8 +100,7 @@ size_t rockchip_sdram_size(phys_addr_t reg)
SYS_REG_COL_MASK);
cs1_col = cs0_col;
bk = 3 - ((sys_reg2 >> SYS_REG_BK_SHIFT(ch)) & SYS_REG_BK_MASK);
- if ((sys_reg3 >> SYS_REG_VERSION_SHIFT &
-SYS_REG_VERSION_MASK) == 0x2) {
+ if ((sys_reg3 >> SYS_REG_VERSION_SHIFT & SYS_REG_VERSION_MASK)
>= 0x2) {
cs1_col = 9 + (sys_reg3 >> SYS_REG_CS1_COL_SHIFT(ch) &
SYS_REG_CS1_COL_MASK);
if (((sys_reg3 >> SYS_REG_EXTEND_CS0_ROW_SHIFT(ch) &
@@ -136,7 +137,7 @@ size_t rockchip_sdram_size(phys_addr_t reg)
SYS_REG_BW_MASK));
row_3_4 = sys_reg2 >> SYS_REG_ROW_3_4_SHIFT(ch) &
SYS_REG_ROW_3_4_MASK;
- if (dram_type == DDR4) {
+ if ((dram_type == DDR4) && (sys_reg3 >> SYS_REG_VERSION_SHIFT &
SYS_REG_VERSION_MASK) != 0x3){
dbw = (sys_reg2 >> SYS_REG_DBW_SHIFT(ch)) &
SYS_REG_DBW_MASK;
bg = (dbw == 2) ? 2 : 1;
@@ -176,9 +177,11 @@ size_t rockchip_sdram_size(phys_addr_t reg)
* 2. update board_get_usable_ram_top() and dram_init_banksize()
* to reserve memory for peripheral space after previous update.
*/
+
+#ifndef __aarch64__
if (size_mb > (SDRAM_MAX_SIZE >> 20))
size_mb = (SDRAM_MAX_SIZE >> 20);
-
+#endif
return (size_t)size_mb << 20;
}
@@ -208,6 +211,10 @@ int dram_init(void)
ulong board_get_usa
[PATCH v1 09/11] rockchip: move dwc3 config to chip specific handler
The dwc3 code in the mach-rockchip board file is specific to the rk3399.
Move it to the rk3399 chip specific code.
Signed-off-by: Peter Geis
---
arch/arm/mach-rockchip/board.c | 24 -
arch/arm/mach-rockchip/rk3399/rk3399.c | 29 ++
2 files changed, 29 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index 5304eb055c6d..b19c15c26f2e 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -127,30 +127,6 @@ int board_usb_cleanup(int index, enum usb_init_type init)
}
#endif /* CONFIG_USB_GADGET_DWC2_OTG */
-#if defined(CONFIG_USB_DWC3_GADGET) && !defined(CONFIG_DM_USB_GADGET)
-#include
-
-static struct dwc3_device dwc3_device_data = {
- .maximum_speed = USB_SPEED_HIGH,
- .base = 0xfe80,
- .dr_mode = USB_DR_MODE_PERIPHERAL,
- .index = 0,
- .dis_u2_susphy_quirk = 1,
- .hsphy_mode = USBPHY_INTERFACE_MODE_UTMIW,
-};
-
-int usb_gadget_handle_interrupts(int index)
-{
- dwc3_uboot_handle_interrupt(0);
- return 0;
-}
-
-int board_usb_init(int index, enum usb_init_type init)
-{
- return dwc3_uboot_init(&dwc3_device_data);
-}
-#endif /* CONFIG_USB_DWC3_GADGET */
-
#endif /* CONFIG_USB_GADGET */
#if CONFIG_IS_ENABLED(FASTBOOT)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c
b/arch/arm/mach-rockchip/rk3399/rk3399.c
index d40969c88898..c7e38997e521 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -284,3 +284,32 @@ void spl_board_init(void)
#endif
}
#endif
+
+#if defined(CONFIG_USB_GADGET)
+#include
+
+#if defined(CONFIG_USB_DWC3_GADGET) && !defined(CONFIG_DM_USB_GADGET)
+#include
+
+static struct dwc3_device dwc3_device_data = {
+ .maximum_speed = USB_SPEED_HIGH,
+ .base = 0xfe80,
+ .dr_mode = USB_DR_MODE_PERIPHERAL,
+ .index = 0,
+ .dis_u2_susphy_quirk = 1,
+ .hsphy_mode = USBPHY_INTERFACE_MODE_UTMIW,
+};
+
+int usb_gadget_handle_interrupts(int index)
+{
+ dwc3_uboot_handle_interrupt(0);
+ return 0;
+}
+
+int board_usb_init(int index, enum usb_init_type init)
+{
+ return dwc3_uboot_init(&dwc3_device_data);
+}
+#endif /* CONFIG_USB_DWC3_GADGET */
+
+#endif /* CONFIG_USB_GADGET */
--
2.25.1
[PATCH v1 10/11] rockchip: rk3568: add dwc3 otg support
Add the required platform data to the rk3568 chip config, in order to
support dwc3 otg on this chip.
Signed-off-by: Peter Geis
---
arch/arm/mach-rockchip/rk3568/rk3568.c | 29 ++
1 file changed, 29 insertions(+)
diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c
b/arch/arm/mach-rockchip/rk3568/rk3568.c
index 0e0a7f5b54f2..ef6bc67a88b0 100644
--- a/arch/arm/mach-rockchip/rk3568/rk3568.c
+++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
@@ -158,3 +158,32 @@ void spl_board_init(void)
setup_boot_mode();
}
#endif
+
+#if defined(CONFIG_USB_GADGET)
+#include
+
+#if defined(CONFIG_USB_DWC3_GADGET) && !defined(CONFIG_DM_USB_GADGET)
+#include
+
+static struct dwc3_device dwc3_device_data = {
+ .maximum_speed = USB_SPEED_HIGH,
+ .base = 0xfcc0,
+ .dr_mode = USB_DR_MODE_PERIPHERAL,
+ .index = 0,
+ .dis_u2_susphy_quirk = 1,
+ .hsphy_mode = USBPHY_INTERFACE_MODE_UTMIW,
+};
+
+int usb_gadget_handle_interrupts(int index)
+{
+ dwc3_uboot_handle_interrupt(0);
+ return 0;
+}
+
+int board_usb_init(int index, enum usb_init_type init)
+{
+ return dwc3_uboot_init(&dwc3_device_data);
+}
+#endif /* CONFIG_USB_DWC3_GADGET */
+
+#endif /* CONFIG_USB_GADGET */
--
2.25.1
[PATCH v1 06/11] rockchip: handle bootrom recovery mode in spl
Fixup the bootrom recovery mode code to function in spl, so we can
handle recovery mode in case u-boot loading is broken.
Signed-off-by: Peter Geis
---
arch/arm/mach-rockchip/Makefile| 6 +++---
arch/arm/mach-rockchip/boot_mode.c | 4 +++-
arch/arm/mach-rockchip/rk3568/rk3568.c | 23 +++
3 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 00aef0ecee6a..53aff25ce8f6 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -15,13 +15,13 @@ obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
-ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
-
# Always include boot_mode.o, as we bypass it (i.e. turn it off)
# inside of boot_mode.c when CONFIG_BOOT_MODE_REG is 0. This way,
# we can have the preprocessor correctly recognise both 0x0 and 0
# meaning "turn it off".
-obj-y += boot_mode.o
+obj-$(CONFIG_ARCH_ROCKCHIP) += boot_mode.o
+
+ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
obj-$(CONFIG_MISC_INIT_R) += misc.o
endif
diff --git a/arch/arm/mach-rockchip/boot_mode.c
b/arch/arm/mach-rockchip/boot_mode.c
index 1a1a887fc2cd..43cb369465a2 100644
--- a/arch/arm/mach-rockchip/boot_mode.c
+++ b/arch/arm/mach-rockchip/boot_mode.c
@@ -51,7 +51,7 @@ __weak int rockchip_dnl_key_pressed(void)
ret = -ENODEV;
uclass_foreach_dev(dev, uc) {
if (!strncmp(dev->name, "saradc", 6)) {
- ret = adc_channel_single_shot(dev->name, 1, &val);
+ ret = adc_channel_single_shot(dev->name, 0, &val);
break;
}
}
@@ -89,6 +89,7 @@ int setup_boot_mode(void)
boot_mode = readl(reg);
debug("%s: boot mode 0x%08x\n", __func__, boot_mode);
+#if !defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
/* Clear boot mode */
writel(BOOT_NORMAL, reg);
@@ -102,6 +103,7 @@ int setup_boot_mode(void)
env_set("preboot", "setenv preboot; ums mmc 0");
break;
}
+#endif
return 0;
}
diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c
b/arch/arm/mach-rockchip/rk3568/rk3568.c
index 22eeb77d41fa..4e23feb9417f 100644
--- a/arch/arm/mach-rockchip/rk3568/rk3568.c
+++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
@@ -104,3 +104,26 @@ int arch_cpu_init(void)
#endif
return 0;
}
+
+#ifdef CONFIG_SPL_BUILD
+
+void __weak led_setup(void)
+{
+}
+
+void spl_board_init(void)
+{
+ led_setup();
+
+#if defined(SPL_DM_REGULATOR)
+ /*
+* Turning the eMMC and SPI back on (if disabled via the Qseven
+* BIOS_ENABLE) signal is done through a always-on regulator).
+*/
+ if (regulators_enable_boot_on(false))
+ debug("%s: Cannot enable boot on regulator\n", __func__);
+#endif
+
+ setup_boot_mode();
+}
+#endif
--
2.25.1
[PATCH v1 07/11] rockchip: rk3568: add boot device detection
Enable rk3568 spl to detect which device it was booted from.
Signed-off-by: Peter Geis
---
arch/arm/mach-rockchip/rk3568/rk3568.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c
b/arch/arm/mach-rockchip/rk3568/rk3568.c
index 4e23feb9417f..5f239d89a7a9 100644
--- a/arch/arm/mach-rockchip/rk3568/rk3568.c
+++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -23,6 +24,7 @@
#define SGRF_SOC_CON4 0x10
#define EMMC_HPROT_SECURE_CTRL 0x03
#define SDMMC0_HPROT_SECURE_CTRL 0x01
+
/* PMU_GRF_GPIO0D_IOMUX_L */
enum {
GPIO0D1_SHIFT = 4,
@@ -43,6 +45,12 @@ enum {
UART2_IO_SEL_M0 = 0,
};
+const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
+ [BROM_BOOTSOURCE_EMMC] = "/sdhci@fe31",
+ [BROM_BOOTSOURCE_SPINOR] = "/spi@fe30/flash@0",
+ [BROM_BOOTSOURCE_SD] = "/mmc@fe2b",
+};
+
static struct mm_region rk3568_mem_map[] = {
{
.virt = 0x0UL,
--
2.25.1
[PATCH v1 08/11] rockchip: rk3568: enable automatic clock gating
Enable automatic clock gating on rk3568, which solves a 7c temperature
difference on SoQuartz compared to downstream.
Signed-off-by: Peter Geis
---
arch/arm/mach-rockchip/rk3568/rk3568.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c
b/arch/arm/mach-rockchip/rk3568/rk3568.c
index 5f239d89a7a9..0e0a7f5b54f2 100644
--- a/arch/arm/mach-rockchip/rk3568/rk3568.c
+++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
@@ -25,6 +25,15 @@
#define EMMC_HPROT_SECURE_CTRL 0x03
#define SDMMC0_HPROT_SECURE_CTRL 0x01
+#define PMU_BASE_ADDR 0xfdd9
+#define PMU_NOC_AUTO_CON0 (0x70)
+#define PMU_NOC_AUTO_CON1 (0x74)
+#define EDP_PHY_GRF_BASE 0xfdcb
+#define EDP_PHY_GRF_CON0 (EDP_PHY_GRF_BASE + 0x00)
+#define EDP_PHY_GRF_CON10 (EDP_PHY_GRF_BASE + 0x28)
+#define CPU_GRF_BASE 0xfdc3
+#define GRF_CORE_PVTPLL_CON0 (0x10)
+
/* PMU_GRF_GPIO0D_IOMUX_L */
enum {
GPIO0D1_SHIFT = 4,
@@ -99,6 +108,20 @@ void board_debug_uart_init(void)
int arch_cpu_init(void)
{
#ifdef CONFIG_SPL_BUILD
+ /*
+* When perform idle operation, corresponding clock can
+* be opened or gated automatically.
+*/
+ writel(0x, PMU_BASE_ADDR + PMU_NOC_AUTO_CON0);
+ writel(0x000f000f, PMU_BASE_ADDR + PMU_NOC_AUTO_CON1);
+
+ /* Disable eDP phy by default */
+ writel(0x00070007, EDP_PHY_GRF_CON10);
+ writel(0x0ff10ff1, EDP_PHY_GRF_CON0);
+
+ /* Set core pvtpll ring length */
+ writel(0x00ff002b, CPU_GRF_BASE + GRF_CORE_PVTPLL_CON0);
+
/* Set the emmc sdmmc0 to secure */
rk_clrreg(SGRF_BASE + SGRF_SOC_CON4, (EMMC_HPROT_SECURE_CTRL << 11
| SDMMC0_HPROT_SECURE_CTRL << 4));
--
2.25.1
[PATCH v1 04/11] spi: rockchip-sfc: sanity check minimum freq
The rockchip-sfc driver sanity checks the maximum frequency, but not the minimum frequency. This causes the probe to fail when a frequency isn't defined, such as with `sf probe 0`. Clamp the minimum frequency to the rockchip default clock rate. Signed-off-by: Peter Geis --- drivers/spi/rockchip_sfc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/spi/rockchip_sfc.c b/drivers/spi/rockchip_sfc.c index 851a6482985b..d0d2dc70a417 100644 --- a/drivers/spi/rockchip_sfc.c +++ b/drivers/spi/rockchip_sfc.c @@ -164,6 +164,8 @@ /* DMA is only enabled for large data transmission */ #define SFC_DMA_TRANS_THRETHOLD(0x40) +#define SFC_MIN_SPEED (24 * 1000 * 1000) + /* Maximum clock values from datasheet suggest keeping clock value under * 150MHz. No minimum or average value is suggested. */ @@ -596,6 +598,9 @@ static int rockchip_sfc_set_speed(struct udevice *bus, uint speed) if (speed > sfc->max_freq) speed = sfc->max_freq; + if (speed < SFC_MIN_SPEED) + speed = SFC_MIN_SPEED; + if (speed == sfc->speed) return 0; -- 2.25.1
[PATCH v1 05/11] spl: support adc drivers in spl
In order to handle the rockchip recovery handler in spl, we need the adc code to be available in spl. Add a toggle to allow adc drivers to function in spl. Signed-off-by: Peter Geis --- common/spl/Kconfig | 5 + drivers/Makefile | 1 + 2 files changed, 6 insertions(+) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index e0d0a6f77b51..df99042e2fd6 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -454,6 +454,11 @@ config SPL_FIT_IMAGE_TINY ensure this information is available to the next image invoked). +config SPL_ADC + bool "Support ADC drivers in SPL" + help + Enable ADC drivers in SPL. + config SPL_CACHE bool "Support CACHE drivers" help diff --git a/drivers/Makefile b/drivers/Makefile index 4e7cf284405a..ce091ca9a7a4 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -1,5 +1,6 @@ # SPDX-License-Identifier: GPL-2.0+ +obj-$(CONFIG_$(SPL_)ADC) += adc/ obj-$(CONFIG_$(SPL_TPL_)BOOTCOUNT_LIMIT) += bootcount/ obj-$(CONFIG_$(SPL_TPL_)BUTTON) += button/ obj-$(CONFIG_$(SPL_TPL_)CACHE) += cache/ -- 2.25.1
[PATCH v1 02/11] mmc: sdhci: allow disabling sdma in spl
Rockchip emmc devices have a similar issue to Rockchip dwmmc devices,
where performing dma to sram causes errors with suspend/resume.
Allow us to toggle sdma in spl for sdhci similar to adma support, so we
can ensure dma is not used when loading the sram code.
Signed-off-by: Peter Geis
---
drivers/mmc/Kconfig | 7 +++
drivers/mmc/sdhci.c | 6 +++---
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index f04cc44e1973..1e4342285ce7 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -468,6 +468,13 @@ config MMC_SDHCI_SDMA
This enables support for the SDMA (Single Operation DMA) defined
in the SD Host Controller Standard Specification Version 1.00 .
+config SPL_MMC_SDHCI_SDMA
+ bool "Support SDHCI SDMA in SPL"
+ depends on MMC_SDHCI
+ help
+ This enables support for the SDMA (Single Operation DMA) defined
+ in the SD Host Controller Standard Specification Version 1.00 in SPL.
+
config MMC_SDHCI_ADMA
bool "Support SDHCI ADMA2"
depends on MMC_SDHCI
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 766e4a6b0c5e..6285e53d12a2 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -70,7 +70,7 @@ static void sdhci_transfer_pio(struct sdhci_host *host,
struct mmc_data *data)
}
}
-#if (defined(CONFIG_MMC_SDHCI_SDMA) || CONFIG_IS_ENABLED(MMC_SDHCI_ADMA))
+#if (CONFIG_IS_ENABLED(MMC_SDHCI_SDMA) || CONFIG_IS_ENABLED(MMC_SDHCI_ADMA))
static void sdhci_prepare_dma(struct sdhci_host *host, struct mmc_data *data,
int *is_aligned, int trans_bytes)
{
@@ -177,7 +177,7 @@ static int sdhci_transfer_data(struct sdhci_host *host,
struct mmc_data *data)
}
} while (!(stat & SDHCI_INT_DATA_END));
-#if (defined(CONFIG_MMC_SDHCI_SDMA) || CONFIG_IS_ENABLED(MMC_SDHCI_ADMA))
+#if (CONFIG_IS_ENABLED(MMC_SDHCI_SDMA) || CONFIG_IS_ENABLED(MMC_SDHCI_ADMA))
dma_unmap_single(host->start_addr, data->blocks * data->blocksize,
mmc_get_dma_dir(data));
#endif
@@ -836,7 +836,7 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct
sdhci_host *host,
#endif
debug("%s, caps: 0x%x\n", __func__, caps);
-#ifdef CONFIG_MMC_SDHCI_SDMA
+#if CONFIG_IS_ENABLED(MMC_SDHCI_SDMA)
if ((caps & SDHCI_CAN_DO_SDMA)) {
host->flags |= USE_SDMA;
} else {
--
2.25.1
[PATCH v1 03/11] spi: rockchip-sfc: fix building rockchip-sfc
The rockchip-sfc driver is missing an include to build correctly. Signed-off-by: Peter Geis --- drivers/spi/rockchip_sfc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spi/rockchip_sfc.c b/drivers/spi/rockchip_sfc.c index e098acac..851a6482985b 100644 --- a/drivers/spi/rockchip_sfc.c +++ b/drivers/spi/rockchip_sfc.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include -- 2.25.1
[PATCH v1 00/11] rockchip fixes and extend rk3568 support
to: Simon Glass to: Philipp Tomsich to: Kever Yang to: Lukasz Majewski to: Sean Anderson to: Peng Fan to: Jaehoon Chung to: Heiko Stübner cc: u-boot@lists.denx.de Good Evening, The following is a few patches for rockchip mainline u-boot support. Patches 1-3 are fixes for the rk3568 reset handler, rockchip emmc dma to sram, and building the rockchip-sfc driver. Patch 4 adds a sanity check for the minimum sfc frequency. Patch 5 and 6 add adc support to spl and enable the rockchip recovery handler in spl, before attempting to load u-boot. Patch 7 enables rk3568 spl bootrom device detection. Patch 8 enables automatic clock gating and other power saving features on rk3568, which solves the chip running hotter compared to downstream. Patch 9 and 10 move the dwc3 platform data to the chip specific code and enable dwc3 otg support on rk3568. Patch 11 is an RFC patch for fixing ram detection on rk3568. Downstream goes about this a different way, where they implemented a special library to handle this. Please review and *especially test* patch 11. Very Respectfully, Peter Geis Peter Geis (11): clk: rockchip: rk3568: fix reset handler mmc: sdhci: allow disabling sdma in spl spi: rockchip-sfc: fix building rockchip-sfc spi: rockchip-sfc: sanity check minimum freq spl: support adc drivers in spl rockchip: handle bootrom recovery mode in spl rockchip: rk3568: add boot device detection rockchip: rk3568: enable automatic clock gating rockchip: move dwc3 config to chip specific handler rockchip: rk3568: add dwc3 otg support [RFC] rockchip: rk356x: attempt to fix ram detection arch/arm/mach-rockchip/Kconfig | 1 + arch/arm/mach-rockchip/Makefile| 6 +- arch/arm/mach-rockchip/board.c | 24 -- arch/arm/mach-rockchip/boot_mode.c | 4 +- arch/arm/mach-rockchip/rk3399/rk3399.c | 29 +++ arch/arm/mach-rockchip/rk3568/rk3568.c | 112 + arch/arm/mach-rockchip/sdram.c | 19 +++-- common/board_f.c | 7 ++ common/spl/Kconfig | 5 ++ drivers/Makefile | 1 + drivers/clk/rockchip/clk_rk3568.c | 2 + drivers/mmc/Kconfig| 7 ++ drivers/mmc/sdhci.c| 6 +- drivers/spi/rockchip_sfc.c | 6 ++ include/configs/rk3568_common.h| 5 ++ 15 files changed, 197 insertions(+), 37 deletions(-) -- 2.25.1
[PATCH v1 01/11] clk: rockchip: rk3568: fix reset handler
The reset handler for rk3568 is missing its private data. This leads to
an abort when a reset is triggered.
Add the missing dev_set_priv to the rk3568 clk driver.
Fixes: 4a262feba3a5 ("rockchip: rk3568: add clock driver")
Signed-off-by: Peter Geis
---
drivers/clk/rockchip/clk_rk3568.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/rockchip/clk_rk3568.c
b/drivers/clk/rockchip/clk_rk3568.c
index d5e45e7602c7..c83ae22dc302 100644
--- a/drivers/clk/rockchip/clk_rk3568.c
+++ b/drivers/clk/rockchip/clk_rk3568.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -2934,6 +2935,7 @@ static int rk3568_clk_bind(struct udevice *dev)
glb_srst_fst);
priv->glb_srst_snd_value = offsetof(struct rk3568_cru,
glb_srsr_snd);
+ dev_set_priv(sys_child, priv);
}
#if CONFIG_IS_ENABLED(RESET_ROCKCHIP)
--
2.25.1
Re: [PATCH 22/24] rockchip: Support building the all output files in binman
On Thu, Feb 10, 2022 at 2:32 PM Peter Geis wrote:
>
> On Thu, Feb 10, 2022 at 1:58 PM Simon Glass wrote:
> >
> > Hi Peter,
> >
> > On Thu, 10 Feb 2022 at 08:04, Peter Geis wrote:
> > >
> > > On Tue, Feb 8, 2022 at 1:54 PM Simon Glass wrote:
> > > >
> > >
> > > Good Morning,
> > >
> > > > Add the required binman images to replace the Makefile rules which are
> > > > currently used. This includes subsuming:
> > > >
> > > >- tpl/u-boot-tpl-rockchip.bin if TPL is enabled
> > > >- idbloader.img if either or both of SPL and TPL are enabled
> > > >- u-boot.itb2 if SPL_FIT is enabled
> > > >- u-boot-rockchip.bin if SPL is used, either using u-boot.itb2 when
> > > > SPL_FIT is enabled or u-boot.img when it isn't
> > > >
> > > > For now u-boot.itb2 is used as the FIT filename to avoid conflicting
> > > > with
> > > > the current u-boot.itb file. This will be updated in a future patch.
> > > >
> > > > Note that the intermediate files are dropped with binman, since it
> > > > producing everything in one pass. This means that
> > > > tpl/u-boot-tpl-rockchip.bin is not created, for example.
> > >
> > > A question if binman can handle the following:
> > > Currently, it is impossible to build a rk3568 image automatically.
> > > This is due to the fact that unlike previous boards, you must pass
> > > both TPL and SPL to mkimage at the same time (similar to rk3399 spi).
> > > Note: TPL currently isn't built in mainline, it must be pulled from a
> > > prebuilt binary.
> > > ./tools/mkimage -n rk3568 -T rksd -d
> > > rk3568_ddr_1560MHz_v1.12.bin:spl/u-boot-spl.bin idbloader.img
> > >
> > > The Makefile method didn't seem to be able to handle this, so I had to
> > > hack in my own function to do it.
> > > I'm hoping this series provides a more elegant solution.
> >
> > Binman certainly lets you add multiple things in, but the bin: stuff
> > is not supported. If it is simply a case of joining the ddr and SPL
> > then you do that with:
>
> Okay, I'll test this, thanks!
> They both needed to be passed to mkimage because they both get
> checksummed individually, but stored in the same header.
>
> >
> > mkimage {
> >args = ...
> >
> >ddrl {
> > type = "blob-ext";
> > filename = "rk3568_ddr_1560MHz_v1.12.bin";
> >};
> >u-boot-spl {
> >};
Good Evening,
I tested this, unfortunately it seems to cat the two files into a
single file and trying to run that through mkimage, which breaks due
to size constraints:
binman: Error 1 running 'mkimage -d ./mkimage.simple-bin.mkimage -n
rk3568 -T rksd ./mkimage-out.simple-bin.mkimage': Error: SPL image is
too large (size 0x22000 than 0x13000)
This matches the behavior listed in the changes to `tools/binman/binman.rst`
> > };
> >
> > At present mkimage is not a subclass of Entry_section, so alignment
> > and padding of the mkimage input are not supported. But that should be
> > easy enough to change, if needed.
>
> Alignment and padding shouldn't be an issue here.
> mkimage handles everything and spits out a complete file.
>
> I haven't yet confirmed if the rk33 spi padding issue applies to the
> rk35 series, mostly because I haven't yet achieved stable support for
> the SFC in mainline yet.
>
> Thanks again!
> Peter
>
> >
> > [..]
> >
> > Regards,
> > Simon
Re: [PATCH 22/24] rockchip: Support building the all output files in binman
On Thu, Feb 10, 2022 at 1:58 PM Simon Glass wrote:
>
> Hi Peter,
>
> On Thu, 10 Feb 2022 at 08:04, Peter Geis wrote:
> >
> > On Tue, Feb 8, 2022 at 1:54 PM Simon Glass wrote:
> > >
> >
> > Good Morning,
> >
> > > Add the required binman images to replace the Makefile rules which are
> > > currently used. This includes subsuming:
> > >
> > >- tpl/u-boot-tpl-rockchip.bin if TPL is enabled
> > >- idbloader.img if either or both of SPL and TPL are enabled
> > >- u-boot.itb2 if SPL_FIT is enabled
> > >- u-boot-rockchip.bin if SPL is used, either using u-boot.itb2 when
> > > SPL_FIT is enabled or u-boot.img when it isn't
> > >
> > > For now u-boot.itb2 is used as the FIT filename to avoid conflicting with
> > > the current u-boot.itb file. This will be updated in a future patch.
> > >
> > > Note that the intermediate files are dropped with binman, since it
> > > producing everything in one pass. This means that
> > > tpl/u-boot-tpl-rockchip.bin is not created, for example.
> >
> > A question if binman can handle the following:
> > Currently, it is impossible to build a rk3568 image automatically.
> > This is due to the fact that unlike previous boards, you must pass
> > both TPL and SPL to mkimage at the same time (similar to rk3399 spi).
> > Note: TPL currently isn't built in mainline, it must be pulled from a
> > prebuilt binary.
> > ./tools/mkimage -n rk3568 -T rksd -d
> > rk3568_ddr_1560MHz_v1.12.bin:spl/u-boot-spl.bin idbloader.img
> >
> > The Makefile method didn't seem to be able to handle this, so I had to
> > hack in my own function to do it.
> > I'm hoping this series provides a more elegant solution.
>
> Binman certainly lets you add multiple things in, but the bin: stuff
> is not supported. If it is simply a case of joining the ddr and SPL
> then you do that with:
Okay, I'll test this, thanks!
They both needed to be passed to mkimage because they both get
checksummed individually, but stored in the same header.
>
> mkimage {
>args = ...
>
>ddrl {
> type = "blob-ext";
> filename = "rk3568_ddr_1560MHz_v1.12.bin";
>};
>u-boot-spl {
>};
> };
>
> At present mkimage is not a subclass of Entry_section, so alignment
> and padding of the mkimage input are not supported. But that should be
> easy enough to change, if needed.
Alignment and padding shouldn't be an issue here.
mkimage handles everything and spits out a complete file.
I haven't yet confirmed if the rk33 spi padding issue applies to the
rk35 series, mostly because I haven't yet achieved stable support for
the SFC in mainline yet.
Thanks again!
Peter
>
> [..]
>
> Regards,
> Simon
Re: [PATCH 22/24] rockchip: Support building the all output files in binman
On Tue, Feb 8, 2022 at 1:54 PM Simon Glass wrote:
>
Good Morning,
> Add the required binman images to replace the Makefile rules which are
> currently used. This includes subsuming:
>
>- tpl/u-boot-tpl-rockchip.bin if TPL is enabled
>- idbloader.img if either or both of SPL and TPL are enabled
>- u-boot.itb2 if SPL_FIT is enabled
>- u-boot-rockchip.bin if SPL is used, either using u-boot.itb2 when
> SPL_FIT is enabled or u-boot.img when it isn't
>
> For now u-boot.itb2 is used as the FIT filename to avoid conflicting with
> the current u-boot.itb file. This will be updated in a future patch.
>
> Note that the intermediate files are dropped with binman, since it
> producing everything in one pass. This means that
> tpl/u-boot-tpl-rockchip.bin is not created, for example.
A question if binman can handle the following:
Currently, it is impossible to build a rk3568 image automatically.
This is due to the fact that unlike previous boards, you must pass
both TPL and SPL to mkimage at the same time (similar to rk3399 spi).
Note: TPL currently isn't built in mainline, it must be pulled from a
prebuilt binary.
./tools/mkimage -n rk3568 -T rksd -d
rk3568_ddr_1560MHz_v1.12.bin:spl/u-boot-spl.bin idbloader.img
The Makefile method didn't seem to be able to handle this, so I had to
hack in my own function to do it.
I'm hoping this series provides a more elegant solution.
Thanks,
Peter Geis
>
> Note that for some 32-bit rk3288 boards, rockchip-optee.dtsi is included.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/arm/dts/rockchip-u-boot.dtsi | 84 ++-
> 1 file changed, 82 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/rockchip-u-boot.dtsi
> b/arch/arm/dts/rockchip-u-boot.dtsi
> index eae3ee715d..6246ca12b7 100644
> --- a/arch/arm/dts/rockchip-u-boot.dtsi
> +++ b/arch/arm/dts/rockchip-u-boot.dtsi
> @@ -17,13 +17,93 @@
> filename = "u-boot-rockchip.bin";
> pad-byte = <0xff>;
>
> - blob {
> - filename = "idbloader.img";
> +#ifdef CONFIG_TPL
> + mkimage {
> + args = "-n", CONFIG_SYS_SOC, "-T rksd";
> +
> + u-boot-tpl {
> + };
> + };
> +
> + u-boot-spl {
> };
> +#elif defined(CONFIG_SPL) /* SPL only */
> + mkimage {
> + args = "-n", CONFIG_SYS_SOC, "-T rksd";
> +
> + u-boot-spl {
> + };
> + };
> +#endif
> +#if defined(CONFIG_SPL_FIT) && defined(CONFIG_ARM64)
> + fit: fit {
> + description = "FIT image for U-Boot with bl31 (TF-A)";
> + #address-cells = <1>;
> + fit,fdt-list = "of-list";
> + fit,external-offset = ;
> + images {
> + u-boot {
> + description = "U-Boot (64-bit)";
> + type = "standalone";
> + os = "U-Boot";
> + arch = "arm64";
> + compression = "none";
> + load = ;
> + u-boot-nodtb {
> + };
> + };
>
> + @atf-SEQ {
> + fit,operation = "split-elf";
> + description = "ARM Trusted Firmware";
> + type = "firmware";
> + arch = "arm64";
> + os = "arm-trusted-firmware";
> + compression = "none";
> + fit,load;
> + fit,entry;
> + fit,data;
> +
> + atf-bl31 {
> + };
> + };
> + @tee-SEQ {
> + fit,operation = "split-elf";
> + description = "TEE";
> + type = &qu
Re: Chainloading U-Boot from Fastboot on Tegra30
On Fri, Aug 21, 2020 at 7:30 PM Peter Geis wrote: > > On Fri, Aug 21, 2020 at 6:41 PM Stephen Warren wrote: > > > > On 8/21/20 3:39 PM, Tom Rini wrote: > > > On Fri, Aug 21, 2020 at 05:30:54PM -0400, Peter Geis wrote: > > >> On Fri, Aug 21, 2020 at 5:04 PM Tom Rini wrote: > > >>> > > >>> On Fri, Aug 21, 2020 at 04:17:24PM -0400, Peter Geis wrote: > > >>>> On Mon, Jul 6, 2020 at 3:48 PM Peter Geis wrote: > > >>>>> > > >>>>> On Mon, Jul 6, 2020 at 1:04 PM Stephen Warren > > >>>>> wrote: > > >>>>>> > > >>>>>> On 7/3/20 6:32 AM, Peter Geis wrote: > > >>>>>>> Good Morning, > > >>>>>>> > > >>>>>>> I am attempting to expand on the work for chainloading U-Boot on the > > >>>>>>> nyan-big in order to chainload U-Boot on the Ouya Tegra30 device > > >>>>>>> from fastboot. > > >>>>>>> I have so far been unsuccessful at getting any output from U-Boot > > >>>>>>> through this method. > > >>>>>> > > >>>>>> I assume that fastboot executes the loaded code on the main CPU not > > >>>>>> on > > >>>>>> the boot CPU (AVP). U-Boot SPL on Tegra30 expects to start running on > > >>>>>> the AVP though; you would have to disable SPL to make this all work, > > >>>>>> and > > >>>>>> perhaps fix U-Boot to work without SPL present. I'm not sure what, if > > >>>>>> any, changes would be required to support that. > > >>>>>> > > >>>>>> For background, see: > > >>>>>> https://http.download.nvidia.com/tegra-public-appnotes/index.html > > >>>>> > > >>>>> Apologies for the resend, I realized I didn't reply to the list. > > >>>>> > > >>>>> I admit I'm still extremely new to U-Boot, but this is the way I > > >>>>> understand the boot flow. > > >>>>> ROM does extremely low level init, then loads U-boot SPL. > > >>>>> U-Boot SPL does basic init, ram, cpu and required peripherals, then > > >>>>> loads U-Boot.bin. > > >>>>> U-Boot.bin is U-Boot proper, with the full interface. > > >>>>> > > >>>>> By loading U-Boot.bin as the nyan instructions indicated, I'm > > >>>>> bypassing the SPL code as if it was already complete. > > >>>>> The issue I have is I'm not sure what modifications were done to the > > >>>>> T124 code to allow nyan to do this. > > >>>>> I've compared the nyan configs to the cardhu configs and I don't see > > >>>>> anything that sticks out to me. > > >>>>> I've also dug through the nyan git log and I don't see anything that > > >>>>> was specifically changed to allow chainloading on T124. > > >>>>> > > >>>>> I also am unsure of where fastboot is loading the kernel in order to > > >>>>> set the text base correctly. > > >>>> > > >>>> For anyone interested, I succeeded at chainloading u-boot on the Ouya. > > >>> > > >>> Nice work. > > >>> > > >>>> The Linux Kernel with low level debugging enabled in the decompressor > > >>>> will print the load address. > > >>>> > > >>>> Jumping to kernel at:4861 ms > > >>>> > > >>>> C:0x80A000C0-0x8112BA40->0x8152C700-0x81C58080 > > >>>> Uncompressing Linux... > > >>>> > > >>>> So by setting the u-boot text base to 0x80A0 u-boot now executes, > > >>>> but it would then immediately silently reboot. > > >>>> Turns out I needed to define the console in the device-tree, which > > >>>> isn't defined in the u-boot tegra30-cardhu.dts. > > >>>> It would then freeze at relocation time, as it was trying to overwrite > > >>>> the trustzone ram space. > > >>>> #define CONFIG_PRAM 2048 solves that issue. > > >>>> > > >>>> I'd like to know if u-boot can read the reserved-memory device-tree &g
Re: Chainloading U-Boot from Fastboot on Tegra30
On Fri, Aug 21, 2020 at 6:41 PM Stephen Warren wrote: > > On 8/21/20 3:39 PM, Tom Rini wrote: > > On Fri, Aug 21, 2020 at 05:30:54PM -0400, Peter Geis wrote: > >> On Fri, Aug 21, 2020 at 5:04 PM Tom Rini wrote: > >>> > >>> On Fri, Aug 21, 2020 at 04:17:24PM -0400, Peter Geis wrote: > >>>> On Mon, Jul 6, 2020 at 3:48 PM Peter Geis wrote: > >>>>> > >>>>> On Mon, Jul 6, 2020 at 1:04 PM Stephen Warren > >>>>> wrote: > >>>>>> > >>>>>> On 7/3/20 6:32 AM, Peter Geis wrote: > >>>>>>> Good Morning, > >>>>>>> > >>>>>>> I am attempting to expand on the work for chainloading U-Boot on the > >>>>>>> nyan-big in order to chainload U-Boot on the Ouya Tegra30 device from > >>>>>>> fastboot. > >>>>>>> I have so far been unsuccessful at getting any output from U-Boot > >>>>>>> through this method. > >>>>>> > >>>>>> I assume that fastboot executes the loaded code on the main CPU not on > >>>>>> the boot CPU (AVP). U-Boot SPL on Tegra30 expects to start running on > >>>>>> the AVP though; you would have to disable SPL to make this all work, > >>>>>> and > >>>>>> perhaps fix U-Boot to work without SPL present. I'm not sure what, if > >>>>>> any, changes would be required to support that. > >>>>>> > >>>>>> For background, see: > >>>>>> https://http.download.nvidia.com/tegra-public-appnotes/index.html > >>>>> > >>>>> Apologies for the resend, I realized I didn't reply to the list. > >>>>> > >>>>> I admit I'm still extremely new to U-Boot, but this is the way I > >>>>> understand the boot flow. > >>>>> ROM does extremely low level init, then loads U-boot SPL. > >>>>> U-Boot SPL does basic init, ram, cpu and required peripherals, then > >>>>> loads U-Boot.bin. > >>>>> U-Boot.bin is U-Boot proper, with the full interface. > >>>>> > >>>>> By loading U-Boot.bin as the nyan instructions indicated, I'm > >>>>> bypassing the SPL code as if it was already complete. > >>>>> The issue I have is I'm not sure what modifications were done to the > >>>>> T124 code to allow nyan to do this. > >>>>> I've compared the nyan configs to the cardhu configs and I don't see > >>>>> anything that sticks out to me. > >>>>> I've also dug through the nyan git log and I don't see anything that > >>>>> was specifically changed to allow chainloading on T124. > >>>>> > >>>>> I also am unsure of where fastboot is loading the kernel in order to > >>>>> set the text base correctly. > >>>> > >>>> For anyone interested, I succeeded at chainloading u-boot on the Ouya. > >>> > >>> Nice work. > >>> > >>>> The Linux Kernel with low level debugging enabled in the decompressor > >>>> will print the load address. > >>>> > >>>> Jumping to kernel at:4861 ms > >>>> > >>>> C:0x80A000C0-0x8112BA40->0x8152C700-0x81C58080 > >>>> Uncompressing Linux... > >>>> > >>>> So by setting the u-boot text base to 0x80A0 u-boot now executes, > >>>> but it would then immediately silently reboot. > >>>> Turns out I needed to define the console in the device-tree, which > >>>> isn't defined in the u-boot tegra30-cardhu.dts. > >>>> It would then freeze at relocation time, as it was trying to overwrite > >>>> the trustzone ram space. > >>>> #define CONFIG_PRAM 2048 solves that issue. > >>>> > >>>> I'd like to know if u-boot can read the reserved-memory device-tree > >>>> node and use it instead of CONFIG_PRAM? > >>> > >>> Honestly, this is what CONFIG_PRAM is for. We could possibly add > >>> something to get this from device-tree, but we might need to do that > >>> early enough that it becomes a tricky thing to do. > >> > >> Thank you, that makes sense. > >> > >>> > >>>> Otherwise the only issue it see
Re: Chainloading U-Boot from Fastboot on Tegra30
On Fri, Aug 21, 2020 at 5:04 PM Tom Rini wrote: > > On Fri, Aug 21, 2020 at 04:17:24PM -0400, Peter Geis wrote: > > On Mon, Jul 6, 2020 at 3:48 PM Peter Geis wrote: > > > > > > On Mon, Jul 6, 2020 at 1:04 PM Stephen Warren > > > wrote: > > > > > > > > On 7/3/20 6:32 AM, Peter Geis wrote: > > > > > Good Morning, > > > > > > > > > > I am attempting to expand on the work for chainloading U-Boot on the > > > > > nyan-big in order to chainload U-Boot on the Ouya Tegra30 device from > > > > > fastboot. > > > > > I have so far been unsuccessful at getting any output from U-Boot > > > > > through this method. > > > > > > > > I assume that fastboot executes the loaded code on the main CPU not on > > > > the boot CPU (AVP). U-Boot SPL on Tegra30 expects to start running on > > > > the AVP though; you would have to disable SPL to make this all work, and > > > > perhaps fix U-Boot to work without SPL present. I'm not sure what, if > > > > any, changes would be required to support that. > > > > > > > > For background, see: > > > > https://http.download.nvidia.com/tegra-public-appnotes/index.html > > > > > > Apologies for the resend, I realized I didn't reply to the list. > > > > > > I admit I'm still extremely new to U-Boot, but this is the way I > > > understand the boot flow. > > > ROM does extremely low level init, then loads U-boot SPL. > > > U-Boot SPL does basic init, ram, cpu and required peripherals, then > > > loads U-Boot.bin. > > > U-Boot.bin is U-Boot proper, with the full interface. > > > > > > By loading U-Boot.bin as the nyan instructions indicated, I'm > > > bypassing the SPL code as if it was already complete. > > > The issue I have is I'm not sure what modifications were done to the > > > T124 code to allow nyan to do this. > > > I've compared the nyan configs to the cardhu configs and I don't see > > > anything that sticks out to me. > > > I've also dug through the nyan git log and I don't see anything that > > > was specifically changed to allow chainloading on T124. > > > > > > I also am unsure of where fastboot is loading the kernel in order to > > > set the text base correctly. > > > > For anyone interested, I succeeded at chainloading u-boot on the Ouya. > > Nice work. > > > The Linux Kernel with low level debugging enabled in the decompressor > > will print the load address. > > > > Jumping to kernel at:4861 ms > > > > C:0x80A000C0-0x8112BA40->0x8152C700-0x81C58080 > > Uncompressing Linux... > > > > So by setting the u-boot text base to 0x80A0 u-boot now executes, > > but it would then immediately silently reboot. > > Turns out I needed to define the console in the device-tree, which > > isn't defined in the u-boot tegra30-cardhu.dts. > > It would then freeze at relocation time, as it was trying to overwrite > > the trustzone ram space. > > #define CONFIG_PRAM 2048 solves that issue. > > > > I'd like to know if u-boot can read the reserved-memory device-tree > > node and use it instead of CONFIG_PRAM? > > Honestly, this is what CONFIG_PRAM is for. We could possibly add > something to get this from device-tree, but we might need to do that > early enough that it becomes a tricky thing to do. Thank you, that makes sense. > > > Otherwise the only issue it seems to have it is does not read the > > nvidia proprietary partition table. > > Is there a way to force u-boot to read the backup gpt table similar to > > the android kernel's method? > > Some tangential experiments the other day and I saw that U-Boot would > read the backup GPT if it's at the expected place. But that might be > only after you do something like "part list mmc 0", so there might in > turn be places that we need to be a bit more robust in our checking. Unfortunately running returns "## Unknown partition table type 0" This is the result of the gpt guid command: Tegra30 (Ouya) # gpt guid mmc 0 GUID Partition Table Header signature is wrong: 0x1000 != 0x5452415020494645 find_valid_gpt: *** ERROR: Invalid GPT *** find_valid_gpt: ***Using Backup GPT *** ---- success! The backup GPT is a valid GPT, and linux will pull the partition table from it if forced to look there. The android kernel handled this by adding "gpt gpt_sector=15073279" to the command line. > > -- > Tom
Re: Chainloading U-Boot from Fastboot on Tegra30
On Mon, Jul 6, 2020 at 3:48 PM Peter Geis wrote: > > On Mon, Jul 6, 2020 at 1:04 PM Stephen Warren wrote: > > > > On 7/3/20 6:32 AM, Peter Geis wrote: > > > Good Morning, > > > > > > I am attempting to expand on the work for chainloading U-Boot on the > > > nyan-big in order to chainload U-Boot on the Ouya Tegra30 device from > > > fastboot. > > > I have so far been unsuccessful at getting any output from U-Boot > > > through this method. > > > > I assume that fastboot executes the loaded code on the main CPU not on > > the boot CPU (AVP). U-Boot SPL on Tegra30 expects to start running on > > the AVP though; you would have to disable SPL to make this all work, and > > perhaps fix U-Boot to work without SPL present. I'm not sure what, if > > any, changes would be required to support that. > > > > For background, see: > > https://http.download.nvidia.com/tegra-public-appnotes/index.html > > Apologies for the resend, I realized I didn't reply to the list. > > I admit I'm still extremely new to U-Boot, but this is the way I > understand the boot flow. > ROM does extremely low level init, then loads U-boot SPL. > U-Boot SPL does basic init, ram, cpu and required peripherals, then > loads U-Boot.bin. > U-Boot.bin is U-Boot proper, with the full interface. > > By loading U-Boot.bin as the nyan instructions indicated, I'm > bypassing the SPL code as if it was already complete. > The issue I have is I'm not sure what modifications were done to the > T124 code to allow nyan to do this. > I've compared the nyan configs to the cardhu configs and I don't see > anything that sticks out to me. > I've also dug through the nyan git log and I don't see anything that > was specifically changed to allow chainloading on T124. > > I also am unsure of where fastboot is loading the kernel in order to > set the text base correctly. For anyone interested, I succeeded at chainloading u-boot on the Ouya. The Linux Kernel with low level debugging enabled in the decompressor will print the load address. Jumping to kernel at:4861 ms C:0x80A000C0-0x8112BA40->0x8152C700-0x81C58080 Uncompressing Linux... So by setting the u-boot text base to 0x80A0 u-boot now executes, but it would then immediately silently reboot. Turns out I needed to define the console in the device-tree, which isn't defined in the u-boot tegra30-cardhu.dts. It would then freeze at relocation time, as it was trying to overwrite the trustzone ram space. #define CONFIG_PRAM 2048 solves that issue. I'd like to know if u-boot can read the reserved-memory device-tree node and use it instead of CONFIG_PRAM? Otherwise the only issue it seems to have it is does not read the nvidia proprietary partition table. Is there a way to force u-boot to read the backup gpt table similar to the android kernel's method?
Re: Chainloading U-Boot from Fastboot on Tegra30
On Mon, Jul 6, 2020 at 1:04 PM Stephen Warren wrote: > > On 7/3/20 6:32 AM, Peter Geis wrote: > > Good Morning, > > > > I am attempting to expand on the work for chainloading U-Boot on the > > nyan-big in order to chainload U-Boot on the Ouya Tegra30 device from > > fastboot. > > I have so far been unsuccessful at getting any output from U-Boot > > through this method. > > I assume that fastboot executes the loaded code on the main CPU not on > the boot CPU (AVP). U-Boot SPL on Tegra30 expects to start running on > the AVP though; you would have to disable SPL to make this all work, and > perhaps fix U-Boot to work without SPL present. I'm not sure what, if > any, changes would be required to support that. > > For background, see: > https://http.download.nvidia.com/tegra-public-appnotes/index.html Apologies for the resend, I realized I didn't reply to the list. I admit I'm still extremely new to U-Boot, but this is the way I understand the boot flow. ROM does extremely low level init, then loads U-boot SPL. U-Boot SPL does basic init, ram, cpu and required peripherals, then loads U-Boot.bin. U-Boot.bin is U-Boot proper, with the full interface. By loading U-Boot.bin as the nyan instructions indicated, I'm bypassing the SPL code as if it was already complete. The issue I have is I'm not sure what modifications were done to the T124 code to allow nyan to do this. I've compared the nyan configs to the cardhu configs and I don't see anything that sticks out to me. I've also dug through the nyan git log and I don't see anything that was specifically changed to allow chainloading on T124. I also am unsure of where fastboot is loading the kernel in order to set the text base correctly.
Re: Chainloading U-Boot from Fastboot on Tegra30
On Sun, Jul 5, 2020 at 11:35 AM Simon Glass wrote: > > Hi Peter, > > On Sun, 5 Jul 2020 at 05:33, Peter Geis wrote: > > > > On Sat, Jul 4, 2020 at 3:53 PM Simon Glass wrote: > > > > > > Hi Peter, > > > > > > On Fri, 3 Jul 2020 at 06:33, Peter Geis wrote: > > > > > > > > Good Morning, > > > > > > > > I am attempting to expand on the work for chainloading U-Boot on the > > > > nyan-big in order to chainload U-Boot on the Ouya Tegra30 device from > > > > fastboot. > > > > I have so far been unsuccessful at getting any output from U-Boot > > > > through this method. > > > > > > > > I'm building the cardhu board with tweaks for Ouya's specifications > > > > similar to my work for the linux kernel. > > > > I build the image using mkbootimg --kernel u-boot.bin --ramdisk > > > > /dev/null --output u-boot-android.bin. > > > > I then fastboot boot u-boot-android.bin. > > > > > > > > I've tried tweaking the text base and tried both standard debug and > > > > low level debug. > > > > > > > > Do you think you could give me some insight into where I'm going wrong? > > > > > > Is it possible that fastboot expects a relocatable image? If you set > > > up the debug UART very early you might be able to output a character > > > in start.S ? > > > > Yes, fastboot expects a relocatable image. > > As I understand it though, if I get the text base correct, U-boot will > > not need to relocate. > > > > The debug UART is already set up when it fastboot jumps to the loaded > > kernel, > > So I should be able to dump data to the expected raw address and it > > will show up? > > Yes, so long as you know the address. Is the MMU turned off? Cache? It is unknown what state either of these are in, since I am unfamiliar at all with how fastboot functions with these. In U-boot yes the MMU was enabled as well as both I and D cache. > > > > > > > > > BTW does U-Boot have support for the fastboot protocol? Perhaps you > > > could just use U-Boot? > > > > The Ouya is locked with a signed boot loader, like most consumer > > android devices. > > Unlike most other devices, it does not have a hardware method for > > entering the bootloader in case of a brick. > > We are currently using a hacked kernel that stores another kernel in > > "safe" ram via kexec and hard resets the board, but a proper > > bootloader would be much more preferable. > > OK. Maybe there is someone on this list with a bit more Android > booting experienec? > > > > > I found one example of where fastboot chainloaded u-boot successfully > > on the galaxy nexus, from 2013. > > https://forum.xda-developers.com/galaxy-nexus/bootloader-boot-multi-boot-support-t2201146 > > OK, I'm sure it is possible. Do you have the source code for the > fastboot code that boots U-Boot? No, we have the reference code here: https://android.googlesource.com/platform/bootable/bootloader/legacy/+/b1fde5cd7d5158b8e6876139ca76a341d0e49708/usbloader/usbloader.c Unfortunately the behavior observed in the Ouya shows it has been heavily modified from this baseline. I've reached out to the dev who performed the work on u-boot for insight as well. > > Regards, > Simon
Re: Chainloading U-Boot from Fastboot on Tegra30
On Sat, Jul 4, 2020 at 3:53 PM Simon Glass wrote: > > Hi Peter, > > On Fri, 3 Jul 2020 at 06:33, Peter Geis wrote: > > > > Good Morning, > > > > I am attempting to expand on the work for chainloading U-Boot on the > > nyan-big in order to chainload U-Boot on the Ouya Tegra30 device from > > fastboot. > > I have so far been unsuccessful at getting any output from U-Boot > > through this method. > > > > I'm building the cardhu board with tweaks for Ouya's specifications > > similar to my work for the linux kernel. > > I build the image using mkbootimg --kernel u-boot.bin --ramdisk > > /dev/null --output u-boot-android.bin. > > I then fastboot boot u-boot-android.bin. > > > > I've tried tweaking the text base and tried both standard debug and > > low level debug. > > > > Do you think you could give me some insight into where I'm going wrong? > > Is it possible that fastboot expects a relocatable image? If you set > up the debug UART very early you might be able to output a character > in start.S ? Yes, fastboot expects a relocatable image. As I understand it though, if I get the text base correct, U-boot will not need to relocate. The debug UART is already set up when it fastboot jumps to the loaded kernel, So I should be able to dump data to the expected raw address and it will show up? > > BTW does U-Boot have support for the fastboot protocol? Perhaps you > could just use U-Boot? The Ouya is locked with a signed boot loader, like most consumer android devices. Unlike most other devices, it does not have a hardware method for entering the bootloader in case of a brick. We are currently using a hacked kernel that stores another kernel in "safe" ram via kexec and hard resets the board, but a proper bootloader would be much more preferable. I found one example of where fastboot chainloaded u-boot successfully on the galaxy nexus, from 2013. https://forum.xda-developers.com/galaxy-nexus/bootloader-boot-multi-boot-support-t2201146 > > Regards, > Simon
Chainloading U-Boot from Fastboot on Tegra30
Good Morning, I am attempting to expand on the work for chainloading U-Boot on the nyan-big in order to chainload U-Boot on the Ouya Tegra30 device from fastboot. I have so far been unsuccessful at getting any output from U-Boot through this method. I'm building the cardhu board with tweaks for Ouya's specifications similar to my work for the linux kernel. I build the image using mkbootimg --kernel u-boot.bin --ramdisk /dev/null --output u-boot-android.bin. I then fastboot boot u-boot-android.bin. I've tried tweaking the text base and tried both standard debug and low level debug. Do you think you could give me some insight into where I'm going wrong? Thank you, Peter Geis
Re: [PATCH] rockchip: Add delay after link-training
On Tue, Jun 2, 2020 at 11:12 AM Kurt Miller wrote: > > On Tue, 2020-06-02 at 10:23 +0800, Shawn Lin wrote: > > > > 在 2020/6/2 9:59, Kever Yang 写道: > > > > > > Hi Kurt, > > > > > > On 2020/6/2 上午4:30, Kurt Miller wrote: > > > > > > > > On at least the RockPro64, many cards will trip a > > > > synchronous abort when first accessing PCIe config space > > > > during bus scanning. A delay after link training allows > > > > some of these cards to function. > > > > > > > > Signed-off-by: Kurt Miller > > > > --- > > > > On the RockPro64, some pci cards trip a synchronous abort when > > > > scanning the > > > > pci bus. For example with HighPoint Rocket Raid 640L which is based on > > > > Marvell 88SE9230 I see this: > > > > > > > > => pci > > > > "Synchronous Abort" handler, esr 0x96000210 > > > > elr: 0022d034 lr : 0022cfd0 (reloc) > > > > elr: f4568034 lr : f4567fd0 > > > > x0 : 0010 x1 : f800 > > > > x2 : x3 : 0010 > > > > x4 : f2559290 x5 : > > > > x6 : 0001 x7 : f2559860 > > > > x8 : 0030 x9 : 0008 > > > > x10: 0010 x11: f251fd1c > > > > x12: 1421 x13: 1468 > > > > x14: f251fd4c x15: > > > > x16: 00060001 x17: 001f > > > > x18: f2532dc0 x19: f251fcd0 > > > > x20: 0001 x21: > > > > x22: 0001 x23: f45d4000 > > > > x24: x25: f45bc000 > > > > x26: x27: > > > > x28: f2541440 x29: f251fc20 > > > > > > > > Code: 54c1 35a5 93407c00 f9400081 (b8616800) > > > > Resetting CPU ... > > > > > > > > Adding a delay after link training works-around the problem. I added > > > > this > > > > delay to the OpenBSD rkpcie driver as well: > > > > > > > > https://github.com/openbsd/src/commit/9857dee3520d8ca5bec68538f4b0708d7e64fc87 > > > > > > > > > > > > HighPoint Rocket Raid 640L needs a 1.75 sec delay and Crossfield > > > > SAS9211-4i > > > > needs a 1 second delay, so I arbitrarily decided on 2 seconds. > > > > > > > > The delay work-around was originally discovered by nuumio: > > > > https://github.com/nuumio/linux-kernel/commit/5a65b17686002dc84d461bffa324a2cb68e67aee > > > > > > > > > > > > drivers/pci/pcie_rockchip.c | 8 > > > > 1 file changed, 8 insertions(+) > > > > > > > > diff --git a/drivers/pci/pcie_rockchip.c b/drivers/pci/pcie_rockchip.c > > > > index 0edc2464a8..51cfbf6b18 100644 > > > > --- a/drivers/pci/pcie_rockchip.c > > > > +++ b/drivers/pci/pcie_rockchip.c > > > > @@ -288,6 +288,14 @@ static int rockchip_pcie_init_port(struct udevice > > > > *dev) > > > > goto err_power_off_phy; > > > > } > > > > +/* > > > > + * XXX: On at least the RockPro64, many cards will trip a > > > > + * synchronous abort when first accessing PCIe config space > > > > + * during bus scanning. A delay after link training allows > > > > + * some of these cards to function. > > > > + */ > > > > +mdelay(2000); > > > I don't understand what kind of delay for init needs 2 Seconds, root > > > cause will preferred. > > Hi Kever, > > While working on this issue for the OpenBSD PCIe driver I was not > able to determine the root cause. I tested the following adapters: > > ROCKPro64 2 Port SATA > StarTech PEXSAT32 2 Port SATA > Samsung 970 Evo NVMe w/m.2 adapter > IO CREST SI-PEX40148 2 Port SATA > IO CREST SI-PEX40057 4 port > HighPoint Rocket Raid 640L > Crossfield SAS9211-4i > Del PERC H200 > Dell PERC 6/i > Intel Gigabit VT Quad Port Server > > All of the above adapters successfully link trained, however > three of them would panic upon the first read of the PCI config > space. nuumio's work-around of placing a delay after link-training > allows these cards to work. > > HighPoint Rocket Raid 640L ~1.75 sec delay > Crossfield SAS9211-4i ~1 sec delay > Dell PERC H200 ~1 sec delay > > In attempt to determine if there was a way to detect how long > to wait, I compared every status and debug register documented > in the rk3399 TRM part 2 for the PCI controller. I compared the > values pre-delay and post-delay. I was not able to find a value > that would indicate it was safe to proceed. > > > Strictly speaking, how long should we need for this had been provided, > > see this: > > > > https://patchwork.kernel.org/patch/11561977/ > > > > If you need more delay, I highly suspect you should check if > > the power supply is stable before enabling training. > > Hi Shawn, > > Thank you for pointing out the need for the 100ms delay before > beginning link-training. I believe this is to correct link > training failures, while the delay after link training is > to work-around post link training reading of PCI config > space on certain cards. There are similar issues on the Linux driver with various cards randomly t
Re: [PATCH v2 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board
On Thu, Apr 23, 2020 at 5:24 AM Chen-Yu Tsai wrote: > > Hi, > > On Tue, Apr 21, 2020 at 1:35 AM Peter Geis wrote: > > > > On Thu, Apr 16, 2020 at 5:53 AM Loic Devulder wrote: > > > > > > Hi Chen, > > > > > > I tested your patches and all work pretty well. I just had issues with > > > USB2 that doesn't recognize any of my USB keys (it's OK on USB3). > > > > > > I also had these issues with XHCI driver: > > > => usb reset > > > resetting USB... > > > BUG at drivers/usb/host/xhci-mem.c:84/xhci_ring_free()! > > > BUG! > > > �esetting ... > > > > > > => usb stop > > > stopping USB.. > > > Host not halted after 16000 microseconds. > > > XHCI: failed to set VBus supply > > > device_remove: Device 'usb@ff60' failed to remove, but children are > > > gone > > > > > > But for the whole series: Tested-by: Loic Devulder > > > > > > On Sun, 2020-04-05 at 10:25 +0800, Chen-Yu Tsai wrote: > > > > From: Chen-Yu Tsai > > > > > > > > Hi everyone, > > > > > > > > This is v2 of my ROC-RK3328-CC series. Changes from v1 are mainly > > > > dropping the custom board target, and dealing with the pinmuxing > > > > through proper use of DM regulators / GPIO / pinctrl in SPL. > > > > > > > > This series adds proper support for Firefly / Libre Computer ROC- > > > > RK3328-CC > > > > single board computer. > > > > > > > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit > > > > card size development board based on the Rockchip RK3328 SoC, with: > > > > > > > > - 1/2/4 GB DDR4 DRAM > > > > - eMMC connector for optional module > > > > - micro SD card slot > > > > - 1 x USB 3.0 host port > > > > - 2 x USB 2.0 host port > > > > - 1 x USB 2.0 OTG port > > > > - HDMI video output > > > > - TRRS connector with audio and composite video output > > > > - gigabit Ethernet > > > > - consumer IR receiver > > > > - debug UART pins > > > > > > > > Originally I started with Loic's patches, and syncing the device tree > > > > files from Linux. That didn't get very far, with SPL failing to > > > > detect > > > > the SD card. Examining the schematics and internal state of GRF and > > > > GPIOs, I realized that the logic for the SD card power enable switch > > > > is opposite that of what the SD card controller's SDMMC0_PWREN pin > > > > would use. Instead, directly using the GPIO is required. > > > > > > > > To deal with this, DM regulator and GPIO are enabled in SPL, and > > > > various device nodes are marked with u-boot,dm-spl to have them work. > > > > pinctrl properties are not stripped, so as to have the SDMMC0_PWREN > > > > pin muxed over to GPIO. > > > > > > > > Along the way, there are some clean-ups of existing dts files, moving > > > > U-boot only features to -u-boot.dtsi files, and then a wholesale sync > > > > from Linux. Only boards already existing in U-boot are synced. DT > > > > binding header files are synced separately as there is already one > > > > patch floating around. The DT sync also includes clean-up changes > > > > only > > > > recently posted, and likely won't make it in for at least a few > > > > weeks. > > > > > > > > Please have a look, and test if possible. I cc-ed a couple people > > > > that > > > > showed interest in this board on mailing lists recently. > > > > > > > > Regards > > > > ChenYu > > > > > > > > > > > > Chen-Yu Tsai (6): > > > > rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u- > > > > boot.dtsi > > > > rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u- > > > > boot.dtsi > > > > dt-bindings: clock: rk3328: sync from upstream Linux kernel > > > > dt-bindings: power: rk3328-power: sync from upstream Linux kernel > > > > rockchip: dts: rk3328: Sync device tree files from Linux > > > > rockchip: rk3328: Add support for ROC-RK3328-CC board > > > > > > > > arch/arm/dts/Makefile |1 + > > > > arch/arm/d
Re: [PATCH v2 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board
wer.h > > > -- > Loic Devulder | ldevulder@irc > 0x175A963893C85F55 | D220 DEF5 56A3 DE00 9DAA 78BA 175A 9638 93C8 5F55 > Senior QA Engineer | Container & Storage Solutions Quality Assurance > team (qa-css) > SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB, 21284 (AG > Nuernberg) Good Afternoon, I have tested this patch set against u-boot git as of 20 April 2020 and have some feedback. The issue of booting off the sdmmc is fixed, thanks! The USB issues above come from a few issues: vcc_host1_5v is set to regulator-always-on, which prevents USB from resetting properly, remove this option allows xhci to clean up. USB 2.0 Host does not work because there is no rockchip,rk3328-usb2phy yet. This causes the generic ohci and ehci drivers to fail, removing CONFIG_PHY from your defconfig resolves this. The USB-OTG port appears to not work because it's stuck in peripheral mode. The vbus-supply = <&vcc_host1_5v> should be on all three USB controllers, as it powers all three ports. Overall, excellent work! For the whole series: Tested-by: Peter Geis
Re: [PATCH v1 0/2] Add roc-rk3328-cc support
On Fri, Feb 14, 2020 at 9:47 AM Loic Devulder wrote: > > This serie add support for roc-rk33239 board from Firefly/Libre > Computer: > - add missing L2 cache entry in rk3328 dts > - add roc-rk3328-cc board support > > With this we can successfully boot the board with mainline U-Boot and > binary blob firmwares. Boot with ATF and TPL/SPL partially works: TPL > works fine but SPL fails to find a bootable device. I have tpl/spl fully enabled on this device privately. The SPL fails to find a boot device when booted from the sdcard. It successfully boots from emmc though. I believe this is due to the 3.3/1.8 mode switch. Have you tested off emmc with your patch? > > I didn't used the DTS from Linux kernel: USB2 fails in that case, this > should be corrected but maybe later? > > Note: sorry if this serie has been send twice, but I had issue with my > email server... > > > Loic Devulder (2): > rockchip: rk3328: dts: add L2 cache entry > rockchip: rk3328: add roc-rk3328-cc support > > arch/arm/dts/Makefile | 3 +- > arch/arm/dts/rk3328-roc-cc-u-boot.dtsi | 16 ++ > arch/arm/dts/rk3328-roc-cc.dts | 260 + > arch/arm/dts/rk3328.dtsi | 25 ++- > arch/arm/mach-rockchip/rk3328/Kconfig | 1 - > board/rockchip/evb_rk3328/MAINTAINERS | 6 + > configs/roc-cc-rk3328_defconfig| 95 + > doc/README.rockchip| 9 +- > 8 files changed, 408 insertions(+), 7 deletions(-) > create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi > create mode 100644 arch/arm/dts/rk3328-roc-cc.dts > create mode 100644 configs/roc-cc-rk3328_defconfig > > -- > 2.25.0 >
Re: rk3328-firefly ddr4 tpl init【请注意，邮件由linux-rockchip-bounces+kever.yang=rock-chips....@lists.infradead.org代发】
On Thu, Dec 12, 2019 at 10:22 PM Kever Yang wrote: > > Hi Peter, > > On 2019/12/5 上午10:19, Peter Geis wrote: > > Good Evening, > > > > I am trying to get TPL/SPL working on the rk3328-firefly ddr4 4gb board. > > I've pulled the ddr4 dtsi from the rockchip u-boot repository [0]. > > > > Unfortunately I cannot get the ddr4 to detect correctly. > > > Yes, the ddr4 support for rk3328 is missing now, we will update it some > time later. > > > Thanks, > > - Kever Thank you for letting me know. I'll be sure to test it for you when it lands. > > > > > With the u-boot tpl, I get the following: > > U-Boot TPL 2020.01-rc3-00072-g1a1bea82b2-dirty (Dec 04 2019 - 08:33:54) > > data training error > > row errordata training error > > DDR4, 333MHz > > BW=16 Col=10 Bk=4 BG=2 CS0 Row=17 CS=1 Die BW=16 Size=2048MB > > > > With the rk3328_ddr_333MHz_v1.16.bin, I get the following: > > DDR version 1.16 20190528 > > ID:0x805 N > > In > > DDR4 > > 333MHz > > Bus Width=32 Col=10 Bank=4 Bank Group=2 Row=16/16 CS=2 Die > > Bus-Width=16 Size=4096MB > > ddrconfig:19 > > OUT > > > > [0] > > https://github.com/rockchip-linux/u-boot/blob/next-dev/arch/arm/dts/rk3328-sdram-ddr4-666.dtsi > > > > ___ > > Linux-rockchip mailing list > > linux-rockc...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-rockchip > > > > > >
rk3328-firefly ddr4 tpl init
Good Evening, I am trying to get TPL/SPL working on the rk3328-firefly ddr4 4gb board. I've pulled the ddr4 dtsi from the rockchip u-boot repository [0]. Unfortunately I cannot get the ddr4 to detect correctly. With the u-boot tpl, I get the following: U-Boot TPL 2020.01-rc3-00072-g1a1bea82b2-dirty (Dec 04 2019 - 08:33:54) data training error row errordata training error DDR4, 333MHz BW=16 Col=10 Bk=4 BG=2 CS0 Row=17 CS=1 Die BW=16 Size=2048MB With the rk3328_ddr_333MHz_v1.16.bin, I get the following: DDR version 1.16 20190528 ID:0x805 N In DDR4 333MHz Bus Width=32 Col=10 Bank=4 Bank Group=2 Row=16/16 CS=2 Die Bus-Width=16 Size=4096MB ddrconfig:19 OUT [0] https://github.com/rockchip-linux/u-boot/blob/next-dev/arch/arm/dts/rk3328-sdram-ddr4-666.dtsi
Re: [U-Boot] [REGRESSION] tegra124: nyan-big: LPAE not working
On 2/11/2019 5:13 PM, Stephen Warren wrote: On 2/11/19 3:48 AM, Thierry Reding wrote: On Mon, Feb 11, 2019 at 10:04:37AM +, Tristan Bastian wrote: Thierry Reding – Mon, 11. February 2019 10:38 On Mon, Feb 11, 2019 at 09:20:33AM +, Tristan Bastian wrote: Thierry Reding – Mon, 11. February 2019 9:52 On Sun, Feb 10, 2019 at 08:53:11PM +0100, Tristan Bastian wrote: Thierry, do you have any news on this? I don't think, that google is going to push an updated version of coreboot to each nyan-big device.. So reverting this patch at least for the nyan devices would be the best I think.. Yes, I agree. I had a brief chat with Rob Herring about this and he too agrees that we should revert it for now. I'll make it a manual revert and add a comment to the device tree node that will hopefully avoid any future janitorial "cleanups" of this sort. great news! :) BTW: I'm now running u-boot natively and it seems like u-boot always has a problem with the memory.. If u-boot is used chainloaded to coreboot it is only getting 2GB of memory and running u-boot natively also just gives me 2GB.. I've tested that with a kernel with "ARM: tegra: Fix unit_address_vs_reg DTC warnings for /memory" reverted and also on a kernel, before this patch was applied.. It's possible that U-Boot doesn't support LPAE and therefore may not be able to use more than the 2 GiB of memory. So I at least enabled LPAE in u-boot with "CONFIG_ARMV7_LPAE=y" and this was for some reason also needed to get some output on the display.. I'm not sure why LPAE needs to activated in u-boot for display output on the nyan-big.. Without LPAE enabled u-boot was still working, and booted linux, but u-boot didn't display anything on screen, linux then did.. Yeah, that's surprising. Perhaps without LPAE U-Boot thinks there's not enough memory for the framebuffer? There should be plenty, so maybe there is something else going on here. However, U-Boot should be able to tell the kernel exactly how much memory the system has and pass that on via device tree. That still does work, right? It seems like this is not working.. And this seems to be the case with both, u-boot chainloaded and running u-boot natively.. I've used these scripts for flashing: github.com/NVIDIA/tegra-uboot-flasher-scripts And used the norrin device since it seems like it is the nyan-big dev board? But going with the norrin device config should not be the issue here since the problem also exists when chainloading u-boot, right? It could be a problem. The memory bank configuration is stored in what's called a BCT along with a bunch of other parameters that define what the memory controller needs to access the given memory chips. So if you've flashed a BCT that's for a board with only 2 GiB of memory you would end up with a system that can't address any more than that. It's somewhat surprising that memory accesses work at all with a BCT that's for different memory chips, but sometimes you can get lucky. You may want to try reflashing with the right BCT. The simplest would probably be to duplicate the cbootimage configuration for Norrin and substitute the relevant bits by what you have from the Chromebook flash utilities. Looks like the BCT in really the only thing you can replace there. Make sure to replace it with the one that matches your Chromebook and it should give you the right memory bank configuration. Is there a way to check if the correct bct for my 4GB model was used? What I tried was to edit the existing bct config file of norrin from here: https://github.com/NVIDIA/cbootimage-configs/blob/master/tegra124/nvidia/norrin/PM370_Hynix_2GB_H5TC4G63AFR_PBA_924MHz_01212014.bct.cfg by replacing all entries for each memory bank with the entries from here: https://github.com/coreboot/coreboot/blob/master/src/mainboard/google/nyan_big/bct/sdram-hynix-4GB-792.inc I also added the SDRAM[0], SDRAM[1], SDRAM[2], SDRAM[3] each time in front of each line.. This also booted for me, but also just leaves me with only 2Gb of my 4GB.. And since this problem also occurs, when chainloading u-boot, this must be a problem with u-boot, I think.. Not necessarily. U-Boot reads the memory size from EMC registers and those EMC registers are programmed based on the contents of the BCT. So if the BCT is wrong, then it's going to be wrong irrespective of what bootloader you use. That said, I does indeed look as if U-Boot only supports 2 GiB of memory on 32-bit Tegra. arch/arm/mach-tegra/board.c contains the relevant code. If you look at dram_init() it uses query_sdram_size() to get the size of RAM. That will allow to convey up to 4 GiB of RAM, but then the code in board2.c (see dram_init_banksize()) only uses a single bank on 32-bit Tegra (CONFIG_PHYS_64BIT is only set for 64-bit Tegra). According to the comments for dram_init_bank_size() we can't store the second bank because the .start field is 32 bits wide and therefore can't store the 0x
