Hi André, On Thu, 20 Jun 2019 at 23:18, André Przywara <andre.przyw...@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.przyw...@arm.com> wrote: > >> > >> On Wed, 19 Jun 2019 10:57:14 +0200 > >> Clément Péron <peron.c...@gmail.com> wrote: > >> > >> Hi, > >> > >>> On Wed, 19 Jun 2019 at 03:04, André Przywara <andre.przyw...@arm.com> > >>> wrote: > >>>> > >>>> On Tue, 18 Jun 2019 19:22:34 +0200 > >>>> Clément Péron <peron.c...@gmail.com> wrote: > >>>> > >>>> Hi, > >>>> > >>>> > >>>>> On Tue, 18 Jun 2019 at 19:08, Clément Péron <peron.c...@gmail.com> > >>>>> wrote: > >>>>>> > >>>>>> Hi Andre, > >>>>>> > >>>>>> On Tue, 18 Jun 2019 at 09:50, Jagan Teki <ja...@amarulasolutions.com> > >>>>>> wrote: > >>>>>>> > >>>>>>> On Thu, May 16, 2019 at 6:56 AM Andre Przywara > >>>>>>> <andre.przyw...@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@4020000: 0, mmc@4022000: 1 > >>>>>> Loading Environment from FAT... Unable to use mmc 1:1... In: > >>>>>> serial@5000000 > >>>>>> Out: serial@5000000 > >>>>>> Err: serial@5000000 > >>>>>> Net: No ethernet found. > >>>>>> starting USB... > >>>>>> Bus usb@5101000: USB EHCI 1.00 > >>>>>> Bus usb@5101400: USB OHCI 1.0 > >>>>>> scanning bus usb@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 <ja...@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+unsubscr...@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. > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot