* [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-21 12:47 ` Andrey Smirnov
0 siblings, 0 replies; 48+ messages in thread
From: Andrey Smirnov @ 2018-06-21 12:47 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jun 20, 2018 at 3:22 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> On Wed, Jun 20, 2018 at 7:07 PM, Fabio Estevam <festevam@gmail.com> wrote:
>
> > This patches causes a regression on a imx51-babbage running 4.18-rc1:
> > I get a kernel hang.
> >
> > If I revert it on top of 4.18-rc1, then it boots fine and USB host is
> > functional.
> >
> > I understand this patch fixes a kernel hang for you, so which commit
> > is responsible for the hang you observe?
> >
I never assumed it was a regression and that USB worked on RDU1 board
before, so I never tried to see if this was a regression. I can only
tell you that it hangs as soon as any PORTSC registers are accessed.
> > It seems this commit fixes a hang for you and causes another hang for me :-)
> >
> > Any ideas?
>
RDU1 design is based heavily on Babbage board, moreso USB1/ULPI
portion of it is an exact copy (it does use different GPIO for PHY
reset, but that's irrelevant), so I am surprised that it breaks in
your case.
However looking at imx51-babbage.dts, I am suspicious of it's USB1
setup. There we have usbh1phy node that references <&gpio2 5
GPIO_ACTIVE_LOW> as reset, but corresponding pinmux, pinctrl_usbh1reg,
is not being used anywhere. Cold that be that the problem you are
seeing is due to USB PHY not being properly reset?
> I am able to boot again if I skip passing the CI_HDRC_OVERRIDE_PHY_CONTROL flag:
>
Yeah, IMHO if you are dropping that flag, you may as well revert the
whole patch :-). The path that make the kernel hang in my case would
be taken if that flag is dropped.
Thanks,
Andrey Smirnov
^ permalink raw reply [flat|nested] 48+ messages in thread
* usb: chipidea: Fix ULPI on imx51
@ 2018-06-21 12:47 ` Andrey Smirnov
0 siblings, 0 replies; 48+ messages in thread
From: Andrey Smirnov @ 2018-06-21 12:47 UTC (permalink / raw)
To: Fabio Estevam
Cc: Greg Kroah-Hartman, Nikita Yushchenko, Peter Chen, linux-usb,
linux-kernel, linux-arm-kernel, Fabio Estevam, Chris Healy,
Lucas Stach, Sebastian Reichel
On Wed, Jun 20, 2018 at 3:22 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> On Wed, Jun 20, 2018 at 7:07 PM, Fabio Estevam <festevam@gmail.com> wrote:
>
> > This patches causes a regression on a imx51-babbage running 4.18-rc1:
> > I get a kernel hang.
> >
> > If I revert it on top of 4.18-rc1, then it boots fine and USB host is
> > functional.
> >
> > I understand this patch fixes a kernel hang for you, so which commit
> > is responsible for the hang you observe?
> >
I never assumed it was a regression and that USB worked on RDU1 board
before, so I never tried to see if this was a regression. I can only
tell you that it hangs as soon as any PORTSC registers are accessed.
> > It seems this commit fixes a hang for you and causes another hang for me :-)
> >
> > Any ideas?
>
RDU1 design is based heavily on Babbage board, moreso USB1/ULPI
portion of it is an exact copy (it does use different GPIO for PHY
reset, but that's irrelevant), so I am surprised that it breaks in
your case.
However looking at imx51-babbage.dts, I am suspicious of it's USB1
setup. There we have usbh1phy node that references <&gpio2 5
GPIO_ACTIVE_LOW> as reset, but corresponding pinmux, pinctrl_usbh1reg,
is not being used anywhere. Cold that be that the problem you are
seeing is due to USB PHY not being properly reset?
> I am able to boot again if I skip passing the CI_HDRC_OVERRIDE_PHY_CONTROL flag:
>
Yeah, IMHO if you are dropping that flag, you may as well revert the
whole patch :-). The path that make the kernel hang in my case would
be taken if that flag is dropped.
Thanks,
Andrey Smirnov
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-21 14:08 ` Fabio Estevam
0 siblings, 0 replies; 48+ messages in thread
From: Fabio Estevam @ 2018-06-21 14:08 UTC (permalink / raw)
To: Andrey Smirnov
Cc: Greg Kroah-Hartman, Nikita Yushchenko, Peter Chen, USB list,
linux-kernel, linux-arm-kernel, Fabio Estevam, Chris Healy,
Lucas Stach, Sebastian Reichel
Hi Andrey,
On Thu, Jun 21, 2018 at 9:47 AM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> I never assumed it was a regression and that USB worked on RDU1 board
> before, so I never tried to see if this was a regression. I can only
> tell you that it hangs as soon as any PORTSC registers are accessed.
I think we need to investigate this portsc register hang further.
> RDU1 design is based heavily on Babbage board, moreso USB1/ULPI
> portion of it is an exact copy (it does use different GPIO for PHY
> reset, but that's irrelevant), so I am surprised that it breaks in
> your case.
>
> However looking at imx51-babbage.dts, I am suspicious of it's USB1
> setup. There we have usbh1phy node that references <&gpio2 5
> GPIO_ACTIVE_LOW> as reset, but corresponding pinmux, pinctrl_usbh1reg,
> is not being used anywhere. Cold that be that the problem you are
> seeing is due to USB PHY not being properly reset?
Yes, this can be improved, but this is not the cause of the issue .
gpio2 5 is passed as the USB PHY reset:
reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
The default IOMUX setting after power on reset is GPIO, so not an issue.
> Yeah, IMHO if you are dropping that flag, you may as well revert the
> whole patch :-). The path that make the kernel hang in my case would
> be taken if that flag is dropped.
Yes, it seems we need to revert the full patch and have a proper fix
in place that works for imx51 RDU, imx53-ppd and imx51 babbage.
The USB host 1 on imx51-babbage has been working since kernel 3.19 :-)
Thanks
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-21 14:08 ` Fabio Estevam
0 siblings, 0 replies; 48+ messages in thread
From: Fabio Estevam @ 2018-06-21 14:08 UTC (permalink / raw)
To: linux-arm-kernel
Hi Andrey,
On Thu, Jun 21, 2018 at 9:47 AM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> I never assumed it was a regression and that USB worked on RDU1 board
> before, so I never tried to see if this was a regression. I can only
> tell you that it hangs as soon as any PORTSC registers are accessed.
I think we need to investigate this portsc register hang further.
> RDU1 design is based heavily on Babbage board, moreso USB1/ULPI
> portion of it is an exact copy (it does use different GPIO for PHY
> reset, but that's irrelevant), so I am surprised that it breaks in
> your case.
>
> However looking at imx51-babbage.dts, I am suspicious of it's USB1
> setup. There we have usbh1phy node that references <&gpio2 5
> GPIO_ACTIVE_LOW> as reset, but corresponding pinmux, pinctrl_usbh1reg,
> is not being used anywhere. Cold that be that the problem you are
> seeing is due to USB PHY not being properly reset?
Yes, this can be improved, but this is not the cause of the issue .
gpio2 5 is passed as the USB PHY reset:
reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
The default IOMUX setting after power on reset is GPIO, so not an issue.
> Yeah, IMHO if you are dropping that flag, you may as well revert the
> whole patch :-). The path that make the kernel hang in my case would
> be taken if that flag is dropped.
Yes, it seems we need to revert the full patch and have a proper fix
in place that works for imx51 RDU, imx53-ppd and imx51 babbage.
The USB host 1 on imx51-babbage has been working since kernel 3.19 :-)
Thanks
^ permalink raw reply [flat|nested] 48+ messages in thread
* usb: chipidea: Fix ULPI on imx51
@ 2018-06-21 14:08 ` Fabio Estevam
0 siblings, 0 replies; 48+ messages in thread
From: Fabio Estevam @ 2018-06-21 14:08 UTC (permalink / raw)
To: Andrey Smirnov
Cc: Greg Kroah-Hartman, Nikita Yushchenko, Peter Chen, USB list,
linux-kernel, linux-arm-kernel, Fabio Estevam, Chris Healy,
Lucas Stach, Sebastian Reichel
Hi Andrey,
On Thu, Jun 21, 2018 at 9:47 AM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> I never assumed it was a regression and that USB worked on RDU1 board
> before, so I never tried to see if this was a regression. I can only
> tell you that it hangs as soon as any PORTSC registers are accessed.
I think we need to investigate this portsc register hang further.
> RDU1 design is based heavily on Babbage board, moreso USB1/ULPI
> portion of it is an exact copy (it does use different GPIO for PHY
> reset, but that's irrelevant), so I am surprised that it breaks in
> your case.
>
> However looking at imx51-babbage.dts, I am suspicious of it's USB1
> setup. There we have usbh1phy node that references <&gpio2 5
> GPIO_ACTIVE_LOW> as reset, but corresponding pinmux, pinctrl_usbh1reg,
> is not being used anywhere. Cold that be that the problem you are
> seeing is due to USB PHY not being properly reset?
Yes, this can be improved, but this is not the cause of the issue .
gpio2 5 is passed as the USB PHY reset:
reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
The default IOMUX setting after power on reset is GPIO, so not an issue.
> Yeah, IMHO if you are dropping that flag, you may as well revert the
> whole patch :-). The path that make the kernel hang in my case would
> be taken if that flag is dropped.
Yes, it seems we need to revert the full patch and have a proper fix
in place that works for imx51 RDU, imx53-ppd and imx51 babbage.
The USB host 1 on imx51-babbage has been working since kernel 3.19 :-)
Thanks
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-21 21:44 ` Andrey Smirnov
0 siblings, 0 replies; 48+ messages in thread
From: Andrey Smirnov @ 2018-06-21 21:44 UTC (permalink / raw)
To: Fabio Estevam
Cc: Greg Kroah-Hartman, Nikita Yushchenko, Peter Chen, linux-usb,
linux-kernel, linux-arm-kernel, Fabio Estevam, Chris Healy,
Lucas Stach, Sebastian Reichel
On Thu, Jun 21, 2018 at 7:08 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Andrey,
>
> On Thu, Jun 21, 2018 at 9:47 AM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>
> > I never assumed it was a regression and that USB worked on RDU1 board
> > before, so I never tried to see if this was a regression. I can only
> > tell you that it hangs as soon as any PORTSC registers are accessed.
>
> I think we need to investigate this portsc register hang further.
>
I just finished experimenting with it on RDU1 and Babbage boards and I
can't reproduce the hang that you describe against 4.18-rc1. At this
point I wonder if it's the bootloader that is a variable that plays
into this. I was booting both boards with 2018.06.0 version of barebox
+ the custom patches that can be found here
https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
last patch in that branch/stack was added as a part of this
investigation, but even before it, I was able to boot Linux just fine,
albeit without working USB.
Any chance you can try it on your end and see if that makes a difference?
Thanks,
Andrey Smirnov
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-21 21:44 ` Andrey Smirnov
0 siblings, 0 replies; 48+ messages in thread
From: Andrey Smirnov @ 2018-06-21 21:44 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jun 21, 2018 at 7:08 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Andrey,
>
> On Thu, Jun 21, 2018 at 9:47 AM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>
> > I never assumed it was a regression and that USB worked on RDU1 board
> > before, so I never tried to see if this was a regression. I can only
> > tell you that it hangs as soon as any PORTSC registers are accessed.
>
> I think we need to investigate this portsc register hang further.
>
I just finished experimenting with it on RDU1 and Babbage boards and I
can't reproduce the hang that you describe against 4.18-rc1. At this
point I wonder if it's the bootloader that is a variable that plays
into this. I was booting both boards with 2018.06.0 version of barebox
+ the custom patches that can be found here
https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
last patch in that branch/stack was added as a part of this
investigation, but even before it, I was able to boot Linux just fine,
albeit without working USB.
Any chance you can try it on your end and see if that makes a difference?
Thanks,
Andrey Smirnov
^ permalink raw reply [flat|nested] 48+ messages in thread
* usb: chipidea: Fix ULPI on imx51
@ 2018-06-21 21:44 ` Andrey Smirnov
0 siblings, 0 replies; 48+ messages in thread
From: Andrey Smirnov @ 2018-06-21 21:44 UTC (permalink / raw)
To: Fabio Estevam
Cc: Greg Kroah-Hartman, Nikita Yushchenko, Peter Chen, linux-usb,
linux-kernel, linux-arm-kernel, Fabio Estevam, Chris Healy,
Lucas Stach, Sebastian Reichel
On Thu, Jun 21, 2018 at 7:08 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Andrey,
>
> On Thu, Jun 21, 2018 at 9:47 AM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>
> > I never assumed it was a regression and that USB worked on RDU1 board
> > before, so I never tried to see if this was a regression. I can only
> > tell you that it hangs as soon as any PORTSC registers are accessed.
>
> I think we need to investigate this portsc register hang further.
>
I just finished experimenting with it on RDU1 and Babbage boards and I
can't reproduce the hang that you describe against 4.18-rc1. At this
point I wonder if it's the bootloader that is a variable that plays
into this. I was booting both boards with 2018.06.0 version of barebox
+ the custom patches that can be found here
https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
last patch in that branch/stack was added as a part of this
investigation, but even before it, I was able to boot Linux just fine,
albeit without working USB.
Any chance you can try it on your end and see if that makes a difference?
Thanks,
Andrey Smirnov
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-22 16:27 ` Fabio Estevam
0 siblings, 0 replies; 48+ messages in thread
From: Fabio Estevam @ 2018-06-22 16:27 UTC (permalink / raw)
To: Andrey Smirnov
Cc: Greg Kroah-Hartman, Nikita Yushchenko, Peter Chen, USB list,
linux-kernel, linux-arm-kernel, Fabio Estevam, Chris Healy,
Lucas Stach, Sebastian Reichel
Hi Andrey,
On Thu, Jun 21, 2018 at 6:44 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> I just finished experimenting with it on RDU1 and Babbage boards and I
> can't reproduce the hang that you describe against 4.18-rc1. At this
> point I wonder if it's the bootloader that is a variable that plays
> into this. I was booting both boards with 2018.06.0 version of barebox
> + the custom patches that can be found here
> https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
> last patch in that branch/stack was added as a part of this
> investigation, but even before it, I was able to boot Linux just fine,
> albeit without working USB.
Thanks for investigating this issue.
Yes, t is possible that the difference in behaviour that we see could
be related to the fact we use different bootloaders.
In order to make things easier, I am sharing a Buildroot image for
imx51-babbage that contains U-Boot 2018.05 + kernel 4.17.2:
https://www.dropbox.com/s/yevnu4y1zdchnbt/sdcard.img?dl=0
Please flash it directly to the SD card via dd and boot it.
You will notice that it will boot normally. Then please copy a
4.18-rc1 zImage into the first SD card partition and you will notice
the hang.
Thanks
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-22 16:27 ` Fabio Estevam
0 siblings, 0 replies; 48+ messages in thread
From: Fabio Estevam @ 2018-06-22 16:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi Andrey,
On Thu, Jun 21, 2018 at 6:44 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> I just finished experimenting with it on RDU1 and Babbage boards and I
> can't reproduce the hang that you describe against 4.18-rc1. At this
> point I wonder if it's the bootloader that is a variable that plays
> into this. I was booting both boards with 2018.06.0 version of barebox
> + the custom patches that can be found here
> https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
> last patch in that branch/stack was added as a part of this
> investigation, but even before it, I was able to boot Linux just fine,
> albeit without working USB.
Thanks for investigating this issue.
Yes, t is possible that the difference in behaviour that we see could
be related to the fact we use different bootloaders.
In order to make things easier, I am sharing a Buildroot image for
imx51-babbage that contains U-Boot 2018.05 + kernel 4.17.2:
https://www.dropbox.com/s/yevnu4y1zdchnbt/sdcard.img?dl=0
Please flash it directly to the SD card via dd and boot it.
You will notice that it will boot normally. Then please copy a
4.18-rc1 zImage into the first SD card partition and you will notice
the hang.
Thanks
^ permalink raw reply [flat|nested] 48+ messages in thread
* usb: chipidea: Fix ULPI on imx51
@ 2018-06-22 16:27 ` Fabio Estevam
0 siblings, 0 replies; 48+ messages in thread
From: Fabio Estevam @ 2018-06-22 16:27 UTC (permalink / raw)
To: Andrey Smirnov
Cc: Greg Kroah-Hartman, Nikita Yushchenko, Peter Chen, USB list,
linux-kernel, linux-arm-kernel, Fabio Estevam, Chris Healy,
Lucas Stach, Sebastian Reichel
Hi Andrey,
On Thu, Jun 21, 2018 at 6:44 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> I just finished experimenting with it on RDU1 and Babbage boards and I
> can't reproduce the hang that you describe against 4.18-rc1. At this
> point I wonder if it's the bootloader that is a variable that plays
> into this. I was booting both boards with 2018.06.0 version of barebox
> + the custom patches that can be found here
> https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
> last patch in that branch/stack was added as a part of this
> investigation, but even before it, I was able to boot Linux just fine,
> albeit without working USB.
Thanks for investigating this issue.
Yes, t is possible that the difference in behaviour that we see could
be related to the fact we use different bootloaders.
In order to make things easier, I am sharing a Buildroot image for
imx51-babbage that contains U-Boot 2018.05 + kernel 4.17.2:
https://www.dropbox.com/s/yevnu4y1zdchnbt/sdcard.img?dl=0
Please flash it directly to the SD card via dd and boot it.
You will notice that it will boot normally. Then please copy a
4.18-rc1 zImage into the first SD card partition and you will notice
the hang.
Thanks
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-24 22:40 ` Andrey Smirnov
0 siblings, 0 replies; 48+ messages in thread
From: Andrey Smirnov @ 2018-06-24 22:40 UTC (permalink / raw)
To: Fabio Estevam
Cc: Greg Kroah-Hartman, Nikita Yushchenko, Peter Chen, linux-usb,
linux-kernel, linux-arm-kernel, Fabio Estevam, Chris Healy,
Lucas Stach, Sebastian Reichel
On Fri, Jun 22, 2018 at 9:27 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Andrey,
>
> On Thu, Jun 21, 2018 at 6:44 PM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>
> > I just finished experimenting with it on RDU1 and Babbage boards and I
> > can't reproduce the hang that you describe against 4.18-rc1. At this
> > point I wonder if it's the bootloader that is a variable that plays
> > into this. I was booting both boards with 2018.06.0 version of barebox
> > + the custom patches that can be found here
> > https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
> > last patch in that branch/stack was added as a part of this
> > investigation, but even before it, I was able to boot Linux just fine,
> > albeit without working USB.
>
> Thanks for investigating this issue.
>
> Yes, t is possible that the difference in behaviour that we see could
> be related to the fact we use different bootloaders.
>
> In order to make things easier, I am sharing a Buildroot image for
> imx51-babbage that contains U-Boot 2018.05 + kernel 4.17.2:
> https://www.dropbox.com/s/yevnu4y1zdchnbt/sdcard.img?dl=0
>
> Please flash it directly to the SD card via dd and boot it.
>
> You will notice that it will boot normally. Then please copy a
> 4.18-rc1 zImage into the first SD card partition and you will notice
> the hang.
>
It's definitely the bootloader, or more specifically whether or not it
initialized/used USB before booting the kernel. Some interesting
highlights:
- On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb
start" (optionally "usb stop") and then "boot", you'll get the hang
that I was trying to fix with my patch.
- Things are exact opposite with 4.18-rc1 and doing the above would
_prevent_ the hang and the image would boot fine.
- Disabling USB in Barebox based boot "stack" gets it to behave the
same way as U-boot from your image (hanging when booting 4.18-rc1)
Digging more into code it seems that the reason for 4.18-rc1's
behavior is the fact that it's missing a call hw_phymode_configure()
after usb_phy_init() and, AFAICT, the only reason it is not happening
is because default image is being built without
CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two
options on 4.18-rc1, seem to fix the problem on both your U-Boot based
image and my "special" Barebox setup.
So AFAICT, this patch still fixes a valid issue (my use-case was net
booting via USB-Ethernet dongle), but an additional patch enabling
those two configuration options might be needed. Thoughts?
Also, I don't have any i.MX53 HW, so I wasn't able to test the effects
of enabling those two options there.
Thanks,
Andrey Smirnov
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-24 22:40 ` Andrey Smirnov
0 siblings, 0 replies; 48+ messages in thread
From: Andrey Smirnov @ 2018-06-24 22:40 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jun 22, 2018 at 9:27 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Andrey,
>
> On Thu, Jun 21, 2018 at 6:44 PM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>
> > I just finished experimenting with it on RDU1 and Babbage boards and I
> > can't reproduce the hang that you describe against 4.18-rc1. At this
> > point I wonder if it's the bootloader that is a variable that plays
> > into this. I was booting both boards with 2018.06.0 version of barebox
> > + the custom patches that can be found here
> > https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
> > last patch in that branch/stack was added as a part of this
> > investigation, but even before it, I was able to boot Linux just fine,
> > albeit without working USB.
>
> Thanks for investigating this issue.
>
> Yes, t is possible that the difference in behaviour that we see could
> be related to the fact we use different bootloaders.
>
> In order to make things easier, I am sharing a Buildroot image for
> imx51-babbage that contains U-Boot 2018.05 + kernel 4.17.2:
> https://www.dropbox.com/s/yevnu4y1zdchnbt/sdcard.img?dl=0
>
> Please flash it directly to the SD card via dd and boot it.
>
> You will notice that it will boot normally. Then please copy a
> 4.18-rc1 zImage into the first SD card partition and you will notice
> the hang.
>
It's definitely the bootloader, or more specifically whether or not it
initialized/used USB before booting the kernel. Some interesting
highlights:
- On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb
start" (optionally "usb stop") and then "boot", you'll get the hang
that I was trying to fix with my patch.
- Things are exact opposite with 4.18-rc1 and doing the above would
_prevent_ the hang and the image would boot fine.
- Disabling USB in Barebox based boot "stack" gets it to behave the
same way as U-boot from your image (hanging when booting 4.18-rc1)
Digging more into code it seems that the reason for 4.18-rc1's
behavior is the fact that it's missing a call hw_phymode_configure()
after usb_phy_init() and, AFAICT, the only reason it is not happening
is because default image is being built without
CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two
options on 4.18-rc1, seem to fix the problem on both your U-Boot based
image and my "special" Barebox setup.
So AFAICT, this patch still fixes a valid issue (my use-case was net
booting via USB-Ethernet dongle), but an additional patch enabling
those two configuration options might be needed. Thoughts?
Also, I don't have any i.MX53 HW, so I wasn't able to test the effects
of enabling those two options there.
Thanks,
Andrey Smirnov
^ permalink raw reply [flat|nested] 48+ messages in thread
* usb: chipidea: Fix ULPI on imx51
@ 2018-06-24 22:40 ` Andrey Smirnov
0 siblings, 0 replies; 48+ messages in thread
From: Andrey Smirnov @ 2018-06-24 22:40 UTC (permalink / raw)
To: Fabio Estevam
Cc: Greg Kroah-Hartman, Nikita Yushchenko, Peter Chen, linux-usb,
linux-kernel, linux-arm-kernel, Fabio Estevam, Chris Healy,
Lucas Stach, Sebastian Reichel
On Fri, Jun 22, 2018 at 9:27 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Andrey,
>
> On Thu, Jun 21, 2018 at 6:44 PM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>
> > I just finished experimenting with it on RDU1 and Babbage boards and I
> > can't reproduce the hang that you describe against 4.18-rc1. At this
> > point I wonder if it's the bootloader that is a variable that plays
> > into this. I was booting both boards with 2018.06.0 version of barebox
> > + the custom patches that can be found here
> > https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the
> > last patch in that branch/stack was added as a part of this
> > investigation, but even before it, I was able to boot Linux just fine,
> > albeit without working USB.
>
> Thanks for investigating this issue.
>
> Yes, t is possible that the difference in behaviour that we see could
> be related to the fact we use different bootloaders.
>
> In order to make things easier, I am sharing a Buildroot image for
> imx51-babbage that contains U-Boot 2018.05 + kernel 4.17.2:
> https://www.dropbox.com/s/yevnu4y1zdchnbt/sdcard.img?dl=0
>
> Please flash it directly to the SD card via dd and boot it.
>
> You will notice that it will boot normally. Then please copy a
> 4.18-rc1 zImage into the first SD card partition and you will notice
> the hang.
>
It's definitely the bootloader, or more specifically whether or not it
initialized/used USB before booting the kernel. Some interesting
highlights:
- On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb
start" (optionally "usb stop") and then "boot", you'll get the hang
that I was trying to fix with my patch.
- Things are exact opposite with 4.18-rc1 and doing the above would
_prevent_ the hang and the image would boot fine.
- Disabling USB in Barebox based boot "stack" gets it to behave the
same way as U-boot from your image (hanging when booting 4.18-rc1)
Digging more into code it seems that the reason for 4.18-rc1's
behavior is the fact that it's missing a call hw_phymode_configure()
after usb_phy_init() and, AFAICT, the only reason it is not happening
is because default image is being built without
CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two
options on 4.18-rc1, seem to fix the problem on both your U-Boot based
image and my "special" Barebox setup.
So AFAICT, this patch still fixes a valid issue (my use-case was net
booting via USB-Ethernet dongle), but an additional patch enabling
those two configuration options might be needed. Thoughts?
Also, I don't have any i.MX53 HW, so I wasn't able to test the effects
of enabling those two options there.
Thanks,
Andrey Smirnov
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-24 23:51 ` Fabio Estevam
0 siblings, 0 replies; 48+ messages in thread
From: Fabio Estevam @ 2018-06-24 23:51 UTC (permalink / raw)
To: Andrey Smirnov
Cc: Greg Kroah-Hartman, Nikita Yushchenko, Peter Chen, USB list,
linux-kernel, linux-arm-kernel, Fabio Estevam, Chris Healy,
Lucas Stach, Sebastian Reichel
Hi Andrey,
On Sun, Jun 24, 2018 at 7:40 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> It's definitely the bootloader, or more specifically whether or not it
> initialized/used USB before booting the kernel. Some interesting
> highlights:
>
> - On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb
> start" (optionally "usb stop") and then "boot", you'll get the hang
> that I was trying to fix with my patch.
>
> - Things are exact opposite with 4.18-rc1 and doing the above would
> _prevent_ the hang and the image would boot fine.
>
> - Disabling USB in Barebox based boot "stack" gets it to behave the
> same way as U-boot from your image (hanging when booting 4.18-rc1)
>
> Digging more into code it seems that the reason for 4.18-rc1's
> behavior is the fact that it's missing a call hw_phymode_configure()
> after usb_phy_init() and, AFAICT, the only reason it is not happening
> is because default image is being built without
> CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two
> options on 4.18-rc1, seem to fix the problem on both your U-Boot based
> image and my "special" Barebox setup.
>
> So AFAICT, this patch still fixes a valid issue (my use-case was net
> booting via USB-Ethernet dongle), but an additional patch enabling
> those two configuration options might be needed. Thoughts?
Yes, I can confirm that your suggested change avoids the kernel hang:
diff --git a/arch/arm/configs/imx_v6_v7_defconfig
b/arch/arm/configs/imx_v6_v7_defconfig
index d14de86..2da678c 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -300,6 +300,7 @@ CONFIG_USB_STORAGE=y
CONFIG_USB_CHIPIDEA=y
CONFIG_USB_CHIPIDEA_UDC=y
CONFIG_USB_CHIPIDEA_HOST=y
+CONFIG_USB_CHIPIDEA_ULPI=y
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_FTDI_SIO=m
@@ -336,6 +337,7 @@ CONFIG_USB_GADGETFS=m
CONFIG_USB_FUNCTIONFS=m
CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
+CONFIG_USB_ULPI_BUS=y
CONFIG_MMC=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
> Also, I don't have any i.MX53 HW, so I wasn't able to test the effects
> of enabling those two options there.
The imx53 board I have access to does not use ULPI.
Maybe Sebastian on Cc may help testing this on his imx53 board as he
is the author of:
be9cae2479f48 ("usb: chipidea: imx: Fix ULPI on imx53")
I am wondering if we need to force some kind of USB reset to put the
USB controller into a known state independently of what the bootloader
has done previously.
Thanks
^ permalink raw reply related [flat|nested] 48+ messages in thread* [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-24 23:51 ` Fabio Estevam
0 siblings, 0 replies; 48+ messages in thread
From: Fabio Estevam @ 2018-06-24 23:51 UTC (permalink / raw)
To: linux-arm-kernel
Hi Andrey,
On Sun, Jun 24, 2018 at 7:40 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> It's definitely the bootloader, or more specifically whether or not it
> initialized/used USB before booting the kernel. Some interesting
> highlights:
>
> - On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb
> start" (optionally "usb stop") and then "boot", you'll get the hang
> that I was trying to fix with my patch.
>
> - Things are exact opposite with 4.18-rc1 and doing the above would
> _prevent_ the hang and the image would boot fine.
>
> - Disabling USB in Barebox based boot "stack" gets it to behave the
> same way as U-boot from your image (hanging when booting 4.18-rc1)
>
> Digging more into code it seems that the reason for 4.18-rc1's
> behavior is the fact that it's missing a call hw_phymode_configure()
> after usb_phy_init() and, AFAICT, the only reason it is not happening
> is because default image is being built without
> CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two
> options on 4.18-rc1, seem to fix the problem on both your U-Boot based
> image and my "special" Barebox setup.
>
> So AFAICT, this patch still fixes a valid issue (my use-case was net
> booting via USB-Ethernet dongle), but an additional patch enabling
> those two configuration options might be needed. Thoughts?
Yes, I can confirm that your suggested change avoids the kernel hang:
diff --git a/arch/arm/configs/imx_v6_v7_defconfig
b/arch/arm/configs/imx_v6_v7_defconfig
index d14de86..2da678c 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -300,6 +300,7 @@ CONFIG_USB_STORAGE=y
CONFIG_USB_CHIPIDEA=y
CONFIG_USB_CHIPIDEA_UDC=y
CONFIG_USB_CHIPIDEA_HOST=y
+CONFIG_USB_CHIPIDEA_ULPI=y
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_FTDI_SIO=m
@@ -336,6 +337,7 @@ CONFIG_USB_GADGETFS=m
CONFIG_USB_FUNCTIONFS=m
CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
+CONFIG_USB_ULPI_BUS=y
CONFIG_MMC=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
> Also, I don't have any i.MX53 HW, so I wasn't able to test the effects
> of enabling those two options there.
The imx53 board I have access to does not use ULPI.
Maybe Sebastian on Cc may help testing this on his imx53 board as he
is the author of:
be9cae2479f48 ("usb: chipidea: imx: Fix ULPI on imx53")
I am wondering if we need to force some kind of USB reset to put the
USB controller into a known state independently of what the bootloader
has done previously.
Thanks
^ permalink raw reply related [flat|nested] 48+ messages in thread* usb: chipidea: Fix ULPI on imx51
@ 2018-06-24 23:51 ` Fabio Estevam
0 siblings, 0 replies; 48+ messages in thread
From: Fabio Estevam @ 2018-06-24 23:51 UTC (permalink / raw)
To: Andrey Smirnov
Cc: Greg Kroah-Hartman, Nikita Yushchenko, Peter Chen, USB list,
linux-kernel, linux-arm-kernel, Fabio Estevam, Chris Healy,
Lucas Stach, Sebastian Reichel
Hi Andrey,
On Sun, Jun 24, 2018 at 7:40 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> It's definitely the bootloader, or more specifically whether or not it
> initialized/used USB before booting the kernel. Some interesting
> highlights:
>
> - On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb
> start" (optionally "usb stop") and then "boot", you'll get the hang
> that I was trying to fix with my patch.
>
> - Things are exact opposite with 4.18-rc1 and doing the above would
> _prevent_ the hang and the image would boot fine.
>
> - Disabling USB in Barebox based boot "stack" gets it to behave the
> same way as U-boot from your image (hanging when booting 4.18-rc1)
>
> Digging more into code it seems that the reason for 4.18-rc1's
> behavior is the fact that it's missing a call hw_phymode_configure()
> after usb_phy_init() and, AFAICT, the only reason it is not happening
> is because default image is being built without
> CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two
> options on 4.18-rc1, seem to fix the problem on both your U-Boot based
> image and my "special" Barebox setup.
>
> So AFAICT, this patch still fixes a valid issue (my use-case was net
> booting via USB-Ethernet dongle), but an additional patch enabling
> those two configuration options might be needed. Thoughts?
Yes, I can confirm that your suggested change avoids the kernel hang:
> Also, I don't have any i.MX53 HW, so I wasn't able to test the effects
> of enabling those two options there.
The imx53 board I have access to does not use ULPI.
Maybe Sebastian on Cc may help testing this on his imx53 board as he
is the author of:
be9cae2479f48 ("usb: chipidea: imx: Fix ULPI on imx53")
I am wondering if we need to force some kind of USB reset to put the
USB controller into a known state independently of what the bootloader
has done previously.
Thanks
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/configs/imx_v6_v7_defconfig
b/arch/arm/configs/imx_v6_v7_defconfig
index d14de86..2da678c 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -300,6 +300,7 @@ CONFIG_USB_STORAGE=y
CONFIG_USB_CHIPIDEA=y
CONFIG_USB_CHIPIDEA_UDC=y
CONFIG_USB_CHIPIDEA_HOST=y
+CONFIG_USB_CHIPIDEA_ULPI=y
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_FTDI_SIO=m
@@ -336,6 +337,7 @@ CONFIG_USB_GADGETFS=m
CONFIG_USB_FUNCTIONFS=m
CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
+CONFIG_USB_ULPI_BUS=y
CONFIG_MMC=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
^ permalink raw reply related [flat|nested] 48+ messages in thread* Re: [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-25 12:18 ` Sebastian Reichel
0 siblings, 0 replies; 48+ messages in thread
From: Sebastian Reichel @ 2018-06-25 12:18 UTC (permalink / raw)
To: Fabio Estevam
Cc: Andrey Smirnov, Greg Kroah-Hartman, Nikita Yushchenko,
Peter Chen, USB list, linux-kernel, linux-arm-kernel,
Fabio Estevam, Chris Healy, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 3068 bytes --]
Hi,
On Sun, Jun 24, 2018 at 08:51:20PM -0300, Fabio Estevam wrote:
> Hi Andrey,
>
> On Sun, Jun 24, 2018 at 7:40 PM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>
> > It's definitely the bootloader, or more specifically whether or not it
> > initialized/used USB before booting the kernel. Some interesting
> > highlights:
> >
> > - On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb
> > start" (optionally "usb stop") and then "boot", you'll get the hang
> > that I was trying to fix with my patch.
> >
> > - Things are exact opposite with 4.18-rc1 and doing the above would
> > _prevent_ the hang and the image would boot fine.
> >
> > - Disabling USB in Barebox based boot "stack" gets it to behave the
> > same way as U-boot from your image (hanging when booting 4.18-rc1)
> >
> > Digging more into code it seems that the reason for 4.18-rc1's
> > behavior is the fact that it's missing a call hw_phymode_configure()
> > after usb_phy_init() and, AFAICT, the only reason it is not happening
> > is because default image is being built without
> > CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two
> > options on 4.18-rc1, seem to fix the problem on both your U-Boot based
> > image and my "special" Barebox setup.
> >
> > So AFAICT, this patch still fixes a valid issue (my use-case was net
> > booting via USB-Ethernet dongle), but an additional patch enabling
> > those two configuration options might be needed. Thoughts?
>
> Yes, I can confirm that your suggested change avoids the kernel hang:
>
> diff --git a/arch/arm/configs/imx_v6_v7_defconfig
> b/arch/arm/configs/imx_v6_v7_defconfig
> index d14de86..2da678c 100644
> --- a/arch/arm/configs/imx_v6_v7_defconfig
> +++ b/arch/arm/configs/imx_v6_v7_defconfig
> @@ -300,6 +300,7 @@ CONFIG_USB_STORAGE=y
> CONFIG_USB_CHIPIDEA=y
> CONFIG_USB_CHIPIDEA_UDC=y
> CONFIG_USB_CHIPIDEA_HOST=y
> +CONFIG_USB_CHIPIDEA_ULPI=y
> CONFIG_USB_SERIAL=m
> CONFIG_USB_SERIAL_GENERIC=y
> CONFIG_USB_SERIAL_FTDI_SIO=m
> @@ -336,6 +337,7 @@ CONFIG_USB_GADGETFS=m
> CONFIG_USB_FUNCTIONFS=m
> CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> +CONFIG_USB_ULPI_BUS=y
> CONFIG_MMC=y
> CONFIG_MMC_SDHCI=y
> CONFIG_MMC_SDHCI_PLTFM=y
>
> > Also, I don't have any i.MX53 HW, so I wasn't able to test the effects
> > of enabling those two options there.
>
> The imx53 board I have access to does not use ULPI.
>
> Maybe Sebastian on Cc may help testing this on his imx53 board as he
> is the author of:
> be9cae2479f48 ("usb: chipidea: imx: Fix ULPI on imx53")
I still have access to the imx53 based PPD from General Electric.
But I don't understand what patch you want me to test. FWIW the
images I use(d) for testing already had CONFIG_USB_CHIPIDEA_ULPI
and CONFIG_USB_ULPI_BUS enabled.
> I am wondering if we need to force some kind of USB reset to put the
> USB controller into a known state independently of what the bootloader
> has done previously.
Makes sense to me.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 48+ messages in thread* [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-25 12:18 ` Sebastian Reichel
0 siblings, 0 replies; 48+ messages in thread
From: Sebastian Reichel @ 2018-06-25 12:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Sun, Jun 24, 2018 at 08:51:20PM -0300, Fabio Estevam wrote:
> Hi Andrey,
>
> On Sun, Jun 24, 2018 at 7:40 PM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>
> > It's definitely the bootloader, or more specifically whether or not it
> > initialized/used USB before booting the kernel. Some interesting
> > highlights:
> >
> > - On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb
> > start" (optionally "usb stop") and then "boot", you'll get the hang
> > that I was trying to fix with my patch.
> >
> > - Things are exact opposite with 4.18-rc1 and doing the above would
> > _prevent_ the hang and the image would boot fine.
> >
> > - Disabling USB in Barebox based boot "stack" gets it to behave the
> > same way as U-boot from your image (hanging when booting 4.18-rc1)
> >
> > Digging more into code it seems that the reason for 4.18-rc1's
> > behavior is the fact that it's missing a call hw_phymode_configure()
> > after usb_phy_init() and, AFAICT, the only reason it is not happening
> > is because default image is being built without
> > CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two
> > options on 4.18-rc1, seem to fix the problem on both your U-Boot based
> > image and my "special" Barebox setup.
> >
> > So AFAICT, this patch still fixes a valid issue (my use-case was net
> > booting via USB-Ethernet dongle), but an additional patch enabling
> > those two configuration options might be needed. Thoughts?
>
> Yes, I can confirm that your suggested change avoids the kernel hang:
>
> diff --git a/arch/arm/configs/imx_v6_v7_defconfig
> b/arch/arm/configs/imx_v6_v7_defconfig
> index d14de86..2da678c 100644
> --- a/arch/arm/configs/imx_v6_v7_defconfig
> +++ b/arch/arm/configs/imx_v6_v7_defconfig
> @@ -300,6 +300,7 @@ CONFIG_USB_STORAGE=y
> CONFIG_USB_CHIPIDEA=y
> CONFIG_USB_CHIPIDEA_UDC=y
> CONFIG_USB_CHIPIDEA_HOST=y
> +CONFIG_USB_CHIPIDEA_ULPI=y
> CONFIG_USB_SERIAL=m
> CONFIG_USB_SERIAL_GENERIC=y
> CONFIG_USB_SERIAL_FTDI_SIO=m
> @@ -336,6 +337,7 @@ CONFIG_USB_GADGETFS=m
> CONFIG_USB_FUNCTIONFS=m
> CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> +CONFIG_USB_ULPI_BUS=y
> CONFIG_MMC=y
> CONFIG_MMC_SDHCI=y
> CONFIG_MMC_SDHCI_PLTFM=y
>
> > Also, I don't have any i.MX53 HW, so I wasn't able to test the effects
> > of enabling those two options there.
>
> The imx53 board I have access to does not use ULPI.
>
> Maybe Sebastian on Cc may help testing this on his imx53 board as he
> is the author of:
> be9cae2479f48 ("usb: chipidea: imx: Fix ULPI on imx53")
I still have access to the imx53 based PPD from General Electric.
But I don't understand what patch you want me to test. FWIW the
images I use(d) for testing already had CONFIG_USB_CHIPIDEA_ULPI
and CONFIG_USB_ULPI_BUS enabled.
> I am wondering if we need to force some kind of USB reset to put the
> USB controller into a known state independently of what the bootloader
> has done previously.
Makes sense to me.
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180625/bcdea32f/attachment.sig>
^ permalink raw reply [flat|nested] 48+ messages in thread* usb: chipidea: Fix ULPI on imx51
@ 2018-06-25 12:18 ` Sebastian Reichel
0 siblings, 0 replies; 48+ messages in thread
From: Sebastian Reichel @ 2018-06-25 12:18 UTC (permalink / raw)
To: Fabio Estevam
Cc: Andrey Smirnov, Greg Kroah-Hartman, Nikita Yushchenko,
Peter Chen, USB list, linux-kernel, linux-arm-kernel,
Fabio Estevam, Chris Healy, Lucas Stach
Hi,
On Sun, Jun 24, 2018 at 08:51:20PM -0300, Fabio Estevam wrote:
> Hi Andrey,
>
> On Sun, Jun 24, 2018 at 7:40 PM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>
> > It's definitely the bootloader, or more specifically whether or not it
> > initialized/used USB before booting the kernel. Some interesting
> > highlights:
> >
> > - On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb
> > start" (optionally "usb stop") and then "boot", you'll get the hang
> > that I was trying to fix with my patch.
> >
> > - Things are exact opposite with 4.18-rc1 and doing the above would
> > _prevent_ the hang and the image would boot fine.
> >
> > - Disabling USB in Barebox based boot "stack" gets it to behave the
> > same way as U-boot from your image (hanging when booting 4.18-rc1)
> >
> > Digging more into code it seems that the reason for 4.18-rc1's
> > behavior is the fact that it's missing a call hw_phymode_configure()
> > after usb_phy_init() and, AFAICT, the only reason it is not happening
> > is because default image is being built without
> > CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two
> > options on 4.18-rc1, seem to fix the problem on both your U-Boot based
> > image and my "special" Barebox setup.
> >
> > So AFAICT, this patch still fixes a valid issue (my use-case was net
> > booting via USB-Ethernet dongle), but an additional patch enabling
> > those two configuration options might be needed. Thoughts?
>
> Yes, I can confirm that your suggested change avoids the kernel hang:
>
> diff --git a/arch/arm/configs/imx_v6_v7_defconfig
> b/arch/arm/configs/imx_v6_v7_defconfig
> index d14de86..2da678c 100644
> --- a/arch/arm/configs/imx_v6_v7_defconfig
> +++ b/arch/arm/configs/imx_v6_v7_defconfig
> @@ -300,6 +300,7 @@ CONFIG_USB_STORAGE=y
> CONFIG_USB_CHIPIDEA=y
> CONFIG_USB_CHIPIDEA_UDC=y
> CONFIG_USB_CHIPIDEA_HOST=y
> +CONFIG_USB_CHIPIDEA_ULPI=y
> CONFIG_USB_SERIAL=m
> CONFIG_USB_SERIAL_GENERIC=y
> CONFIG_USB_SERIAL_FTDI_SIO=m
> @@ -336,6 +337,7 @@ CONFIG_USB_GADGETFS=m
> CONFIG_USB_FUNCTIONFS=m
> CONFIG_USB_MASS_STORAGE=m
> CONFIG_USB_G_SERIAL=m
> +CONFIG_USB_ULPI_BUS=y
> CONFIG_MMC=y
> CONFIG_MMC_SDHCI=y
> CONFIG_MMC_SDHCI_PLTFM=y
>
> > Also, I don't have any i.MX53 HW, so I wasn't able to test the effects
> > of enabling those two options there.
>
> The imx53 board I have access to does not use ULPI.
>
> Maybe Sebastian on Cc may help testing this on his imx53 board as he
> is the author of:
> be9cae2479f48 ("usb: chipidea: imx: Fix ULPI on imx53")
I still have access to the imx53 based PPD from General Electric.
But I don't understand what patch you want me to test. FWIW the
images I use(d) for testing already had CONFIG_USB_CHIPIDEA_ULPI
and CONFIG_USB_ULPI_BUS enabled.
> I am wondering if we need to force some kind of USB reset to put the
> USB controller into a known state independently of what the bootloader
> has done previously.
Makes sense to me.
-- Sebastian
^ permalink raw reply [flat|nested] 48+ messages in thread* Re: [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-25 12:26 ` Fabio Estevam
0 siblings, 0 replies; 48+ messages in thread
From: Fabio Estevam @ 2018-06-25 12:26 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Andrey Smirnov, Greg Kroah-Hartman, Nikita Yushchenko,
Peter Chen, USB list, linux-kernel, linux-arm-kernel,
Fabio Estevam, Chris Healy, Lucas Stach
Hi Sebastian,
On Mon, Jun 25, 2018 at 9:18 AM, Sebastian Reichel
<sebastian.reichel@collabora.co.uk> wrote:
> I still have access to the imx53 based PPD from General Electric.
> But I don't understand what patch you want me to test. FWIW the
> images I use(d) for testing already had CONFIG_USB_CHIPIDEA_ULPI
> and CONFIG_USB_ULPI_BUS enabled.
I was referring to the patch that enables CONFIG_USB_CHIPIDEA_ULPI and
CONFIG_USB_ULPI_BUS.
Will submit this change as suggested by Andrey.
Regards,
Fabio Estevam
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-25 12:26 ` Fabio Estevam
0 siblings, 0 replies; 48+ messages in thread
From: Fabio Estevam @ 2018-06-25 12:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi Sebastian,
On Mon, Jun 25, 2018 at 9:18 AM, Sebastian Reichel
<sebastian.reichel@collabora.co.uk> wrote:
> I still have access to the imx53 based PPD from General Electric.
> But I don't understand what patch you want me to test. FWIW the
> images I use(d) for testing already had CONFIG_USB_CHIPIDEA_ULPI
> and CONFIG_USB_ULPI_BUS enabled.
I was referring to the patch that enables CONFIG_USB_CHIPIDEA_ULPI and
CONFIG_USB_ULPI_BUS.
Will submit this change as suggested by Andrey.
Regards,
Fabio Estevam
^ permalink raw reply [flat|nested] 48+ messages in thread
* usb: chipidea: Fix ULPI on imx51
@ 2018-06-25 12:26 ` Fabio Estevam
0 siblings, 0 replies; 48+ messages in thread
From: Fabio Estevam @ 2018-06-25 12:26 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Andrey Smirnov, Greg Kroah-Hartman, Nikita Yushchenko,
Peter Chen, USB list, linux-kernel, linux-arm-kernel,
Fabio Estevam, Chris Healy, Lucas Stach
Hi Sebastian,
On Mon, Jun 25, 2018 at 9:18 AM, Sebastian Reichel
<sebastian.reichel@collabora.co.uk> wrote:
> I still have access to the imx53 based PPD from General Electric.
> But I don't understand what patch you want me to test. FWIW the
> images I use(d) for testing already had CONFIG_USB_CHIPIDEA_ULPI
> and CONFIG_USB_ULPI_BUS enabled.
I was referring to the patch that enables CONFIG_USB_CHIPIDEA_ULPI and
CONFIG_USB_ULPI_BUS.
Will submit this change as suggested by Andrey.
Regards,
Fabio Estevam
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-21 14:12 ` Nikita Yushchenko
0 siblings, 0 replies; 48+ messages in thread
From: Nikita Yushchenko @ 2018-06-21 14:12 UTC (permalink / raw)
To: Andrey Smirnov, Fabio Estevam
Cc: Greg Kroah-Hartman, Peter Chen, linux-usb, linux-kernel,
linux-arm-kernel, Fabio Estevam, Chris Healy, Lucas Stach,
Sebastian Reichel
>>> This patches causes a regression on a imx51-babbage running 4.18-rc1:
>>> I get a kernel hang.
>>>
>>> If I revert it on top of 4.18-rc1, then it boots fine and USB host is
>>> functional.
>>>
>>> I understand this patch fixes a kernel hang for you, so which commit
>>> is responsible for the hang you observe?
>>>
>
> I never assumed it was a regression and that USB worked on RDU1 board
> before, so I never tried to see if this was a regression. I can only
> tell you that it hangs as soon as any PORTSC registers are accessed.
Hang at register access usually means that module that owns the register
is not clocked.
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-21 14:12 ` Nikita Yushchenko
0 siblings, 0 replies; 48+ messages in thread
From: Nikita Yushchenko @ 2018-06-21 14:12 UTC (permalink / raw)
To: linux-arm-kernel
>>> This patches causes a regression on a imx51-babbage running 4.18-rc1:
>>> I get a kernel hang.
>>>
>>> If I revert it on top of 4.18-rc1, then it boots fine and USB host is
>>> functional.
>>>
>>> I understand this patch fixes a kernel hang for you, so which commit
>>> is responsible for the hang you observe?
>>>
>
> I never assumed it was a regression and that USB worked on RDU1 board
> before, so I never tried to see if this was a regression. I can only
> tell you that it hangs as soon as any PORTSC registers are accessed.
Hang at register access usually means that module that owns the register
is not clocked.
^ permalink raw reply [flat|nested] 48+ messages in thread
* usb: chipidea: Fix ULPI on imx51
@ 2018-06-21 14:12 ` Nikita Yushchenko
0 siblings, 0 replies; 48+ messages in thread
From: Nikita Yushchenko @ 2018-06-21 14:12 UTC (permalink / raw)
To: Andrey Smirnov, Fabio Estevam
Cc: Greg Kroah-Hartman, Peter Chen, linux-usb, linux-kernel,
linux-arm-kernel, Fabio Estevam, Chris Healy, Lucas Stach,
Sebastian Reichel
>>> This patches causes a regression on a imx51-babbage running 4.18-rc1:
>>> I get a kernel hang.
>>>
>>> If I revert it on top of 4.18-rc1, then it boots fine and USB host is
>>> functional.
>>>
>>> I understand this patch fixes a kernel hang for you, so which commit
>>> is responsible for the hang you observe?
>>>
>
> I never assumed it was a regression and that USB worked on RDU1 board
> before, so I never tried to see if this was a regression. I can only
> tell you that it hangs as soon as any PORTSC registers are accessed.
Hang at register access usually means that module that owns the register
is not clocked.
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-21 14:25 ` Nikita Yushchenko
0 siblings, 0 replies; 48+ messages in thread
From: Nikita Yushchenko @ 2018-06-21 14:25 UTC (permalink / raw)
To: Andrey Smirnov, Fabio Estevam
Cc: Greg Kroah-Hartman, Peter Chen, linux-usb, linux-kernel,
linux-arm-kernel, Fabio Estevam, Chris Healy, Lucas Stach,
Sebastian Reichel
21.06.2018 17:12, Nikita Yushchenko wrote:
>>>> This patches causes a regression on a imx51-babbage running 4.18-rc1:
>>>> I get a kernel hang.
>>>>
>>>> If I revert it on top of 4.18-rc1, then it boots fine and USB host is
>>>> functional.
>>>>
>>>> I understand this patch fixes a kernel hang for you, so which commit
>>>> is responsible for the hang you observe?
>>>>
>>
>> I never assumed it was a regression and that USB worked on RDU1 board
>> before, so I never tried to see if this was a regression. I can only
>> tell you that it hangs as soon as any PORTSC registers are accessed.
>
> Hang at register access usually means that module that owns the register
> is not clocked.
On RDU1, call to usb_phy_init() actually calls usb_gen_phy_init() that
does regulator_enable() for &vusb_reg and clk_prepare_enable() for
&clk_26M_usb. I thing some of these two is actually needed to avoid
hang on register access.
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-21 14:25 ` Nikita Yushchenko
0 siblings, 0 replies; 48+ messages in thread
From: Nikita Yushchenko @ 2018-06-21 14:25 UTC (permalink / raw)
To: linux-arm-kernel
21.06.2018 17:12, Nikita Yushchenko wrote:
>>>> This patches causes a regression on a imx51-babbage running 4.18-rc1:
>>>> I get a kernel hang.
>>>>
>>>> If I revert it on top of 4.18-rc1, then it boots fine and USB host is
>>>> functional.
>>>>
>>>> I understand this patch fixes a kernel hang for you, so which commit
>>>> is responsible for the hang you observe?
>>>>
>>
>> I never assumed it was a regression and that USB worked on RDU1 board
>> before, so I never tried to see if this was a regression. I can only
>> tell you that it hangs as soon as any PORTSC registers are accessed.
>
> Hang at register access usually means that module that owns the register
> is not clocked.
On RDU1, call to usb_phy_init() actually calls usb_gen_phy_init() that
does regulator_enable() for &vusb_reg and clk_prepare_enable() for
&clk_26M_usb. I thing some of these two is actually needed to avoid
hang on register access.
^ permalink raw reply [flat|nested] 48+ messages in thread
* usb: chipidea: Fix ULPI on imx51
@ 2018-06-21 14:25 ` Nikita Yushchenko
0 siblings, 0 replies; 48+ messages in thread
From: Nikita Yushchenko @ 2018-06-21 14:25 UTC (permalink / raw)
To: Andrey Smirnov, Fabio Estevam
Cc: Greg Kroah-Hartman, Peter Chen, linux-usb, linux-kernel,
linux-arm-kernel, Fabio Estevam, Chris Healy, Lucas Stach,
Sebastian Reichel
21.06.2018 17:12, Nikita Yushchenko wrote:
>>>> This patches causes a regression on a imx51-babbage running 4.18-rc1:
>>>> I get a kernel hang.
>>>>
>>>> If I revert it on top of 4.18-rc1, then it boots fine and USB host is
>>>> functional.
>>>>
>>>> I understand this patch fixes a kernel hang for you, so which commit
>>>> is responsible for the hang you observe?
>>>>
>>
>> I never assumed it was a regression and that USB worked on RDU1 board
>> before, so I never tried to see if this was a regression. I can only
>> tell you that it hangs as soon as any PORTSC registers are accessed.
>
> Hang at register access usually means that module that owns the register
> is not clocked.
On RDU1, call to usb_phy_init() actually calls usb_gen_phy_init() that
does regulator_enable() for &vusb_reg and clk_prepare_enable() for
&clk_26M_usb. I thing some of these two is actually needed to avoid
hang on register access.
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-22 0:49 ` Peter Chen
0 siblings, 0 replies; 48+ messages in thread
From: Peter Chen @ 2018-06-22 0:49 UTC (permalink / raw)
To: Nikita Yushchenko, Andrey Smirnov, Fabio Estevam
Cc: Greg Kroah-Hartman, linux-usb, linux-kernel, linux-arm-kernel,
Fabio Estevam, Chris Healy, Lucas Stach, Sebastian Reichel
> >>>>
> >>
> >> I never assumed it was a regression and that USB worked on RDU1 board
> >> before, so I never tried to see if this was a regression. I can only
> >> tell you that it hangs as soon as any PORTSC registers are accessed.
> >
> > Hang at register access usually means that module that owns the
> > register is not clocked.
>
> On RDU1, call to usb_phy_init() actually calls usb_gen_phy_init() that does
> regulator_enable() for &vusb_reg and clk_prepare_enable() for &clk_26M_usb. I
> thing some of these two is actually needed to avoid hang on register access.
Fabio, would you please check both regulator and clock for ULPI PHY are on at imx51bbg?
Peter
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH] usb: chipidea: Fix ULPI on imx51
@ 2018-06-22 0:49 ` Peter Chen
0 siblings, 0 replies; 48+ messages in thread
From: Peter Chen @ 2018-06-22 0:49 UTC (permalink / raw)
To: linux-arm-kernel
> >>>>
> >>
> >> I never assumed it was a regression and that USB worked on RDU1 board
> >> before, so I never tried to see if this was a regression. I can only
> >> tell you that it hangs as soon as any PORTSC registers are accessed.
> >
> > Hang at register access usually means that module that owns the
> > register is not clocked.
>
> On RDU1, call to usb_phy_init() actually calls usb_gen_phy_init() that does
> regulator_enable() for &vusb_reg and clk_prepare_enable() for &clk_26M_usb. I
> thing some of these two is actually needed to avoid hang on register access.
Fabio, would you please check both regulator and clock for ULPI PHY are on at imx51bbg?
Peter
^ permalink raw reply [flat|nested] 48+ messages in thread
* usb: chipidea: Fix ULPI on imx51
@ 2018-06-22 0:49 ` Peter Chen
0 siblings, 0 replies; 48+ messages in thread
From: Peter Chen @ 2018-06-22 0:49 UTC (permalink / raw)
To: Nikita Yushchenko, Andrey Smirnov, Fabio Estevam
Cc: Greg Kroah-Hartman, linux-usb, linux-kernel, linux-arm-kernel,
Fabio Estevam, Chris Healy, Lucas Stach, Sebastian Reichel
> >>>>
> >>
> >> I never assumed it was a regression and that USB worked on RDU1 board
> >> before, so I never tried to see if this was a regression. I can only
> >> tell you that it hangs as soon as any PORTSC registers are accessed.
> >
> > Hang at register access usually means that module that owns the
> > register is not clocked.
>
> On RDU1, call to usb_phy_init() actually calls usb_gen_phy_init() that does
> regulator_enable() for &vusb_reg and clk_prepare_enable() for &clk_26M_usb. I
> thing some of these two is actually needed to avoid hang on register access.
Fabio, would you please check both regulator and clock for ULPI PHY are on at imx51bbg?
Peter
^ permalink raw reply [flat|nested] 48+ messages in thread