| Message ID | 9ce549aa-79a9-81e4-b569-b9a5d574850d@onet.eu |
|---|---|
| State | Not Applicable |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | [U-Boot] chiliSOM: USB bug | expand |
Hi Witold, On 11.04.2018 08:18, sdrb wrote: > Hi, > > I use Grinn's chiliSOM and very old U-boot 2014.07 on it. Unfortunately > the newest u-boot doesn't run SPL properly - so I'm forced to use > 2014.07 version. What are your problems exactly with SPL? What version of chiliSOM does you board have? Mainline u-boot with SPL runs successfully on chiliboard 1.1 (containing chiliSOM 2.2). > > I noticed that there is some problem with USB maintenance. As far as I > know the chiliSOM is TI AM335x compatible system so it uses Mentor USB > OTG controller. > > The problem occures when I'm trying to use following sequence of commands: > > # usb start > # usb stop > # usb start See output of commands issued on u-boot 2018.03: => usb start starting USB... USB0: scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... Device NOT ready Request Sense returned 02 3A 00 Device NOT ready Request Sense returned 02 3A 00 Device NOT ready Request Sense returned 02 3A 00 Device NOT ready Request Sense returned 02 3A 00 0 Storage Device(s) found => usb stop stopping USB.. => usb start starting USB... USB0: scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... Device NOT ready Request Sense returned 02 3A 00 Device NOT ready Request Sense returned 02 3A 00 Device NOT ready Request Sense returned 02 3A 00 Device NOT ready Request Sense returned 02 3A 00 0 Storage Device(s) found Did you try to connect other USB devices? Is that issue connected USB device dependent? Regards, Marcin > > and after the second "usb start" I get error: > > [2018-04-06 08:13:42.600] U-Boot# usb start > [2018-04-06 08:13:44.162] (Re)start USB... > [2018-04-06 08:13:44.164] USB0: scanning bus 0 for devices... 5 USB > Device(s) found > [2018-04-06 08:13:50.872] scanning usb for storage devices... 0 > Storage Device(s) found > [2018-04-06 08:13:50.881] U-Boot# usb stop > [2018-04-06 08:13:55.514] stopping USB.. > [2018-04-06 08:13:55.521] U-Boot# usb start > [2018-04-06 08:14:01.962] (Re)start USB... > [2018-04-06 08:14:01.964] USB0: lowlevel init failed > [2018-04-06 08:14:16.730] USB error: all controllers failed lowlevel init > [2018-04-06 08:14:16.734] U-Boot# > > I dig a little the code and I noticed that there is some line which > breaks up things. > The problem is in proc musb_generic_disable() where there is zeroed > DEVCTL register. > Seems like zeroing breaks somehow Mentor USB because after it it not > possible to turn USB host mode. > > I tried to solve the problem with push MUSB into suspend mode, then zero > DEVCTL and then resume MUSB, but still no success. > So I decided to remove this line from my code and now it seems to work. > I mean now USB is working fine: > > [2018-04-06 08:15:44.290] U-Boot# usb start > [2018-04-06 08:15:45.787] (Re)start USB... > [2018-04-06 08:15:45.790] USB0: scanning bus 0 for devices... 5 USB > Device(s) found > [2018-04-06 08:15:52.489] scanning usb for storage devices... 0 > Storage Device(s) found > [2018-04-06 08:15:52.495] U-Boot# usb stop > [2018-04-06 08:15:54.835] stopping USB.. > [2018-04-06 08:15:54.837] U-Boot# usb start > [2018-04-06 08:17:03.323] (Re)start USB... > [2018-04-06 08:17:03.325] USB0: scanning bus 0 for devices... 5 USB > Device(s) found > [2018-04-06 08:17:09.864] scanning usb for storage devices... 0 > Storage Device(s) found > [2018-04-06 08:17:09.871] U-Boot# > > > I know that my u-boot version 2014.07 is quite old, but the proc > musb_generic_disable() in newest version is the same so probably the > problem also still occures on other boards. > > Anyone can verify or confirm that? I'd like to know if this is not > specific to my board with chiliSOM. > I removed zeroing of DEVCTL register but maybe there is some better > solution? > > Any thoughts? > > WK > > > commit 22447924ca27d3332698d3976f3e5e653bf893cc > Author: Witold Kowolik <sdrb@onet.eu> > Date: Wed Apr 11 07:49:42 2018 +0200 > > ARM: am335x: chiliSOM: Temporary workaround for Mentor OTG USB in > host mode > > Signed-off-by: Witold Kowolik <sdrb@onet.eu> > > diff --git a/drivers/usb/musb-new/musb_core.c > b/drivers/usb/musb-new/musb_core.c > index 79e118ef85..2be2bd6081 100644 > --- a/drivers/usb/musb-new/musb_core.c > +++ b/drivers/usb/musb-new/musb_core.c > @@ -977,7 +977,7 @@ static void musb_generic_disable(struct musb *musb) > musb_writew(mbase, MUSB_INTRRXE, 0); > > /* off */ > - musb_writeb(mbase, MUSB_DEVCTL, 0); > + /* musb_writeb(mbase, MUSB_DEVCTL, 0); */ > > /* flush pending interrupts */ > temp = musb_readb(mbase, MUSB_INTRUSB); > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot
Hi Marcin, Marcin Niestroj wrote: > Hi Witold, > > On 11.04.2018 08:18, sdrb wrote: >> Hi, >> >> I use Grinn's chiliSOM and very old U-boot 2014.07 on it. >> Unfortunately the newest u-boot doesn't run SPL properly - so I'm >> forced to use 2014.07 version. > > What are your problems exactly with SPL? What version of chiliSOM does > you board have? Mainline u-boot with SPL runs successfully on > chiliboard 1.1 (containing chiliSOM 2.2). I've got ChiliSOM 2.2 version. I don't use chiliboard - I've got only chiliSOM 2.2 integrated in our carrying board. The problem is that SPL is not starting as good as in 2014.07 version. I mean - firmware shows only a few 'C' letters and then it hungs in some infinite loop: CCCCCCCCCCCCCCC but when at that moment I press Reset button it starts but unfortunately something is going wrong because it restarts: U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 +0200) Trying to boot from MMC1 CCCCCCCC U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 +0200) Trying to boot from MMC1 CCCCCCCC U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 +0200) Trying to boot from MMC1 CCCCCCCC U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 +0200) Trying to boot from MMC1 So - to run newest u-boot I need to power-on board and then press reset. I dig a litte in source of latest uboot and noticed that the last procedure which is invoked in SPL is jump_to_image_no_args(). This proc tries to go to 0x80800000 addr and then reset appears. But before it tries to go into this addr it successfully reads u-boot.img file. So rather the problem is in invocation of TPL than in SPL. I wonder why the u-boot.img file is only 389392 bytes long while in old u-boot it was 1.7 MB. Additionally - I see no device tree source file for chilisom in git repo but the configuration file mention it in CONFIG_DEFAULT_FDT_FILE. Do we use the same u-boot repo? I use this one: http://git.denx.de/u-boot.git and master branch. Maybe I did something wrong? >> I noticed that there is some problem with USB maintenance. As far as I >> know the chiliSOM is TI AM335x compatible system so it uses Mentor USB >> OTG controller. >> >> The problem occures when I'm trying to use following sequence of >> commands: >> >> # usb start >> # usb stop >> # usb start > > See output of commands issued on u-boot 2018.03: > > => usb start > starting USB... > USB0: scanning bus 0 for devices... 1 USB Device(s) found > scanning usb for storage devices... Device NOT ready > Request Sense returned 02 3A 00 > Device NOT ready > Request Sense returned 02 3A 00 > Device NOT ready > Request Sense returned 02 3A 00 > Device NOT ready > Request Sense returned 02 3A 00 > 0 Storage Device(s) found > => usb stop > stopping USB.. > => usb start > starting USB... > USB0: scanning bus 0 for devices... 1 USB Device(s) found > scanning usb for storage devices... Device NOT ready > Request Sense returned 02 3A 00 > Device NOT ready > Request Sense returned 02 3A 00 > Device NOT ready > Request Sense returned 02 3A 00 > Device NOT ready > Request Sense returned 02 3A 00 > 0 Storage Device(s) found > > Did you try to connect other USB devices? Is that issue connected > USB device dependent? We've got two USB 1.1 hubs integrated on board - so I cannot switch them off. I'm connecting USB device to one of it ports. I see no any dependency between any connected USB device and the problem. Regards, WK
On 12.04.2018 06:37, sdrb wrote: > Hi Marcin, > > Marcin Niestroj wrote: >> Hi Witold, >> >> On 11.04.2018 08:18, sdrb wrote: >>> Hi, >>> >>> I use Grinn's chiliSOM and very old U-boot 2014.07 on it. >>> Unfortunately the newest u-boot doesn't run SPL properly - so I'm >>> forced to use 2014.07 version. >> >> What are your problems exactly with SPL? What version of chiliSOM does >> you board have? Mainline u-boot with SPL runs successfully on >> chiliboard 1.1 (containing chiliSOM 2.2). > > I've got ChiliSOM 2.2 version. > I don't use chiliboard - I've got only chiliSOM 2.2 integrated in our > carrying board. > > > The problem is that SPL is not starting as good as in 2014.07 version. I > mean - firmware shows only a few 'C' letters and then it hungs in some > infinite loop: > > CCCCCCCCCCCCCCC > > but when at that moment I press Reset button it starts but unfortunately > something is going wrong because it restarts: > > U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 > +0200) > Trying to boot from MMC1 > CCCCCCCC > U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 > +0200) > Trying to boot from MMC1 > CCCCCCCC > U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 > +0200) > Trying to boot from MMC1 > CCCCCCCC > U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 > +0200) > Trying to boot from MMC1 > > So - to run newest u-boot I need to power-on board and then press reset. Could you describe what is you BOOT[4:0] configuration? And you want to boot from MMC1, right? If you are booting u-boot 2014.07 version, do you still see CCCCC on the beginning? I have noticed something else on chiliboard. Device is normally powered on with no problems (after plugging in USB cable for example). But after it powers off (to RTC only), then I push power button to wakeup device, it shows CCCCCCC in infinite loop. To recover from this state I need to plug out SD card and plug it in once again. Then device boots correctly. Thought this is hardware issue and didn't have enough time to look at that. I wonder if both issues have the same root cause... > > > I dig a litte in source of latest uboot and noticed that the last > procedure which is invoked in SPL is jump_to_image_no_args(). > This proc tries to go to 0x80800000 addr and then reset appears. > But before it tries to go into this addr it successfully reads > u-boot.img file. So rather the problem is in invocation of TPL than in SPL. > > I wonder why the u-boot.img file is only 389392 bytes long while in old > u-boot it was 1.7 MB. > > Additionally - I see no device tree source file for chilisom in git repo > but the configuration file mention it in CONFIG_DEFAULT_FDT_FILE. This configuration sets name of dts file to be used with Linux kernel. > > Do we use the same u-boot repo? I use this one: > http://git.denx.de/u-boot.git > > and master branch. Yes, I use the same repo and branch. > > Maybe I did something wrong? > >>> I noticed that there is some problem with USB maintenance. As far as >>> I know the chiliSOM is TI AM335x compatible system so it uses Mentor >>> USB OTG controller. >>> >>> The problem occures when I'm trying to use following sequence of >>> commands: >>> >>> # usb start >>> # usb stop >>> # usb start >> >> See output of commands issued on u-boot 2018.03: >> >> => usb start >> starting USB... >> USB0: scanning bus 0 for devices... 1 USB Device(s) found >> scanning usb for storage devices... Device NOT ready >> Request Sense returned 02 3A 00 >> Device NOT ready >> Request Sense returned 02 3A 00 >> Device NOT ready >> Request Sense returned 02 3A 00 >> Device NOT ready >> Request Sense returned 02 3A 00 >> 0 Storage Device(s) found >> => usb stop >> stopping USB.. >> => usb start >> starting USB... >> USB0: scanning bus 0 for devices... 1 USB Device(s) found >> scanning usb for storage devices... Device NOT ready >> Request Sense returned 02 3A 00 >> Device NOT ready >> Request Sense returned 02 3A 00 >> Device NOT ready >> Request Sense returned 02 3A 00 >> Device NOT ready >> Request Sense returned 02 3A 00 >> 0 Storage Device(s) found >> >> Did you try to connect other USB devices? Is that issue connected >> USB device dependent? > > We've got two USB 1.1 hubs integrated on board - so I cannot switch them > off. I'm connecting USB device to one of it ports. I see no any > dependency between any connected USB device and the problem. > > Regards, > WK
Marcin Niestrój wrote: > > > On 12.04.2018 06:37, sdrb wrote: >> Hi Marcin, >> >> Marcin Niestroj wrote: >>> Hi Witold, >>> >>> On 11.04.2018 08:18, sdrb wrote: >>>> Hi, >>>> >>>> I use Grinn's chiliSOM and very old U-boot 2014.07 on it. >>>> Unfortunately the newest u-boot doesn't run SPL properly - so I'm >>>> forced to use 2014.07 version. >>> >>> What are your problems exactly with SPL? What version of chiliSOM does >>> you board have? Mainline u-boot with SPL runs successfully on >>> chiliboard 1.1 (containing chiliSOM 2.2). >> >> I've got ChiliSOM 2.2 version. >> I don't use chiliboard - I've got only chiliSOM 2.2 integrated in our >> carrying board. >> >> >> The problem is that SPL is not starting as good as in 2014.07 version. >> I mean - firmware shows only a few 'C' letters and then it hungs in >> some infinite loop: >> >> CCCCCCCCCCCCCCC >> >> but when at that moment I press Reset button it starts but >> unfortunately something is going wrong because it restarts: >> >> U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 >> +0200) >> Trying to boot from MMC1 >> CCCCCCCC >> U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 >> +0200) >> Trying to boot from MMC1 >> CCCCCCCC >> U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 >> +0200) >> Trying to boot from MMC1 >> CCCCCCCC >> U-Boot SPL 2018.05-rc1-00251-g2600df4f8e-dirty (Apr 12 2018 - 05:59:00 >> +0200) >> Trying to boot from MMC1 >> >> So - to run newest u-boot I need to power-on board and then press reset. > > Could you describe what is you BOOT[4:0] configuration? And you want to > boot from MMC1, right? If I read the BOOT[4:0] properly it is: 0011. I want to boot from SD card. > If you are booting u-boot 2014.07 version, do you still see CCCCC on the > beginning? Yes > I have noticed something else on chiliboard. Device is normally powered > on with no problems (after plugging in USB cable for example). But after > it powers off (to RTC only), then I push power button to wakeup device, > it shows CCCCCCC in infinite loop. To recover from this state I need > to plug out SD card and plug it in once again. Then device boots > correctly. Thought this is hardware issue and didn't have enough > time to look at that. > I wonder if both issues have the same root cause... I have also noticed that sometimes the whole system is not starting properly and still shows 'C' letters. And yes - I also replug SD card or turn off the power to fix the problem. >> I dig a litte in source of latest uboot and noticed that the last >> procedure which is invoked in SPL is jump_to_image_no_args(). >> This proc tries to go to 0x80800000 addr and then reset appears. >> But before it tries to go into this addr it successfully reads >> u-boot.img file. So rather the problem is in invocation of TPL than in >> SPL. >> >> I wonder why the u-boot.img file is only 389392 bytes long while in >> old u-boot it was 1.7 MB. >> >> Additionally - I see no device tree source file for chilisom in git >> repo but the configuration file mention it in CONFIG_DEFAULT_FDT_FILE. > > This configuration sets name of dts file to be used with Linux kernel. > Ok, I thought that u-boot uses it for its own purposes. Regards, WK
On 12.04.2018 11:09, sdrb wrote: > Marcin Niestrój wrote: >> >> <snip> >> >> Could you describe what is you BOOT[4:0] configuration? And you want to >> boot from MMC1, right? > > If I read the BOOT[4:0] properly it is: 0011. > I want to boot from SD card. Please provide these 5 pins (including 4 and 0) configuration.
Marcin Niestroj wrote: > > > On 12.04.2018 11:09, sdrb wrote: >> Marcin Niestrój wrote: >>> > >> <snip> >>> >>> Could you describe what is you BOOT[4:0] configuration? And you want to >>> boot from MMC1, right? >> >> If I read the BOOT[4:0] properly it is: 0011. >> I want to boot from SD card. > > Please provide these 5 pins (including 4 and 0) configuration. > Sorry for misprint - SYSBOOT[4:0] pins are as follows: 00011. Regards, WK
On 12.04.2018 13:35, sdrb wrote: > Marcin Niestroj wrote: >> >> >> On 12.04.2018 11:09, sdrb wrote: >>> Marcin Niestrój wrote: >>>> >> >> <snip> >>>> >>>> Could you describe what is you BOOT[4:0] configuration? And you want to >>>> boot from MMC1, right? >>> >>> If I read the BOOT[4:0] properly it is: 0011. >>> I want to boot from SD card. >> >> Please provide these 5 pins (including 4 and 0) configuration. >> > > Sorry for misprint - SYSBOOT[4:0] pins are as follows: 00011. Unfortunately I can't reproduce this issue on my side with chiliboard. It's hard to tell what could be the problem when using you board. What RAM vendor is on chiliSOM you have on your board? Maybe there DDR is not initialized with proper timing? Don't have other ideas for now. > > Regards, > WK >
Marcin Niestroj wrote: > > On 12.04.2018 13:35, sdrb wrote: >> Marcin Niestroj wrote: >>> >>> >>> On 12.04.2018 11:09, sdrb wrote: >>>> Marcin Niestrój wrote: >>>>> >>> >> <snip> >>>>> >>>>> Could you describe what is you BOOT[4:0] configuration? And you >>>>> want to >>>>> boot from MMC1, right? >>>> >>>> If I read the BOOT[4:0] properly it is: 0011. >>>> I want to boot from SD card. >>> >>> Please provide these 5 pins (including 4 and 0) configuration. >>> >> >> Sorry for misprint - SYSBOOT[4:0] pins are as follows: 00011. > > Unfortunately I can't reproduce this issue on my side with chiliboard. > It's hard to tell what could be the problem when using you board. > What RAM vendor is on chiliSOM you have on your board? Maybe there > DDR is not initialized with proper timing? Don't have other ideas for > now. > If I identified properly the chip it is Samsung.
On 13.04.2018 11:12, sdrb wrote: > Marcin Niestroj wrote: >> >> On 12.04.2018 13:35, sdrb wrote: >>> Marcin Niestroj wrote: >>>> >>>> >>>> On 12.04.2018 11:09, sdrb wrote: >>>>> Marcin Niestrój wrote: >>>>>> >>>> >> <snip> >>>>>> >>>>>> Could you describe what is you BOOT[4:0] configuration? And you >>>>>> want to >>>>>> boot from MMC1, right? >>>>> >>>>> If I read the BOOT[4:0] properly it is: 0011. >>>>> I want to boot from SD card. >>>> >>>> Please provide these 5 pins (including 4 and 0) configuration. >>>> >>> >>> Sorry for misprint - SYSBOOT[4:0] pins are as follows: 00011. >> >> Unfortunately I can't reproduce this issue on my side with chiliboard. >> It's hard to tell what could be the problem when using you board. >> What RAM vendor is on chiliSOM you have on your board? Maybe there >> DDR is not initialized with proper timing? Don't have other ideas for >> now. >> > > If I identified properly the chip it is Samsung. > We had an issue with Samsung DDR on chiliSOM with one of our clients and his board. We have used a workaround patch to sleep between DDR initialization and copying u-boot.img to RAM. If there was no delay, then RAM memory was in undefined behavior, resulting in very strange runtime errors. We used u-boot 2014.07 back then. However I see that commit 69b918b65d11 ("am33xx,ddr3: fix ddr3 sdram configuration") already addresses this issue, but in a different way than we did back then. So I have no idea now what goes wrong in your case.
diff --git a/drivers/usb/musb-new/musb_core.c b/drivers/usb/musb-new/musb_core.c index 79e118ef85..2be2bd6081 100644 --- a/drivers/usb/musb-new/musb_core.c +++ b/drivers/usb/musb-new/musb_core.c @@ -977,7 +977,7 @@ static void musb_generic_disable(struct musb *musb) musb_writew(mbase, MUSB_INTRRXE, 0); /* off */ - musb_writeb(mbase, MUSB_DEVCTL, 0); + /* musb_writeb(mbase, MUSB_DEVCTL, 0); */ /* flush pending interrupts */ temp = musb_readb(mbase, MUSB_INTRUSB);
Hi, I use Grinn's chiliSOM and very old U-boot 2014.07 on it. Unfortunately the newest u-boot doesn't run SPL properly - so I'm forced to use 2014.07 version. I noticed that there is some problem with USB maintenance. As far as I know the chiliSOM is TI AM335x compatible system so it uses Mentor USB OTG controller. The problem occures when I'm trying to use following sequence of commands: # usb start # usb stop # usb start and after the second "usb start" I get error: [2018-04-06 08:13:42.600] U-Boot# usb start [2018-04-06 08:13:44.162] (Re)start USB... [2018-04-06 08:13:44.164] USB0: scanning bus 0 for devices... 5 USB Device(s) found [2018-04-06 08:13:50.872] scanning usb for storage devices... 0 Storage Device(s) found [2018-04-06 08:13:50.881] U-Boot# usb stop [2018-04-06 08:13:55.514] stopping USB.. [2018-04-06 08:13:55.521] U-Boot# usb start [2018-04-06 08:14:01.962] (Re)start USB... [2018-04-06 08:14:01.964] USB0: lowlevel init failed [2018-04-06 08:14:16.730] USB error: all controllers failed lowlevel init [2018-04-06 08:14:16.734] U-Boot# I dig a little the code and I noticed that there is some line which breaks up things. The problem is in proc musb_generic_disable() where there is zeroed DEVCTL register. Seems like zeroing breaks somehow Mentor USB because after it it not possible to turn USB host mode. I tried to solve the problem with push MUSB into suspend mode, then zero DEVCTL and then resume MUSB, but still no success. So I decided to remove this line from my code and now it seems to work. I mean now USB is working fine: [2018-04-06 08:15:44.290] U-Boot# usb start [2018-04-06 08:15:45.787] (Re)start USB... [2018-04-06 08:15:45.790] USB0: scanning bus 0 for devices... 5 USB Device(s) found [2018-04-06 08:15:52.489] scanning usb for storage devices... 0 Storage Device(s) found [2018-04-06 08:15:52.495] U-Boot# usb stop [2018-04-06 08:15:54.835] stopping USB.. [2018-04-06 08:15:54.837] U-Boot# usb start [2018-04-06 08:17:03.323] (Re)start USB... [2018-04-06 08:17:03.325] USB0: scanning bus 0 for devices... 5 USB Device(s) found [2018-04-06 08:17:09.864] scanning usb for storage devices... 0 Storage Device(s) found [2018-04-06 08:17:09.871] U-Boot# I know that my u-boot version 2014.07 is quite old, but the proc musb_generic_disable() in newest version is the same so probably the problem also still occures on other boards. Anyone can verify or confirm that? I'd like to know if this is not specific to my board with chiliSOM. I removed zeroing of DEVCTL register but maybe there is some better solution? Any thoughts? WK commit 22447924ca27d3332698d3976f3e5e653bf893cc Author: Witold Kowolik <sdrb@onet.eu> Date: Wed Apr 11 07:49:42 2018 +0200 ARM: am335x: chiliSOM: Temporary workaround for Mentor OTG USB in host mode Signed-off-by: Witold Kowolik <sdrb@onet.eu>