[U-Boot] [linux-sunxi] [PATCH 0/6] sunxi: H6: Enable USB (2.0) support
Clément Péron
peron.clem at gmail.com
Wed Jun 26 22:25:01 UTC 2019
Hi André,
On Thu, 20 Jun 2019 at 23:18, André Przywara <andre.przywara at arm.com> wrote:
>
> On 20/06/2019 19:01, Clément Péron wrote:
>
> Hi Clément,
>
> thanks for trying that!
> ...
>
> > On Wed, 19 Jun 2019 at 12:03, Andre Przywara <andre.przywara at arm.com> wrote:
> >>
> >> On Wed, 19 Jun 2019 10:57:14 +0200
> >> Clément Péron <peron.clem at gmail.com> wrote:
> >>
> >> Hi,
> >>
> >>> On Wed, 19 Jun 2019 at 03:04, André Przywara <andre.przywara at arm.com> wrote:
> >>>>
> >>>> On Tue, 18 Jun 2019 19:22:34 +0200
> >>>> Clément Péron <peron.clem at gmail.com> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>>
> >>>>> On Tue, 18 Jun 2019 at 19:08, Clément Péron <peron.clem at gmail.com> wrote:
> >>>>>>
> >>>>>> Hi Andre,
> >>>>>>
> >>>>>> On Tue, 18 Jun 2019 at 09:50, Jagan Teki <jagan at amarulasolutions.com> wrote:
> >>>>>>>
> >>>>>>> On Thu, May 16, 2019 at 6:56 AM Andre Przywara <andre.przywara at arm.com> wrote:
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> this series enables USB support on the H6 boards. This is mostly just
> >>>>>>>> adding some missing pieces here and there, the actual controller and PHY
> >>>>>>>> are very similar to the previous ones, if not identical.
> >>>>>>>> This is for the 2.0 ports only at the moment, USB 3.0 will be done
> >>>>>>>> later (started porting Icenowy's Linux driver).
> >>>>>>>> The Pine H64 shares a similar problem as the Pine64+ boards regarding
> >>>>>>>> the upper USB port. To enable this port, we need the first patch
> >>>>>>>> from the series [1] fixing this issue on the A64 boards.
> >>>>>>>>
> >>>>>>>> Patch 1 is a drive-by patch to bring SUNXI_GPIO to Kconfig, as this was
> >>>>>>>> lingering in one of my branches for a while.
> >>>>>>>> Patch 2 enables GPIO support for the H6, as this is needed for the Pine
> >>>>>>>> H64 to enable the VBUS regulator.
> >>>>>>>> Patch 3 adds the clock and reset gates mappings for the USB controller and
> >>>>>>>> the PHY, the values are taken from the manual and verified against
> >>>>>>>> Linux.
> >>>>>>>> Patch 4 adds some code to the PHY driver to skip over not implemented
> >>>>>>>> PHYs, as the H6 uses a PHY0/PHY3 combination in the DT.
> >>>>>>>> Patch 5 then eventually enables USB in the existing defconfigs.
> >>>>>>>> Patch 6 adds the .dts fixes required to get the upper USB port to work
> >>>>>>>> on the Pine H64.
> >>>>>>>>
> >>>>>>>> Clément, can you please verify that this works for the Beelink box?
> >>>>>> Thank you for the notice.
> >>>>>>
> >>>>>> Works fine on my board:
> >>>>> I have tested with and without the trick in usb2otg node and both seems working.
> >>>>> (only tested usb start; usb tree).
> >>>>
> >>>> You mean dropping the status="okay"?
> >>> I mean, I have tested with and without the whole patch and it works in
> >>> both cases.
> >>
> >> Do you mean it works without adding "phys = <&usb2phy 0>;" to the ehci0
> >> and ohci0 nodes?
> >> Are you sure that USB *really* works? The boot log *always* enumerates the
> >> bus and prints one device (the root hub), but does "usb tree" show an
> >> actual connected device? The easiest test is to connect a pen drive, at
> >> which point U-Boot automatically lists the USB mass storage device in the
> >> boot log.
> >
> > You're right, only the root hub is enumerated.
> > Actually the VBUS supply on my board is directly provided by the
> > always-on "DC Jack".
> > So normally this hack is not needed and the USB should work in both
> > case which is kind of expected.
>
> Well, the power part is one thing, but quite some boards do it like this
> (Pine64, for instance).
> This PHY connection property is something separate, it's just needed for
> U-Boot, because the driver will bail out if it cannot find a PHY. It's a
> driver shortcoming, if you like, checkout ehci_setup_phy() in
> drivers/usb/host/ehci-hcd.c and it's call site in
> drivers/usb/host/ehci-generic.c:ehci_usb_probe().
>
> > But unfortunately it's doesn't seem to work. I have tested with a
> > storage usb and it's not listed :(
>
> Mmmh, interesting. Does it work in Linux?
Yes complete bootlog : https://pastebin.com/2kUZR23B
I have tested with 3 USB keys and none are listed in USB Storage Devices found.
> Also, did you ever try FEL booting, using this port and an A-to-A cable?
Only with the PhoenixUsb Tools for recovering the original ROM.
> Just asking to make sure that USB 2.0 port is actually USB0, and not the
> other USB 2.0 port on the SoC (USB3).
There is only 1 USB 2.0 Port on this board and yes it's the USB0.
>
> > The TX UART of my board is not functional so it's a bit touchy to
> > debug the issue.
>
> Ah, same as on the Eachlink H6 Mini, then. Did you see what Sven and I
> came up with?
> http://linux-sunxi.org/Eachlink_H6_Mini#Adding_a_serial_port_.28might_void_warranty.3F.29
Thanks for the link but I have burnt the pin myself.
It was working at the beggining but one day I have misplugged the pins
and this GPIO is now unusable :(.
I should try to switch to the BT UART the day I really need it.
Regards,
Clément
>
> > Anyway it doesn't make the board reset so it's not blocking.
> > I will try to investigate this later.
>
> OK, thanks!
>
> Cheers,
> Andre.
>
> >>>> Yeah, I figured as well that it works both ways. Actually older kernels
> >>>> require the MUSB driver to be enabled, while newer kernels don't seem to
> >>>> care. As this affects the Debian Buster kernel (4.19, in the installer),
> >>>> I plan on just leaving it as it is right now.
> >>>>
> >>>>> Why not leave it to avoid a difference with linux?
> >>>>
> >>>> Technically we should disable it, as it's not usable and might clash
> >>>> with EHCI0/OHCI0, but for said reason I just keep it.
> >>> That's what I have in mind, if it's not mandatory just leave it as
> >>> this, this will avoid differences with linux.
> >>
> >> There shall be no real differences with Linux, in this case I will push
> >> those changes to Linux, so we sync this somewhat the other way.
> >> The hardware clearly connects the USB0 controller to PHY0, the DT should
> >> reflect this.
> >>
> >> Cheers,
> >> Andre.
> >>
> >>>>>> U-Boot 2019.07-rc4 (Jun 18 2019 - 19:06:21 +0200) Allwinner Technology
> >>>>>>
> >>>>>> CPU: Allwinner H6 (SUN50I)
> >>>>>> Model: Beelink GS1
> >>>>>> DRAM: 2 GiB
> >>>>>> MMC: mmc at 4020000: 0, mmc at 4022000: 1
> >>>>>> Loading Environment from FAT... Unable to use mmc 1:1... In: serial at 5000000
> >>>>>> Out: serial at 5000000
> >>>>>> Err: serial at 5000000
> >>>>>> Net: No ethernet found.
> >>>>>> starting USB...
> >>>>>> Bus usb at 5101000: USB EHCI 1.00
> >>>>>> Bus usb at 5101400: USB OHCI 1.0
> >>>>>> scanning bus usb at 5101000 for devices... 1 USB Device(s) found
> >>>>>>
> >>>>>> Regards,
> >>>>>> Clément
> >>>>>>
> >>>>>>>> I guess the USB 2.0 port is probably the OTG one, so this setup would
> >>>>>>>> look somewhat similar to the PineH64, which would allow you to copy
> >>>>>>>> the USB DT nodes from there.
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Andre.
> >>>>>>>>
> >>>>>>>> [1] https://lists.denx.de/pipermail/u-boot/2019-May/369520.html
> >>>>>>>>
> >>>>>>>> Andre Przywara (6):
> >>>>>>>> sunxi: move SUNXI_GPIO to Kconfig
> >>>>>>>> sunxi: gpio: Enable support for H6 pin controller
> >>>>>>>> sunxi: clocks: Add H6 USB clock gates and resets
> >>>>>>>> sunxi: phy: Add USB PHY support for Allwinner H6
> >>>>>>>> sunxi: H6: Enable USB for existing boards
> >>>>>>>> sunxi: Pine64: DTS: enable USB PHY 0 for HCI0
> >>>>>>>
> >>>>>>> Except 6/6 (it can be part of DTS sync during MW) and rest
> >>>>>>>
> >>>>>>> Reviewed-by: Jagan Teki <jagan at amarulasolutions.com>
> >>>>
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> >> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190619110302.7c4ea7e8%40donnerap.cambridge.arm.com.
> >> For more options, visit https://groups.google.com/d/optout.
>
More information about the U-Boot
mailing list