search

ayufan-rock64 / linux-build

Rock64 Linux build scripts, tools and instructions
MIT License
561 stars 98 forks source link

usb otg ethernet gadget #117

Closed kfox1111 closed 5 years ago

kfox1111 commented 6 years ago

I'd like to switch the otg port on the rock64 in xenial to regular otg instead of host and load the cdc_ethernet driver. Finding it difficult to find info on this. Any ideas?

kfox1111 commented 6 years ago

ping

xalius commented 6 years ago

What have you tried so far? What happens when you load the usb gadget drivers? Before this works you probably have to reconfigure the top USB port in the devicetree as either OTG or device mode port.

ghost commented 6 years ago

Any update on this? I'm trying to figure out if the USB3.0 port supports device mode.

ayufan commented 6 years ago

Afaik. Nope. Otg is only on usb2.0

On Thu, 24 May 2018 at 05:06, R0b0t1 notifications@github.com wrote:

Any update on this? I'm trying to figure out if the USB3.0 port supports device mode.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ayufan-rock64/linux-build/issues/117#issuecomment-391573333, or mute the thread https://github.com/notifications/unsubscribe-auth/ACTpQYWgOZrjmUxH2yqr7DdYX1pEgsYpks5t1iO8gaJpZM4SZZae .

dernyn commented 6 years ago

I don't know if it's a language problem; but, kfox1111 question has not been answered.

I think what he is asking is how to install/configure the driver to make the built-in USB 2.0 OTG controller work with your distro as a USB network interface, using the build-in DWC OTG Controller.

I too, thought the Single USB 3.0 port was OTG capable, but it's not.. if you run this command: lsusb -vvv

you will see the type of hardware USB controllers on board the ROC-RK3328-CC (ROCK64)

"ID 1d6b:0003 Linux Foundation 3.0 root hub" "SuperSpeed (5GBps)" The USB 3.0 Controller is a standard, xHCI Host Controller. unlike the Top-most port USB 2.0 DWC OTG Controller (dwc2_hsotg)

what he is really asking is,.... if somehow, you can modify the kernel/driver into forcing the native USB 3.0 controller to be detected and used as a OTG controller, in order to get a faster gadget mode USB 3.0 network card working, instead of the USB 2.0 version from the (ROCK64) ROC-RK3328-CC.

dernyn commented 6 years ago

it seems the USB 3.0 DWC3 is supported by the Synopsys DesignWare USB Core Controller inside the RK3328, it just has to be enabled before boot-up.

CONFIG_USB_XHCI_DWC3=y

this person enabled the changes from your files: https://github.com/daijh223/linux-u-boot/

OpenSUSE supports out of the box, it seems to be in the u-boot init startup module/config.

google "rk3328-evb.dts dwc3"

├── rockchip │ │ ├── rk3328-evb.dtb │ │ ├── rk3328-rock64.dtb

arch/arm64/boot/dts/rockchip/rk3328-evb.dts arch/arm64/boot/dts/rockchip/rk3328-rock64.dts arch/arm64/boot/dts/rockchip/rk3328.dtsi

kfox1111 commented 6 years ago

Sorry for the late reply. I somehow have not been getting emails on this thread.

Before this works you probably have to reconfigure the top USB port in the devicetree as either OTG or device mode port. Thats my question,. How do I do that? Is there an overlay file somewhere I need?

On the pi, you do it like: https://gist.github.com/gbaman/975e2db164b3ca2b51ae11e45e8fd40a

Thanks, Kevin

dernyn commented 6 years ago

I did a bit more digging on the USB controller and I found that Rockchip disabled the ability to turn the USB 3.0 non-OTG(xHCI) into OTG in the rk3328 in the U-boot firmware long ago, The feature was there and you can kinda bring it back with patches, but it triggered issues in software due to IRQ and reserve memory addresses. I was able to confirm that the USB 3.0 controller is not natively an OTG controller in hardware.

Please keep in mind that the architecture of this chip is not the same architecture of the RPI, this chip requires U-boot to set the correct setting before it even booted.

Also the firefly version uses DDR4 which the changes have been made to function correctly with u-boot.

To get the native USB 2.0 OTG, you need to compile the mainline Linux source and install & configure the drivers. This is not chip dependent (other than the OTG abilities for DWC2)and you can try to find information in Linux forums.

kfox1111 commented 6 years ago

