[BUG] USB boot issue on ROCKPro64 with UEFI
Hi U-Boot folks,
Hopefully this is the right way to report bugs. If not, please do not hesitate to let me know.
I am hitting an issue with U-Boot v2021.07 on the ROCKPro64, when booting Linux with UEFI from USB. The kernel EFI stub will hang:
EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map...
After tracking it down, it appears efi_exit_boot_services() is ultimately calling OHCI hc_reset(), which hangs at this line:
1804 if (ohci_readl(&ohci->regs->control) & OHCI_CTRL_IR) {
This seems to indicate reading the OHCI hardware control register cannot complete, which hints at a clocking issue.
Looking in more details at the clocks changes performed on the efi_exit_boot_services() path, a workaround is indeed to prevent the USB2PHY clocks from being disabled (see the patch following this e-mail).
I don't know enough about the RK3399 clock tree to fully understand what is going on here, and what would be a proper fix. Hopefully others will be able to continue from there.
Best regards,
Vincent Stehlé System Architect - Arm
Vincent Stehlé (1): clk: rk3399: do not disable the USB2PHY clk
drivers/clk/rockchip/clk_rk3399.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
When booting from USB with UEFI on the ROCKPro64, the Linux kernel EFI stub will hang in efi_exit_boot_services due to OHCI hc_reset accessing the hardware registers after the USB2PHY clocks have been disabled.
As a workaround, prevent the USB2PHY clocks from being disabled to repair the boot.
Signed-off-by: Vincent Stehlé vincent.stehle@arm.com ---
THIS IS A WORKAROUND PLEASE DO NOT APPLY!
drivers/clk/rockchip/clk_rk3399.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk_rk3399.c b/drivers/clk/rockchip/clk_rk3399.c index f8cbda44551..9cf7d26a026 100644 --- a/drivers/clk/rockchip/clk_rk3399.c +++ b/drivers/clk/rockchip/clk_rk3399.c @@ -1213,10 +1213,10 @@ static int rk3399_clk_disable(struct clk *clk) rk_setreg(&priv->cru->clkgate_con[5], BIT(6)); break; case SCLK_USB2PHY0_REF: - rk_setreg(&priv->cru->clkgate_con[6], BIT(5)); + /* WORKAROUND: leave enabled */ break; case SCLK_USB2PHY1_REF: - rk_setreg(&priv->cru->clkgate_con[6], BIT(6)); + /* WORKAROUND: leave enabled */ break; case ACLK_GMAC: rk_setreg(&priv->cru->clkgate_con[32], BIT(0));
Vincent Stehlé vincent.stehle@arm.com writes:
Hi,
Hi U-Boot folks,
Hopefully this is the right way to report bugs. If not, please do not hesitate to let me know.
I am hitting an issue with U-Boot v2021.07 on the ROCKPro64, when booting Linux with UEFI from USB. The kernel EFI stub will hang:
EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map...
After tracking it down, it appears efi_exit_boot_services() is ultimately calling OHCI hc_reset(), which hangs at this line:
1804 if (ohci_readl(&ohci->regs->control) & OHCI_CTRL_IR) {
This seems to indicate reading the OHCI hardware control register cannot complete, which hints at a clocking issue.
Looking in more details at the clocks changes performed on the efi_exit_boot_services() path, a workaround is indeed to prevent the USB2PHY clocks from being disabled (see the patch following this e-mail).
I don't know enough about the RK3399 clock tree to fully understand what is going on here, and what would be a proper fix. Hopefully others will be able to continue from there.
I may be wrong but seems like the issue solved by https://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-ic... Unfortunately, I think that there has been no progress since the submission of this patch.
Arnaud
On Fri, Sep 03, 2021 at 07:02:13PM +0200, Arnaud Patard wrote: ..
I may be wrong but seems like the issue solved by https://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-ic... Unfortunately, I think that there has been no progress since the submission of this patch.
Hi Arnaud,
You are right, this patch solves the issue I am seeing on the ROCKPro64. Thanks for the pointer.
Best regards,
Vincent Stehlé System Architect - Arm
participants (2)
-
Arnaud Patard -
Vincent Stehlé