Hi Alexey,
On 5/8/26 10:21 AM, Alexey Charkov wrote:
On Thu, May 7, 2026 at 8:48 PM Anton Burticica <[email protected]> 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.
There's an attempt at synchronizing the codebase with Linux v6.16-rc7,
see
https://lore.kernel.org/u-boot/[email protected]/.
Maybe this is something you could give a try and see if it makes things
behave any different?
Cheers,
Quentin