yeah, I'm trying to do it with the usb2 port that is designated for otg. I think its just a devicetree change, (or better yet devicetree overlay) but not entirely sure whats needed though. I managed to get it updated to have the spi uboot and to run a stable armbian a few minutes ago, so at least I can test with something more modern now.

kfox1111 commented 6 years ago

do I need to override: usb@ff580000 dr_mode to be otg?

kfox1111 commented 6 years ago

https://github.com/raspberrypi/linux/blob/rpi-4.4.y/arch/arm/boot/dts/overlays/dwc2-overlay.dts looks interesting. could we make a file like this for the rock64?

kfox1111 commented 6 years ago

I decompiled the device tree, set dt_mode to otg, and rebuilt it. added: extraargs=dwc2,g_ether to armbianEnv.txt and rebooted. I see it in the /proc/cmdline and /proc/device-tree/usb@ff580000/dr_mode.

no joy.

kfox1111 commented 6 years ago

hmm... while I'm asking.... a usb-a to usb-a is a pretty odd type of cable. do I need a straight or a cross over cable or something else?

kfox1111 commented 6 years ago

I swapped the two data wires making a crossover cable, and got a little farther:

dmesg on the laptop showed: [13033.103522] usb 1-1: new low-speed USB device number 22 using xhci_hcd [13033.265421] usb 1-1: device descriptor read/64, error -71 [13033.520479] usb 1-1: device descriptor read/64, error -71 [13033.774560] usb 1-1: new low-speed USB device number 23 using xhci_hcd [13033.928388] usb 1-1: device descriptor read/64, error -71 [13034.183586] usb 1-1: device descriptor read/64, error -71 [13034.437581] usb 1-1: new low-speed USB device number 24 using xhci_hcd [13034.438997] usb 1-1: Device not responding to setup address. [13034.641128] usb 1-1: Device not responding to setup address. [13034.841427] usb 1-1: device not accepting address 24, error -71 [13034.994365] usb 1-1: new low-speed USB device number 25 using xhci_hcd [13034.995983] usb 1-1: Device not responding to setup address. [13035.197984] usb 1-1: Device not responding to setup address. [13035.398323] usb 1-1: device not accepting address 25, error -71 [13035.398356] usb usb1-port1: unable to enumerate USB device

Nothing on the rock64 either with the normal dtb or the one with otg dt_mode.

ghost commented 6 years ago

That is the error one receives if the data wires are backwards. If the controller supports device mode you don't need a crossover cable; crossover cables don't really exist for USB like they do for serial or ethernet connections. (People sell devices they call "USB crossover cables" but those are typically two serial converters to allow file transfers.)

kfox1111 commented 6 years ago

the thing that is confusing to me is otg requires a sense line for switching between host mode and device mode. My understanding is the port is configured for host mode out of the box and there is physically no connection for a usb A cable to tell the rock64 it needs to be in device mode. So I'm struggling to figure out how to set it into device mode. did I miss something/overthinking something?

ghost commented 6 years ago

Having the port configured for host mode is different than having it configured for OTG mode which is different than having it configured for device mode. For OTG and device mode you need to supply a set of device mode configurations. When in OTG mode the controller detects if it has been plugged into a host or a device and responds appropriately. The electrical characteristics of the USB wires change depending on what is being plugged into what. The wiring is always the same.

kfox1111 commented 6 years ago

ah. so, I probably want device mode instead of otg mode as there is no sense wire. I'll try setting the dr_mode to device once I get access to it.

Any other ideas on how to configure the kernel to use it in that mode? Will linux just detect its in device mode, or do I need to bind things to it somehow? I've only ever used dwc2,g_* config.

kfox1111 commented 6 years ago

ok. I got a new rock64 (fried the old one a bit.) and a new usb cable from pine64. So, should be the right hardware for sure.

I tried lspci before making any changes:

root@rock64:~# lsusb                                                            
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub                  
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub                  
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub                  
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub                  
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I then tried setting the dr_mode of usb@ff580000 to peripheral root@rock64:~# lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

So it dropped out. Not sure if this is expected or not. it did apply too:

root@rock64:~# cat /proc/device-tree/usb@ff580000/dr_mode                       
peripheral

I then plug in the cable to a linux box with the top usb port on the rock64. Nothing shows up on dmesg on either box.

So, still no joy.

For good measure, I tried it with the string 'device' too. didn't work either.

I verified we have a CDC driver loaded: grep CDCETHER -i /boot/config-4.4.124-rk3328
CONFIG_USB_NET_CDCETHER=y

anyone have any other ideas?

