[PATCH] rockchip: rk3576: Properly handle USB controller takeover from BootROM
Alexey Charkov
alchark at flipper.net
Fri May 8 10:21:23 CEST 2026
On Thu, May 7, 2026 at 8:48 PM Anton Burticica <mouse at ya.ru> wrote:
>
> The original idea was to _not_ disable USB3 OTG port when booted from USB:
>
> https://github.com/flipperdevices/u-boot/pull/20/changes
Hi Anton, thanks for the context!
It seems, however, that the minimal change out of your original pull
request which fixes the observed initialization issue is just the
assertion of the reset line. The rest may be helpful but is apparently
not directly relevant to what I'm trying to fix here - thus the
significantly trimmed down patch body compared to your original
version (one change at a time).
> There is a possibility that with already running analogue blocks, disabling the port will leave the controller in some weird state and it's not possible to fully reset it via exposed reset lanes without full SoC reset.
Could be. However, having a different initial hardware state by the
time the driver loads, depending on the original bootsource, sounds
like future pain.
The Linux driver(s) also seem to be able to properly reinitialize the
relevant hardware blocks regardless of where the boot ROM and U-boot
left them, so I don't think we are dealing with a case of
"unrecoverable weird state requiring full SoC reset". We just need to
figure out what we are missing here, out of the substantial difference
between the two codebases.
> To: "u-boot at lists.denx.de" <u-boot at lists.denx.de>;
> Cc: Tom Rini <trini at konsulko.com>, Simon Glass <sjg at chromium.org>, Philipp Tomsich <philipp.tomsich at vrull.eu>, Kever Yang <kever.yang at rock-chips.com>, Jonas Karlman <jonas at kwiboo.se>, Anton Burticica <mouse at ya.ru>, Alexey Charkov <alchark at flipper.net>;
> Subject: [PATCH] rockchip: rk3576: Properly handle USB controller takeover from BootROM;
> 15:53, April 27, 2026, Alexey Charkov <alchark at flipper.net>:
>
> 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(+)
[Please avoid top posting per mailing list etiquette, as that makes
tracing the context for your reply harder]
Best regards,
Alexey
More information about the U-Boot
mailing list