[PATCH] rockchip: rk3576: Properly handle USB controller takeover from BootROM

[Alexey Charkov]

Hi Quentin,

On Mon, Apr 27, 2026 at 6:43 PM Quentin Schulz <quentin.schulz at cherry.de> wrote:
>
> Hi Alexey,
>
> On 4/27/26 2:53 PM, Alexey Charkov wrote:
> > From: Anton Burticica <mouse at ya.ru>
> >
> > When booting via USB download mode (Maskrom), the BootROM leaves the
> > USB3OTG0 controller in an active state. U-Boot must properly reset
> > the controller before reinitializing it for fastboot or other USB
> > gadget functions.
> >
> > Without this change, USB gadget mode commands such as fastboot and ums
> > fail when U-Boot is loaded via Maskrom USB download because the
> > controller state is inconsistent.
> >
> > Signed-off-by: Anton Burticica <mouse at ya.ru>
> > [Removed unrelated changes, adjusted the commit description]
> > Signed-off-by: Alexey Charkov <alchark at flipper.net>
> > ---
> >   arch/arm/mach-rockchip/rk3576/rk3576.c | 18 ++++++++++++++++++
> >   1 file changed, 18 insertions(+)
> >
> > diff --git a/arch/arm/mach-rockchip/rk3576/rk3576.c b/arch/arm/mach-rockchip/rk3576/rk3576.c
> > index c17ba418ced5..84618ad5acb7 100644
> > --- a/arch/arm/mach-rockchip/rk3576/rk3576.c
> > +++ b/arch/arm/mach-rockchip/rk3576/rk3576.c
> > @@ -7,6 +7,8 @@
> >
> >   #include <dm.h>
> >   #include <misc.h>
> > +#include <linux/bitops.h>
> > +#include <linux/delay.h>
> >   #include <asm/armv8/mmu.h>
> >   #include <asm/arch-rockchip/bootrom.h>
> >   #include <asm/arch-rockchip/hardware.h>
> > @@ -39,6 +41,10 @@
> >   #define USB_GRF_BASE                0x2601E000
> >   #define USB3OTG0_CON1               0x0030
> >
> > +#define TOP_CRU_BASE         0x27200000
> > +#define TOP_CRU_SOFTRST_CON47        0x0abc
> > +#define SOFTRST47_ARESETN_USB3OTG0   BIT(5)
> > +
> >   enum {
> >       BROM_BOOTSOURCE_FSPI0 = 3,
> >       BROM_BOOTSOURCE_FSPI1_M1 = 6,
> > @@ -189,6 +195,18 @@ int arch_cpu_init(void)
> >        */
> >       writel(0xffffff00, SYS_SGRF_BASE + SYS_SGRF_SOC_CON20);
> >
> > +     /* If the controller was left running by the boot ROM, reset it */
> > +     if (read_brom_bootsource_id() == BROM_BOOTSOURCE_USB) {
> > +             /* Assert USB3OTG0 reset */
> > +             writel(RK_SETBITS(SOFTRST47_ARESETN_USB3OTG0),
> > +                    TOP_CRU_BASE + TOP_CRU_SOFTRST_CON47);
> > +             udelay(1000);
> > +             /* De-assert USB3OTG0 reset */
> > +             writel(RK_CLRBITS(SOFTRST47_ARESETN_USB3OTG0),
> > +                    TOP_CRU_BASE + TOP_CRU_SOFTRST_CON47);
> > +             udelay(1000);
> > +     }
> > +
>
> Uh... Wouldn't the issue rather be that the U-Boot driver doesn't
> actually reset the device?
>
> Can you try with
>
> diff --git a/drivers/usb/dwc3/dwc3-generic.c
> b/drivers/usb/dwc3/dwc3-generic.c
> index 22b9ef0b24e..1b7d845bc75 100644
> --- a/drivers/usb/dwc3/dwc3-generic.c
> +++ b/drivers/usb/dwc3/dwc3-generic.c
> @@ -604,6 +604,9 @@ static int dwc3_glue_reset_init(struct udevice *dev,
>                  * have slower sleep clocks so we'll play it safe.
>                  */
>                 udelay(500);
> +       } else if (device_is_compatible(dev, "rockchip,rk3576-dwc3")) {
> +               reset_assert_bulk(&glue->resets);
> +               udelay(1000);
>         }
>         ret = reset_deassert_bulk(&glue->resets);
>         if (ret) {
>
> maybe? Hunch is that every variant of this driver actually needs to do
> this to avoid to rely on the device being out of reset already, but the
> delay is likely silicon-implementation-specific? The driver in the Linux
> kernel doesn't actually assert it either before deasserting it, so who
> knows. Adding Marek in Cc.

This snippet doesn't work unfortunately, I'm getting the following
(the same result as without any patches):

=> ums 0 mmc 0
UMS: LUN 0, dev mmc 0, hwpart 0, sector 0x0, count 0x3a63e00
rockchip_udphy phy at 2b010000: cmn ana lcpll lock timeout
rockchip_udphy phy at 2b010000: failed to init usbdp combophy
rockchip_udphy phy at 2b010000: PHY: Failed to init phy at 2b010000: -110.
rockchip_udphy phy at 2b010000: cmn ana lcpll lock timeout
rockchip_udphy phy at 2b010000: failed to init usbdp combophy
rockchip_udphy phy at 2b010000: PHY: Failed to init phy at 2b010000: -110.
No USB device found
Couldn't init USB controller.

> Otherwise, for sure we do not want to de-assert the signal in the rk3576
> SoC C file, we don't know if the driver is even built and we should let
> it do it if need be.

Indeed, dropping the de-assertion (or rather leaving it to the driver)
still gets it to work properly, thanks!

Best regards,
Alexey