dernyn commented 6 years ago

you need a -- capacitor on id pin. gnd-cap-pin

you need to find the ID pin for USB2 on your board, add a capacitor on the ID pin , going to ground. this will trigger auto detect of host.

see "otg dwc capacitor on id pin" on google.

dernyn commented 6 years ago

https://linux-sunxi.org/Pine64#FEL_mode when this ID pin is missing

kfox1111 commented 6 years ago

caping the pin would probably work yeah. But software seems to be able to switch the port between host and peripheral mode. There is mention of adb support for android, so it must be switching the port over to peripheral mode too. So I think the extra hardware is unneeded if I can figure out the right way to configure the devicetree.

kfox1111 commented 6 years ago

the rockchip seems to have a FEL equivalent mode called rockusb which also forces the usb port into peripheral mode. So no extra hardware should be needed?

kfox1111 commented 6 years ago

ok. got a little bit further maybe. when I set it into peripheral mode, and the usb entry dropped out, it didn't notice this in dmesg:

[    1.441297] dwc2 ff580000.usb: 128 invalid for host_nperio_tx_fifo_size. Check HW configuration.
[    1.441315] dwc2 ff580000.usb: 256 invalid for host_perio_tx_fifo_size. Check HW configuration.

So it probably needs some other things in addition to just dr_mode.

I noticed a thread on rk3328 support saying that back when it was first introduced, it only supported peripheral mode, not host mode. So It really can be done.

Maybe if I can find that version of the device tree, and use its usb config, it might work.

kfox1111 commented 6 years ago

This may be related https://patchwork.kernel.org/patch/9248697/

kfox1111 commented 6 years ago

ok. I think I'm starting to understand the device-tree stuff more. I'm currently thinking that the dwc2 driver itself isn't handling the switchover to peripheral mode properly.

kfox1111 commented 6 years ago

I just built an armbian kernel in dev mode. it didn't complain anymore in peripheral mode, but still doesn't show up in lsusb. [ 0.600507] dwc2 ff580000.usb: ff580000.usb supply vusb_d not found, using du mmy regulator [ 0.600571] dwc2 ff580000.usb: ff580000.usb supply vusb_a not found, using du mmy regulator [ 0.602787] dwc2 ff580000.usb: EPs: 10, dedicated fifos, 972 entries in SPRAM

kfox1111 commented 6 years ago

4.18.0-rc8-rockchip64

kfox1111 commented 6 years ago

