[PATCH v1 06/11] rockchip: handle bootrom recovery mode in spl

[Peter Geis]

On Mon, Mar 14, 2022 at 7:59 AM Philipp Tomsich
<philipp.tomsich at vrull.eu> wrote:
>
> On Tue, 22 Feb 2022 at 02:31, Peter Geis <pgwipeout at gmail.com> 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 <pgwipeout at gmail.com>
> > ---
> >  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
> >