• Content Count

  • Joined

  • Last visited

  1. Hi everyone, brace yourselves this a breakdown of the efforts I have made so far to turn the espressobin into a usb device. The armada3720 soc on the espressobin contains a usb 3 and a usb 2 device controller. I have been trying to enable them in order to turn the espressobin into a usb network adapter of sorts or a usb mass storage device. This may indeed be an impossibility, and I would love to hear any arguments as to why it is impossible. Thus far here are the main issues as I understand them so far: 1. The espressobin does not have a usb type b port, which is generally viewed as requirement for a usb device. However since there are other pieces of hardware that use the type A female interface in device mode maybe this is possible with the espressobin too. The rockpi 4 has a Type A interface that can be put in device mode using a switch for example. Maybe the espressobin can turn put the port into device mode using software instead of a hardware switch. 2. Though the 4.4.x kernels have some sort of support for the usb3 device controller on the espressobin, neither mainline nor the marvell 4.14 kernel do. Which may indicate that the feature does not actually work or will not be supported longer term. 3. I can't get it work: Test methodology so far: a) Compile u-boot version 2018.03-armada-18.12 to put comphy lane0 in to device mode in dts file - see patch 0001 below b) Compile Marvell 4.4.52 kernel with host controller disabled and device controllers enabled, lane 0 comphy configured in various modes: COMPHY_USB3, and a few others, though I don't actually know what they are in any human decipherable form ... patch 0005) - To be more specific according to include/dt-bindings/phy-comphy-mvebu.h a device mode is defined which one would think would work for the usb device controller: line 73 #define COMPHY_USB3D0 COMPHY_DEF(COMPHY_USB3D_MODE, COMPHY_UNIT_ID0, \ COMPHY_SPEED_DEFAULT, COMPHY_POLARITY_NO_INVERT) - However if I set the mode of the comphy to COMPHY_USB3D0 in the armada-3720-community.dts file in the 4.4.52 kernel, the kernel boots and says that it is the "Wrong mode for the phy" - Once this happened I was only able to determine the hex values for compatible modes by inserting some debug codes into the drivers/usb/gadget/udc/mvebu_u3d.c driver code and recompiling. - The hex values for the comphy modes I have been testing are summarised in patch 0002 below - So here is where I am now, I am configuring the u3d device to use comphy mode that is in a valid mode, but may or may not be in a vdevice mode and attempting to test the kernel as a usb device. The good news is that the controllers are visible by the kernel. /sys/class/udc becomes populated with two device controllers one for the usb3 and one for usb2 d0050000.u3d and d0054100.udc respectively. - To configure them I use the ag (short for add gadget) script attached this script works fine on other machines. - RESULT: i) On linux machines as the host end absolutely no sign that there is a usb device connected when either using a usb-A male to type-C cable or a USB-A male to USB-A male cable ii) On windows machines as the host end I get "Usb device malfunctioned because it did not respond to a port reset" or something along those lines iii) On the espressobin as a device, I see "USB Device: disconnected" after the gadget seems to be initialized to some degree, but is saying it is disconnected because there is no signal on the vbus or something. a) When I change the checkvbus function to fake the vbus being connected, I can see that the controller is trying to pullup some dp or dn lines on the usb controller and I am able to see a "USB Device: connected" line being printed but still there is absolutely no indication that there is a device connected on a linux machine as the usb host as in RESULT(i) Summary: The main suspects 1) Neither udc or u3d are connected physically to the usb hosts ports at all, neither the usb2 or the usb3 type a female ports, thus no amount of reconfiguration will casue them to allow the espressobin to act as a device. 2) the lane 0 settings are not set correctly, I have not been assigning the COMPHY the appropriate hex value as outlined in patch 0002, they may even need to be connected in host modes instead of device modes since the espressobin does not actually have a Type B port on the outside only two USB Type A and micro usb a/b. 3) I have somehow misconfigured the utmi (like the lane 0 comphy, utmi32 can be configured to used in a device mode see patch 0004 and then referenced by the usb2 device controller see patch 0005. INCIDENTALLY: The armada-3720 also supports a usb OTG mode whereby the usb3 xhci device, u3d and udc devices are enabled simultaneously in the armada-3720-community.dts file and a usb-phy is also created and enabled as described in the 4.4.52 documentation file: Documentation/devicetree/bindings/usb/armada3700-usb-phy.txt , I have tried this technique by enabling the OTG option in the kernel and then following the directions in a3700-usb-phy.txt, but did not really get anywhere, with similar results of nothing being detected by a linux usb host machine. Patch 0001 --- a/arch/arm/dts/armada-3720-espressobin.dts +++ b/arch/arm/dts/armada-3720-espressobin.dts @@ -60,7 +60,7 @@ &comphy { max-lanes = <3>; phy0 { - phy-type = <COMPHY_TYPE_USB3>; + phy-type = <COMPHY_TYPE_USB3_DEVICE>; phy-speed = <COMPHY_SPEED_5G>; }; Patch 0002 diff --git a/arch/arm64/boot/dts/marvell/armada-3720-community.dts b/arch/arm64/boot/dts/marvell/armada-3720-community.dts index 844e46bcfc95..82a241528a86 100644 --- a/arch/arm64/boot/dts/marvell/armada-3720-community.dts +++ b/arch/arm64/boot/dts/marvell/armada-3720-community.dts @@ -114,7 +114,13 @@ u3d@50000 { status = "okay"; - phys = <&a3700_comphy 0 COMPHY_USB3>; + /* NUM1 phys = <&a3700_comphy 0 0x21fc>; */ + /* NUM2 phys = <&a3700_comphy 0 0x31fc>; */ + phys = <&a3700_comphy 0 0xa0fc>; /* NUM3 */ + /* Either NUM1,NUM2,NUM3 corresponds to mode COMPHY_USB3 because + these are the only three modes and I have tested, are available for the lane according to mvebu_u3d.c, and + setting phys = <&a3700_comphy 0 COMPHY_USB3> works without causing the kernel to complain. + */ phy-names = "usb"; }; Patch 0003 diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi index e6f170ae2b39..cb8784456978 100644 --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi @@ -375,7 +375,7 @@ utmi_usb32: utmi@5d000 { compatible = "marvell,armada-3700-utmi-phy"; reg = <0x5d000 0x1000>; - utmi-port = <UTMI_PHY_TO_USB3_HOST0>; + utmi-port = <UTMI_PHY_TO_USB3_DEVICE0>; #phy-cells = <0>; status = "disabled"; }; Patch 0005 --- a/arch/arm64/boot/dts/marvell/armada-3720-community.dts +++ b/arch/arm64/boot/dts/marvell/armada-3720-community.dts @@ -113,20 +113,26 @@ }; u3d@50000 { - status = "disabled"; - phys = <&a3700_comphy 0 COMPHY_USB3>; + status = "okay"; + /* NUM1 phys = <&a3700_comphy 0 0x21fc>; */ + /* NUM2 phys = <&a3700_comphy 0 0x31fc>; */ + phys = <&a3700_comphy 0 0xa0fc>; /* NUM3 */ + /* Either NUM1,NUM2,NUM3 corresponds to mode COMPHY_USB3 because + these are the only three modes and I have tested + phys = <&a3700_comphy 0 COMPHY_USB3> and the kernel does not complain + */ phy-names = "usb"; }; udc@54100 { - status = "disabled"; + status = "okay"; phys = <&utmi_usb32>; phy-names = "usb"; }; usb3@58000 { compatible = "generic-xhci"; - status = "okay"; + status = "disabled"; phys = <&utmi_usb32>, /* utmi usb32 dedicated phy */ <&a3700_comphy 0 COMPHY_USB3>; /* usb3 comphy */ phy-names = "usb2", "usb3"; ag
  2. Hi Everyone, Presently I am running a number of espressobins as wireless access point using openwrt. Similar to how armbian provision's the espressobin's network interfaces openwrt seems to disable the topaz switch of the espressobin and then create three individual network adapters wan, lan0 and lan1. I have run into a problem where clients can join the wireless networks which the espressobin's provide but when I roam, that is disconnect a wireless client from one and then connect to another the wireless client will not be able to obtain a DHCP address for 5 minutes. I have noticed that once the message "bridge topology change detected: propogating tcn bdpu" in the log messages. Once this message appears the wireless clients appear to be able to obtain a DHCP address. Presumably since openwrt bridges the wireless adapter (wlan0) with the wan adapter which is the uplink port (wan interface) for each on each espressobin wireless access point, the bridge (br-wan) may be somehow allowing the DHCPOFFER packets to traverse the bridge once the arp entries have timedout. The problem is that there is no indication from the arp tables of the espressobin's that this is indeed what is happening. According to the arptables for br-wan (wlan0 and wan bridged together) as a wireless client roams the arp entries seem to changed well before the bridge topology log message appears and according to these tables the bridge appears to behave as expected. It appears that armbian does the same thing that openwrt does, turns off the topaz switch and creates three separate interfaces. My question is, is it possible that the switch behavior has not been completely turned off and is somehow causing the type of behavior where DHCP and arp traffic is dropped until arp entries timeout as I have described and has been described on the espressobin wiki here: http://espressobin.net/forums/topic/are-lan0-and-lan1-bridged-in-hardware/ ? Thanks SOLVED/WORKAROUND: I expermimented with setting the ageing parameter of the bridge between the wlan0 and wan to a much lower value 1000 instead of 30000, this allowed for fast roaming between the APs or at least a much lower delay because the arp entries for the clients will timeout more quickly. This parameter is set in /sys/class/net/br-wan/bridge/ageing or something like that.