ok. got debugging enabled on 4.18.-rc8-rockchip64, and a bunch of other modules built: [ 0.602547] dwc2 ff580000.usb: mapped PA ff580000 to VA (ptrval) [ 0.602610] dwc2 ff580000.usb: ff580000.usb supply vusb_d not found, using dummy regulator [ 0.602688] dwc2 ff580000.usb: ff580000.usb supply vusb_a not found, using dummy regulator [ 0.602754] dwc2 ff580000.usb: registering common handler for irq31 [ 0.604859] dwc2 ff580000.usb: dwc2_core_reset() [ 0.604874] dwc2 ff580000.usb: Core Release: 3.10a (snpsid=4f54310a) [ 0.604883] dwc2 ff580000.usb: Forcing mode to device [ 0.604891] dwc2 ff580000.usb: Waiting for device mode [ 0.604899] dwc2 ff580000.usb: Device mode set [ 0.604908] dwc2 ff580000.usb: Forcing mode to device [ 0.604915] dwc2 ff580000.usb: Waiting for device mode [ 0.604921] dwc2 ff580000.usb: Device mode set [ 0.604952] dwc2 ff580000.usb: NonPeriodic TXFIFO size: 16 [ 0.604959] dwc2 ff580000.usb: RXFIFO size: 280 [ 0.604984] dwc2 ff580000.usb: EPs: 10, dedicated fifos, 972 entries in SPRAM [ 0.605758] dwc2 ff580000.usb: DCFG=0x08100000, DCTL=0x00000002, DIEPMSK=00000000 [ 0.605768] dwc2 ff580000.usb: GAHBCFG=0x00000000, GHWCFG1=0x00006664 [ 0.605777] dwc2 ff580000.usb: GRXFSIZ=0x00000400, GNPTXFSIZ=0x00100400 [ 0.605786] dwc2 ff580000.usb: DPTx[1] FSize=256, StAddr=0x00000410 [ 0.605794] dwc2 ff580000.usb: DPTx[2] FSize=256, StAddr=0x00000900 [ 0.605803] dwc2 ff580000.usb: DPTx[3] FSize=256, StAddr=0x00000a00 [ 0.605811] dwc2 ff580000.usb: DPTx[4] FSize=256, StAddr=0x00000b00 [ 0.605821] dwc2 ff580000.usb: DPTx[5] FSize=256, StAddr=0x00000c00 [ 0.605829] dwc2 ff580000.usb: DPTx[6] FSize=256, StAddr=0x00000d00 [ 0.605838] dwc2 ff580000.usb: DPTx[7] FSize=0, StAddr=0x00000e00 [ 0.605847] dwc2 ff580000.usb: DPTx[8] FSize=0, StAddr=0x00000f00 [ 0.605856] dwc2 ff580000.usb: DPTx[9] FSize=256, StAddr=0x00000410 [ 0.605867] dwc2 ff580000.usb: ep0-in: EPCTL=0x00008800, SIZ=0x00000000, DMA=0xf1c882bc [ 0.605877] dwc2 ff580000.usb: ep0-out: EPCTL=0x00008000, SIZ=0x00000000, DMA=0xbc63b000 [ 0.605887] dwc2 ff580000.usb: ep1-in: EPCTL=0x00001000, SIZ=0x00000000, DMA=0x7fc906b4 [ 0.605899] dwc2 ff580000.usb: ep1-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0xd30ad39e [ 0.605908] dwc2 ff580000.usb: ep2-in: EPCTL=0x00000000, SIZ=0x00000000, DMA=0xe5ec0858 [ 0.605919] dwc2 ff580000.usb: ep2-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0x54a22fae [ 0.605929] dwc2 ff580000.usb: ep3-in: EPCTL=0x00002000, SIZ=0x00000000, DMA=0x9b975a34 [ 0.605940] dwc2 ff580000.usb: ep3-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0xd30ad39e [ 0.605951] dwc2 ff580000.usb: ep4-in: EPCTL=0x00000000, SIZ=0x00000000, DMA=0xe5ec0858 [ 0.605961] dwc2 ff580000.usb: ep4-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0xaa38f516 [ 0.605971] dwc2 ff580000.usb: ep5-in: EPCTL=0x00003000, SIZ=0x00000000, DMA=0x476413d7 [ 0.605982] dwc2 ff580000.usb: ep5-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0xd30ad39e [ 0.605992] dwc2 ff580000.usb: ep6-in: EPCTL=0x00000000, SIZ=0x00000000, DMA=0xe5ec0858 [ 0.606003] dwc2 ff580000.usb: ep6-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0x4d0f544a [ 0.606014] dwc2 ff580000.usb: ep7-in: EPCTL=0x00004000, SIZ=0x00000000, DMA=0xd3ea4dfe [ 0.606024] dwc2 ff580000.usb: ep7-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0xd30ad39e [ 0.606034] dwc2 ff580000.usb: ep8-in: EPCTL=0x00004800, SIZ=0x00000000, DMA=0xd2251f41 [ 0.606044] dwc2 ff580000.usb: ep8-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0xe5d9e575 [ 0.606055] dwc2 ff580000.usb: ep9-in: EPCTL=0x00005000, SIZ=0x00000000, DMA=0xf1503d74 [ 0.606066] dwc2 ff580000.usb: ep9-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0x0715383a [ 0.606075] dwc2 ff580000.usb: DVBUSDIS=0x00000b8f, DVBUSPULSE=000002c6

modprobe g_ether

