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

Peter Geis
2022-03-14T12:34:56Z

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