> >
> >> Hello Fabio and Peter,
> >>
> >> I am suffering some strange behaviour in initializing the smtp reset
> >> block of the USB1 (host) in iMX28 running kernel 3.12.1 (vanilla) on
> >> my custom board based on iMX28EVK.
> >>
> >> With bootlets I DO NOT TOUCH any register to the USB PHY and family...
> >> With bootloader (barebox 2013-03) I do not initialize the usbcore,
> >> and the only stuff I set is the pinmux for USB_ID and USB_OC for both
> >> ports, but none used.
> >>
> >> In the device tree there are both declarations for usb-device role
> >> and usb-host role.
> >>
> >> Sometimes during cold-start or warm-start (due to a reset pressure,
> >> and/or a reboot command issued) the USB1 (host) is not configured
> >> because the function:
> >>
> >> stmp_reset_block() in the lib/stmp_device.c is exiting due to a TIMEOUT.
> >>
> >> The following code is executed correctly:
> >>
> >>> /* clear CLKGATE */
> >>> writel(STMP_MODULE_CLKGATE, reset_addr +
> STMP_OFFSET_REG_CLR);
> >>>
> >>> /* set SFTRST to reset the block */
> >>> writel(STMP_MODULE_SFTRST, reset_addr + STMP_OFFSET_REG_SET);
> >>> udelay(1);
> >>
> >> And now the problematic part:
> >>
> >>> /* poll CLKGATE becoming set */
> >>> while ((!(readl(reset_addr) & STMP_MODULE_CLKGATE)) && --
> timeout)
> >>> /* nothing */;
> >>> if (unlikely(!timeout
> >>
> >> it waits for 0x400 (timeout value counter) read access, then exit
> >> with a timeout. It looks like the HW_USBPHY_CTRL for USBPHY1
> >> (0x8007E030) has the following value: 0x80020000 (so no CLKGATE
> >> high...)
> >
> > It means the PHY works abnormal, would you please check the related
> > PLL is configured successfully?
> >
>
> I suppose yes, the PLL is configured in the right way (anyway I do not touch any
> known register neither in the linux kernel, neither in the barebox and/or
> bootlets), because the subsequent boots are running fine (at least the 90% of
> the times)
>
I mean check PLL configuration runtime and see if it is the reason.
Besides, if bootloader usb works ok with continual warm reset tests?
Peter
> Now as quick-and-dirty workaround I increased the timeout value to a
> 0x4000 (16 times the original), and it seems to be ok for the 95% of the times,
> but I do not know if it is the correct way to face and correct the problem.
>
> There are some code to be inserted into bootloader and/or bootlets to ensure
> a proper way to prepare the USB PHY clock PLL part so linux can initialize it
> correctly?
>
>
��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