[ 220.140908] using random self ethernet address [ 220.140914] using random host ethernet address [ 220.141598] usb0: HOST MAC 16:a3:48:07:dc:90 [ 220.141878] usb0: MAC ee:8b:9a:a9:63:0c [ 220.141925] using random self ethernet address [ 220.141928] using random host ethernet address [ 220.141992] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008 [ 220.141996] g_ether gadget: g_ether ready [ 220.144070] dwc2 ff580000.usb: bound driver g_ether [ 220.144082] dwc2 ff580000.usb: dwc2_hsotg_pullup: is_on: 1 op_state: 3 [ 220.144088] dwc2 ff580000.usb: dwc2_core_reset() [ 220.144102] dwc2 ff580000.usb: FIFOs reset, timeout at 100 [ 220.144114] dwc2 ff580000.usb: EP0: DIEPCTL0=0x00008000, DOEPCTL0=0x00008000 [ 220.144118] dwc2 ff580000.usb: gsintmsk now 0xd88c3cc4 [ 220.144136] dwc2 ff580000.usb: DCTL=0x00000002 [ 220.144143] dwc2 ff580000.usb: GLPMCFG=0x10001483 [ 220.147148] dwc2 ff580000.usb: dwc2_hsotg_enqueue_setup: queueing setup request [ 220.147157] dwc2 ff580000.usb: ep0: req 00000000df9135a5: 8@000000005d5020bd, noi=0, zero=0, snok=0 [ 220.147169] dwc2 ff580000.usb: dwc2_hsotg_start_req: DxEPCTL=0x80008000, ep 0, dir out [ 220.147175] dwc2 ff580000.usb: ureq->length:8 ureq->actual:0 [ 220.147181] dwc2 ff580000.usb: dwc2_hsotg_start_req: 1@8/8, 0x00080008 => 0x00000b10 [ 220.147188] dwc2 ff580000.usb: dwc2_hsotg_start_req: fe202000 pad => 0x00000b14 [ 220.147192] dwc2 ff580000.usb: ep0 state:0 [ 220.147196] dwc2 ff580000.usb: dwc2_hsotg_start_req: DxEPCTL=0x80008000 [ 220.147202] dwc2 ff580000.usb: dwc2_hsotg_start_req: DXEPCTL=0x80008000 [ 220.147208] dwc2 ff580000.usb: EP0: DIEPCTL0=0x00008000, DOEPCTL0=0x80008000 [ 220.150299] dwc2 ff580000.usb: dwc2_hsotg_irq: 04008420 00000400 (d88c3cc4) retry 8 [ 220.150307] dwc2 ff580000.usb: GINTSTS_ErlySusp [ 220.153360] dwc2 ff580000.usb: gintsts=04008820 gintmsk=d88c3cc4 [ 220.153371] dwc2 ff580000.usb: USB SUSPEND [ 220.153377] dwc2 ff580000.usb: dwc2_handle_usb_suspend_intr: DSTS=0x400003 [ 220.153383] dwc2 ff580000.usb: DSTS.Suspend Status=1 HWCFG4.Power Optimize=1 HWCFG4.Hibernation=0 [ 220.153387] dwc2 ff580000.usb: ignore suspend request before enumeration [ 220.153395] dwc2 ff580000.usb: dwc2_hsotg_irq: 04008020 00000000 (d88c3cc4) retry 8 [ 226.9405hy phy-ff450000.syscon:usb2-phy@100.0: charger = USB_DCP_CHARGER

I see a usb0 device in 'ip a' on the rock64. But nothing on dmesg on either host when I connect the usb cable to the laptop still.

kfox1111 commented 6 years ago

hmm... I just tried unloading the g_ether module, then preconnected the usb cable, then reloaded g_ether. I did see this on the laptop: [257696.847231] usb 1-4: New USB device found, idVendor=0525, idProduct=a4a2 [257696.847240] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [257696.847247] usb 1-4: Product: RNDIS/Ethernet Gadget [257696.847252] usb 1-4: Manufacturer: Linux 4.18.0-rc8-rockchip64 with ff580000.usb [257696.882545] cdc_eem 1-4:1.0 usb0: register 'cdc_eem' at usb-0000:00:14.0-4, CDC EEM Device, 86:d7:fc:93:29:c7 [257696.882996] usbcore: registered new interface driver cdc_eem [257696.885258] usbcore: registered new interface driver cdc_subset [257697.635172] IPv6: ADDRCONF(NETDEV_UP): enp0s20f0u4: link is not ready [257697.635337] cdc_eem 1-4:1.0 enp0s20f0u4: kevent 12 may have been dropped [257702.570690] usb 1-4: USB disconnect, device number 24 [257702.570977] cdc_eem 1-4:1.0 enp0s20f0u4: unregister 'cdc_eem' usb-0000:00:14.0-4, CDC EEM Device

I saw enp0s20f0u4 show up for a few seconds, then drop back out. Much closer now...

kfox1111 commented 6 years ago

maybe network manager is messing with me a bit... Will try without it.

kfox1111 commented 6 years ago

ok. finally some progress...

Its pretty touchy it seems. If I do it in this order, it seems to work:

  1. on the laptop modprobe usbnet
  2. boot the rock64 with usb cable already connected
  3. modprobe g_ether on the rock64.
kfox1111 commented 6 years ago

Actually, it seems to fail the first time after init... So,

  1. on the laptop modprobe usbnet
  2. boot the rock64 with usb cable already connected
  3. modprobe g_ether on the rock64
  4. rmmod g_ether
  5. modprobe g_ether

Then it works. The laptop complains about lack of connectivity during the first modprobe. Guessing it has something to do with the dwc2 init process?

With the debugging turned off, I'm getting about ~200mbit/s from the laptop to the rock64 and ~130 back via iperf3.

Maybe some buffer tweaking is needed?

kfox1111 commented 5 years ago

Hi @tttteatree I dont quite have a full process yet ironed out. I've had to try so many things, that some things that I have done may or may not be optional to get it to work. Also, I would like to contribute back a device tree overlay at some point, if I can figure out how to make those work instead of hacking up the existing device tree to set the settings. that would be much cleaner. I also got to the point where I switched to a dev kernel for testing and am not sure it works on a stock kernel. a stock kernel might work now. but, a procedure like the following should work (recalling from memory so might need slight tweaking for paths and things):

At this point in theory it should be good to go for usb gadget mode.

see my previous post for some of the weird ordering I had to do to get the two hosts to detect each other though. I think that may be a kernel driver bug that still needs to be tracked down.

Good luck. :)

tttteatree commented 5 years ago

@kfox1111 thank you. I'll update you on how it goes, likely weeks from now when I receive my order.

gauthamkantharaju commented 5 years ago

@kfox1111 have rock64 board, flashed Ubuntu 18.04 Bionic minimal 64bit Image booting off of sd-card. Updated rk3328-rock64.dts

&usb20_otg {
    dr_mode = "**peripheral**";
    status = "okay";
};

compiled and updated rk3328-rock64.dtb. Connected usb (type A) cable, rock64 USB 2.0 OTG port - latop. Laptop couldn't detect the usb-serial connection though.

There are a rock64 USB 2.0 controller configuration in menuconfig under "USB Support".

rock64-usb-2 0-controller

If enabled, error while building linux kernel,

LD drivers/power/built-in.o CC [M] drivers/usb/dwc_otg_310/dwc_otg_driver.o drivers/usb/dwc_otg_310/dwc_otg_driver.c: In function ‘dwc_otg_driver_init’: drivers/usb/dwc_otg_310/dwc_otg_driver.c:1690:6: warning: unused variable ‘error’ [-Wunused-variable] error, forbidden warning:dwc_otg_driver.c:1690 int error; ^~~~~ At top level: drivers/usb/dwc_otg_310/dwc_otg_driver.c:1181:13: warning: ‘dwc_otg_driver_shutdown’ defined but not used [-Wunused-function] error, forbidden warning:dwc_otg_driver.c:1181 static void dwc_otg_driver_shutdown(struct platform_device _dev) ^~~~~~~ drivers/usb/dwc_otg_310/dwc_otg_driver.c:1176:12: warning: ‘dwc_otg_driver_resume’ defined but not used [-Wunused-function] error, forbidden warning:dwc_otg_driver.c:1176 static int dwc_otg_driver_resume(struct platform_device _dev) ^~~~~ drivers/usb/dwc_otg_310/dwc_otg_driver.c:1170:12: warning: ‘dwc_otg_driver_suspend’ defined but not used [-Wunused-function] error, forbidden warning:dwc_otg_driver.c:1170 static int dwc_otg_driver_suspend(struct platform_device _dev, ^~~~~~ drivers/usb/dwc_otg_310/dwc_otg_driver.c:844:20: warning: ‘dwc_otg_common_irq’ defined but not used [-Wunused-function] error, forbidden warning:dwc_otg_driver.c:844 static irqreturn_t dwc_otg_common_irq(int irq, void dev) ^~~~~~ drivers/usb/dwc_otg_310/dwc_otg_driver.c:592:12: warning: ‘set_parameters’ defined but not used [-Wunused-function] error, forbidden warning:dwc_otg_driver.c:592 static int set_parameters(dwc_otg_core_if_t *core_if, ^~~~~~ In file included from drivers/usb/dwc_otg_310/dwc_otg_os_dep.h:16:0, from drivers/usb/dwc_otg_310/dwc_otg_driver.c:51: include/linux/device.h:304:26: warning: ‘driver_attr_vbus_status’ defined but not used [-Wunused-variable] error, forbidden warning:device.h:304 struct driver_attribute driverattr##_name = ATTR(_name, _mode, _show, _store) ^ drivers/usb/dwc_otg_310/dwc_otg_driver.c:586:8: note: in expansion of macro ‘DRIVER_ATTR’ static DRIVER_ATTR(vbus_status, S_IRUGO, vbus_status_show, NULL); ^~~ include/linux/device.h:304:26: warning: ‘driver_attr_op_state’ defined but not used [-Wunused-variable] error, forbidden warning:device.h:304 struct driver_attribute driverattr##_name = __ATTR(_name, _mode, _show, _store) ^ drivers/usb/dwc_otg_310/dwc_otg_driver.c:574:8: note: in expansion of macro ‘DRIVER_ATTR’ static DRIVER_ATTR(op_state, S_IRUGO, dwc_otg_op_state_show, NULL); ^~~ include/linux/device.h:304:26: warning: ‘driver_attr_dwc_otg_conn_en’ defined but not used [-Wunused-variable] error, forbidden warning:device.h:304 struct driver_attribute driverattr##_name = ATTR(_name, _mode, _show, _store) ^ drivers/usb/dwc_otg_310/dwc_otg_driver.c:538:8: note: in expansion of macro ‘DRIVER_ATTR’ static DRIVER_ATTR(dwc_otg_conn_en, S_IRUGO | S_IWUSR, dwc_otg_conn_en_show, ^~~ include/linux/device.h:304:26: warning: ‘driver_attr_force_usb_mode’ defined but not used [-Wunused-variable] error, forbidden warning:device.h:304 struct driver_attribute driverattr##_name = __ATTR(_name, _mode, _show, _store) ^ drivers/usb/dwc_otg_310/dwc_otg_driver.c:509:8: note: in expansion of macro ‘DRIVER_ATTR’ static DRIVER_ATTR(force_usb_mode, S_IRUGO | S_IWUSR, force_usb_mode_show, ^~~ include/linux/device.h:304:26: warning: ‘driver_attr_debuglevel’ defined but not used [-Wunused-variable] error, forbidden warning:device.h:304 struct driver_attribute driverattr##_name = ATTR(_name, _mode, _show, _store) ^ drivers/usb/dwc_otg_310/dwc_otg_driver.c:345:8: note: in expansion of macro ‘DRIVER_ATTR’ static DRIVER_ATTR(debuglevel, S_IRUGO | S_IWUSR, dbg_level_show, ^~~ include/linux/device.h:304:26: warning: ‘driver_attr_version’ defined but not used [-Wunused-variable] error, forbidden warning:device.h:304 struct driver_attribute driverattr##_name = ATTR(_name, _mode, _show, _store) ^ drivers/usb/dwc_otg_310/dwc_otg_driver.c:320:8: note: in expansion of macro ‘DRIVER_ATTR’ static DRIVER_ATTR(version, S_IRUGO, version_show, NULL); ^~~ scripts/Makefile.build:277: recipe for target 'drivers/usb/dwc_otg_310/dwc_otg_driver.o' failed make[3]: [drivers/usb/dwc_otg_310/dwc_otg_driver.o] Error 1 scripts/Makefile.build:484: recipe for target 'drivers/usb/dwc_otg_310' failed make[2]: [drivers/usb/dwc_otg_310] Error 2 scripts/Makefile.build:484: recipe for target 'drivers/usb' failed make[1]: [drivers/usb] Error 2 Makefile:1031: recipe for target 'drivers' failed make: [drivers] Error 2

Is rock64 OTG port working? am I missing any steps?

Any suggestion is very much appreciated because otg support is the blocker!!

Thank you in advance, Gautham

kfox1111 commented 5 years ago

So, I used xenial for the test. Looks like bionic was made stable since, and they removed the old image. :(

Not sure thats going to be a problem, but it means we can't exactly duplicate the environment.

I'd recommend trying to get usb ethernet working, as we know that can be made to work. Then once that is working, switching out the usb driver for the serial one. That minimizes the changes and might make it quicker to find a solution.

&usb20_otg {
    dr_mode = "**peripheral**";
    status = "okay";
};

Looks good to me, assuming the **'s aren't actually there.

The usb probing seems very broken at least on the kernel I was using. see the post that starts with: "Actually, it seems to fail the first time after init..." for the procedure to get it to work. I tried many different orderings and that was the only one I could use to get it to work. Once that works, you should be able to switch out the ethernet driver for the serial one in the procedure.

Really not sure about the kernel build issue your hitting. Maybe not quite compatible build tooling? I used the armbian docker stuff. I didn't record the commands I used unfortunately. but I think it was something like: ./compile.sh docker BRANCH=dev BOARD=rock64 KERNEL_ONLY=yes

gauthamkantharaju commented 5 years ago

@kfox1111 thank you for the quick reply. Will try out the suggestions and feedback.

gauthamkantharaju commented 5 years ago

@kfox1111 enabled USB Serial gadget with above mentioned dts modification. That's it works like a charm!!

connect usb cable from rock64 OTG port to latop/system (host machine)

rock64: sudo modprobe g_serial /dev/ttyGS0 device node comes up, need to change the device node permission in order to open, read or write to host machine in non root user mode without which throws Permission denied error sudo chmod 666 /dev/ttyGS0

host: [1651113.411363] usb 1-2: new high-speed USB device number 44 using xhci_hcd [1651113.551546] usb 1-2: New USB device found, idVendor=0525, idProduct=a4a7 [1651113.551556] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [1651113.551563] usb 1-2: Product: Gadget Serial v2.4 [1651113.551569] usb 1-2: Manufacturer: Linux 4.4.154-g15aec11-dirty with ff580000.usb [1651113.553023] cdc_acm 1-2:2.0: ttyACM0: USB ACM device

kfox1111 commented 5 years ago

Thats great news. :)

So, next steps, it would be good to figure out how to make the dts changes into a dto device tree overlay file so it can be configured on by enabling it in the armbian config file rather then decompileing/tweaking/recompiling. Then we can maybe get the dto and the usb gadget drivers built by default into armbian images?

ayufan commented 5 years ago

Well. My image already allows that :)

https://github.com/ayufan-rock64/linux-package/blob/master/root-rock64/usr/local/sbin/rock64_enable_eth_gadget.sh

On Wed, Oct 10, 2018 at 8:37 PM kfox1111 notifications@github.com wrote:

Thats great news. :)

So, next steps, it would be good to figure out how to make the dts changes into a dto device tree overlay file so it can be configured on by enabling it in the armbian config file rather then decompileing/tweaking/recompiling. Then we can maybe get the dto and the usb gadget drivers built by default into armbian images?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ayufan-rock64/linux-build/issues/117#issuecomment-428683916, or mute the thread https://github.com/notifications/unsubscribe-auth/ACTpQZ9T_N1t5wO7hLhYIE-vSwYzmOsSks5ujj5QgaJpZM4SZZae .

ayufan commented 5 years ago

Fully dynamic.

On Wed, Oct 10, 2018 at 8:52 PM Kamil Trzciński ayufan@ayufan.eu wrote:

Well. My image already allows that :)

https://github.com/ayufan-rock64/linux-package/blob/master/root-rock64/usr/local/sbin/rock64_enable_eth_gadget.sh

On Wed, Oct 10, 2018 at 8:37 PM kfox1111 notifications@github.com wrote:

Thats great news. :)

So, next steps, it would be good to figure out how to make the dts changes into a dto device tree overlay file so it can be configured on by enabling it in the armbian config file rather then decompileing/tweaking/recompiling. Then we can maybe get the dto and the usb gadget drivers built by default into armbian images?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ayufan-rock64/linux-build/issues/117#issuecomment-428683916, or mute the thread https://github.com/notifications/unsubscribe-auth/ACTpQZ9T_N1t5wO7hLhYIE-vSwYzmOsSks5ujj5QgaJpZM4SZZae .

kfox1111 commented 5 years ago

Very interesting. Thanks for sharing.

One concern I have is that the device could come up in host mode while its plugged into another host port for my use case. with a devicetree overlay at boot, the device would only ever come up in peripheral mode. Do you know if it is actually safe to bring it up in host mode with another host attached?

Looks like your scripts have the exact overlay source file needed to build an on boot overlay though, so we could use that if it was unsafe.

ayufan commented 5 years ago

This issue is resolved, and currently the discussion is around the extras on top of that.

kfox1111 commented 5 years ago

@tttteatree up to you. our use cases are different. I typically use hardware for general purpose things, and use it longer then vendors typically support their hardware. So I try and use linux distributions that don't come from any particular vendor. This means things like security updates can still happen long after the vendor has moved on. If ayufan's image covers all of your requirements, go with that. It will be easier.

kfox1111 commented 5 years ago

yeah, my plan is to try and submit a patch back to armbian at some point to enable all the usb gadget modules by default so it will come in new images. Just haven't had a chance yet.

kfox1111 commented 5 years ago

No worries. I'm new to it too. I'm use to managing x86_64 hardware/software. I've built kernels but hadn't ever looked at device tree until this thread. Interesting stuff.