rpi-4.4.y: Add USB gadget support to Pi Zero

[notro]

Build the dwc2 usb driver as a module to be able to use the USB On-the-Go functionality (supports both host and device/peripheral mode).
Add a specific Device Tree file for Pi Zero with dwc2 enabled in otg mode. Also fix the inverted ACT led.

This requires a change in the bootloader to give the Zero a dtb of it's own. Currently it uses this:

~$ sudo vcdbg log msg
001289.085: Loading 'bcm2708-rpi-b-plus.dtb' from SD card

This PR can be tested by setting the dtb manually in /boot/config.txt:

device_tree=bcm2708-rpi-zero.dtb

Testing

This will give a serial console on a connected computer:

sudo modprobe g_serial
sudo systemctl start getty@ttyGS0.service

On my Windows 8 computer, the USB serial port shows up as: ELMO GMAS (COM5)

Hotswapping to a keyboard works.

Controller fifo

The fifo assignment isn't optimal. This PR uses only 1024 of the 4080 available dynamic fifo entries:

[    8.779556] dwc2 20980000.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM

Currently assigned in Device Tree:

&usb {
    g-np-tx-fifo-size = <32>;
    g-rx-fifo-size = <256>;
    g-tx-fifo-size = <256 128 128 64 64 64 32>;
};

I don't know how to best distribute the remaining entries.

Issue

When I disconnect the keyboard, I get a warning:

[   93.639089] g_serial gadget: Gadget Serial v2.4
[   93.639120] g_serial gadget: g_serial ready
[   93.642186] dwc2 20980000.usb: bound driver g_serial
<connect computer>
[  101.877358] dwc2 20980000.usb: new device is high-speed
[  101.893135] dwc2 20980000.usb: new address 5
[  101.908600] g_serial gadget: high-speed config #2: CDC ACM config
<disconnect computer and connect keyboard>
[  158.138483] usb 1-1: new low-speed USB device number 2 using dwc2
[  158.355959] usb 1-1: New USB device found, idVendor=046d, idProduct=c313
[  158.356001] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  158.356019] usb 1-1: Product: USB Multimedia Keyboard
[  158.356036] usb 1-1: Manufacturer: LITEON Technology
[  158.378340] input: LITEON Technology USB Multimedia Keyboard as /devices/platform/soc/20980000.usb/usb1/1-1/1-1:1.0/0003:046D:C313.0001/input/input0
[  158.441305] hid-generic 0003:046D:C313.0001: input,hidraw0: USB HID v1.10 Keyboard [LITEON Technology USB Multimedia Keyboard] on usb-20980000.usb-1/input0
[  158.454182] input: LITEON Technology USB Multimedia Keyboard as /devices/platform/soc/20980000.usb/usb1/1-1/1-1:1.1/0003:046D:C313.0002/input/input1
[  158.509498] hid-generic 0003:046D:C313.0002: input,hidraw1: USB HID v1.10 Device [LITEON Technology USB Multimedia Keyboard] on usb-20980000.usb-1/input1
<disconnect keyboard>
[  186.039220] usb 1-1: USB disconnect, device number 2
[  186.219073] ------------[ cut here ]------------
[  186.219241] WARNING: CPU: 0 PID: 67 at drivers/usb/dwc2/gadget.c:176 dwc2_hsotg_init_fifo+0x18c/0x1ac [dwc2]()
[  186.219258] Modules linked in: evdev usb_f_acm u_serial g_serial libcomposite cfg80211 rfkill dwc2 udc_core bcm2835_gpiomem bcm2835_wdt uio_pdrv_genirq uio i2c_dev snd_bcm2835 snd_pcm snd_timer snd fuse
[  186.219359] CPU: 0 PID: 67 Comm: kworker/u2:2 Not tainted 4.4.0-rc6+ #2
[  186.219371] Hardware name: BCM2708
[  186.219435] Workqueue: dwc2 dwc2_conn_id_status_change [dwc2]
[  186.219508] [<c0016ccc>] (unwind_backtrace) from [<c0013b3c>] (show_stack+0x20/0x24)
[  186.219548] [<c0013b3c>] (show_stack) from [<c032682c>] (dump_stack+0x20/0x28)
[  186.219584] [<c032682c>] (dump_stack) from [<c00222c8>] (warn_slowpath_common+0x8c/0xc4)
[  186.219613] [<c00222c8>] (warn_slowpath_common) from [<c00223bc>] (warn_slowpath_null+0x2c/0x34)
[  186.219697] [<c00223bc>] (warn_slowpath_null) from [<bf0ae6ac>] (dwc2_hsotg_init_fifo+0x18c/0x1ac [dwc2])
[  186.219831] [<bf0ae6ac>] (dwc2_hsotg_init_fifo [dwc2]) from [<bf0b04e4>] (dwc2_hsotg_core_init_disconnected+0x60/0x35c [dwc2])
[  186.219937] [<bf0b04e4>] (dwc2_hsotg_core_init_disconnected [dwc2]) from [<bf0a6824>] (dwc2_conn_id_status_change+0xe8/0x21c [dwc2])
[  186.220001] [<bf0a6824>] (dwc2_conn_id_status_change [dwc2]) from [<c0039c70>] (process_one_work+0x13c/0x490)
[  186.220029] [<c0039c70>] (process_one_work) from [<c003a13c>] (worker_thread+0x178/0x538)
[  186.220064] [<c003a13c>] (worker_thread) from [<c003fee8>] (kthread+0xe0/0xfc)
[  186.220097] [<c003fee8>] (kthread) from [<c000f788>] (ret_from_fork+0x14/0x2c)
[  186.220114] ---[ end trace 900ecfdec3d84a77 ]---
<connect computer>
[  189.792998] dwc2 20980000.usb: new device is high-speed
[  189.808759] dwc2 20980000.usb: new address 13
[  189.831151] g_serial gadget: high-speed config #2: CDC ACM config

Failed on 4.1

I also tried to do this PR on rpi-4.1.y but it didn't work and I didn't try to find out why. Got this error:

[    7.463269] dwc2 20980000.usb: no platform data or transceiver defined

This PR is based on work done by several people in #1212

[notro]

I only get the warning on keyboard disconnect if I have g_serial loaded.

[popcornmix]

Thanks. No objections. @pelwell ?

I did mention the inverted ACT led shortly before launch, but I think Mike liked the inverted, mostly on behaviour due to the absence of a PWR led, so it wasn't fixed then. I still think fixing it is probably the right thing to do, but we'll see what @pelwell and others think.

[MrEngman]

The ACT led is great how it works at the moment. Ideal as there is no PWR led. Please don't change it.

[notro]

The ACT led is great how it works at the moment. Ideal as there is no PWR led.

In what way ideal, that it works excatly as a PWR led? The trigger can be changed to default-on to mimick a power led.

The problem with the inverted behaviour is that trigger none turns the led on and default-on turns it off. heartbeat gives a strange pulsing, and mmc0 is steady on apart from small "inverted blinks" when there's activity instead of a blink. cpu0 is also strange like mmc0.

There's a DT overlay parameter (act_led_activelow) to change the inversion, but I think that the expected behaviour should be the default.

Available triggers:

~$ cat /sys/class/leds/led0/trigger
none kbd-scrollock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock [mmc0] timer oneshot heartbeat backlight gpio cpu0 default-on input

Change trigger from boot with overlay parameter: act_led_trigger

Change trigger immediately:

~$ echo cpu0 | sudo tee /sys/class/leds/led0/trigger
cpu0

[MrEngman]

I didn't say it works "exactly" as a PWR led, but it does provide a good indication the Pi zer0 is powered. It appears to default to ON indicating the Pi is powered and flashes off when the SD card is being accessed/written.

My Pi zero sat next to me is idle at the moment and the ACT led is lit showing it is being powered. If it is changed to behave like the earlier Pi's that have a seperate PWR led then it would be off and I would not know if it was powered on or not.

Or is this a case of it ain't broke fix it so it is, like the changes to the wifi made over the last few months.

[clivem]

I think the original Zero LED behaviour should stay! I'm more interested in a visual indication that the Zero is being powered than its SDCARD is being accessed. What we have now is a good compromise, only having a single LED available to work with.

[notro]

How about this change which will turn the led on, but keep the correct behaviour for the other triggers?

 &leds {
    act_led: act {
        label = "led0";
-       linux,default-trigger = "mmc0";
+       linux,default-trigger = "default-on";
        gpios = <&gpio 47 1>;
    };
 };

I agree that it's useful to have a power indicator.

Some thoughts on using the act led:
If I were to make a product based around a Zero, I would have turned the led on using dt-blob.bin, indicating that the board is powered (firmware loaded and sdcard funtional).
Then I would have used the trigger "timer" in the dtb causing the led to blink during kernel loading.
At last I would have turned the led steady on when the board was fully funtional.

This way I would now that if the led never lights, there's a power/sdcard problem. If it lights up I know the firmware is loaded.
If it doesn't start blinking, the kernel has failed to load.
If it stays blinking, I know that my app or whatever hasn't started succesfully.
There is also one more diagnostic step, and that would be to switch to the hearbeat pattern as the first thing when userspace loads. To show that systemd has started.
But I have never shipped a product so I don't know how useful it is to pinpoint these different stages for diagnostic purposes.

[NicoHood]

I updated the tutorial above now with a lot more details!

It works great, and with the patch @nmaas87 suggested everything works now at boot. Plug in your pi and it always connects with the same mac now.

@shrx I guess we dont. I just tried with the full install. Feel free to test the lite image. I guess it should work without any problems.

I guess its quite easy to use OTG now ;)
The power issue is still now solved though.
I also never tried to switch back to a non-zero pi. Not sure what will happen then with this kinda dev state.

[clivem]

@notro LOL. You're making me nostalgic! I remember how cool I thought it was when I plugged my first BeagleBone into a PC and got a serial console....... But the fact doesn't change, without dwc2 receiving some love, while it may be the answer for world peace in device mode, it leaves something to be desired, (that's the politest way of putting it), in host mode. wifi dongles suddenly disconnecting from USB bus is the tip of an iceberg. Heaven help you, (train crash leading to toxic chemical spill), trying to use it for USB audio! ;)

[notro]

I remember how cool I thought it was when I plugged my first BeagleBone into a PC and got a serial console

Me too, it was so easy to get started.

Your comment jogged my Solution-Finder-Unit and I realised that my goal might not be so far away after all.
config.txt is easily available for editing, so a user could add: dtoverlay=dwc2
Then the service could do:

if zero() and dwc2() and device_mode() then
    modprobe g_serial
end

A keyboard plugged in after boot will still work, and if this behaviour is not desirable, the service can just be disabled.

So here's project for me when I'm done banging my head agaist getting Pi2 mainline support working without issues (unless someone can't wait that long and finds a way to actually implement this).

Heaven help you, (train crash leading to toxic chemical spill), trying to use it for USB audio! ;)

My focus on an easily available serial console gave me tunnel vision, so I'm glad there's a review process :-)

[NicoHood]

Just a small question:
I cannot use ping without sudo on the g_ether module. Is this normal?

pi@raspberrypizero:~$ ping 8.8.8.8
ping: icmp open socket: Operation not permitted

[nmaas87]

@NicoHood Not a problem because of g_ether I think. Test if the SUID bit is set correctly on your ping command, as described here: http://ben.goodacre.name/tech/Ping:_icmp_open_socket:_Operation_not_permitted_(Linux)
On my Minibian Jessie - it worked right out of the box :)
Edit: It did work right out of the box (ping 8.8.8.8) without root access, however, the SUID bit was not set on my PiZero (I have no idea how this could work, because network access is always a kind of root thing...). On my Ubuntu Box, however, the SUID bit is set on /bin/ping :).

[NicoHood]

I now also tried the usb gadget. It seems to work fine, I tried to install an OS into the emulated usb drive, but it failed after booting. But it was used on a slow "random" sd card, I will try this again on a better one.

The question is now, how to enable the gadgets by default on a zero, but disable them in a pi2? We currently have to edit the config.txt. Is there a way to add something like if inside those files, or can the be done with a kernel fix?

Also can we automatically enable the dwc2 module if g_ether is loaded for example? Would this work too? Then people do not have to type both of them in the /etc/modules.

I really would like to see this feature more flexible across different pi models. This is really awesome. And some of the responsible pi people should solve the power issue by providing a schematic, so we know if connecting a PSU in device mode hurts any device.

[NicoHood]

I just tried again (with a different sd card, from the beginning) and after applying:

echo "device_tree=bcm2708-rpi-zero.dtb" | sudo tee -a /boot/config.txt

The raspi stops booting and the rainbow screen only shows up. If i remove the line (with an sd card reader) it boots up again.

Using g_ether without those line does not work, but the line itself now also doesnt work anymore. So what has changed?

I first setup the device with a pi2, however the 4.4 kernel all boots fine on a zero, just the device tree setting makes it not boot up anymore.

Edit:
I put in my old sd card and I noticed that bcm2708-rpi-zero.dtb is just missing on the boot partition. Maybe because I did the rpi-upgrade on the pi2, not the zero? I guess this is a bug?

[t3chguy]

@NicoHood no, the zero specific .dtb is no more as I found out. Just dtoverlay=dwc2 is enough after sudo BRANCH=next rpi-update, then either manually load one of the g_ modules or stick

dwc2
g_ether

inside /etc/modules

[notro]

What's the link to the Raspian github issue tracker? I can't find it.
I have a proposal on how to easily enable a usb console.

[lurch]

What's the link to the Raspian github issue tracker?

I guess https://github.com/RPi-Distro/repo/issues is the nearest match?

[popcornmix]

Correct. For raspbian build of default debian packages it is:
https://www.raspbian.org/RaspbianBugs

For raspberry pi specific packages and init scripts (not from debian) then:
https://github.com/RPi-Distro/repo/issues

[notro]

Thanks. RPi-Distro/repo#17

[NicoHood]

@t3chguy thanks! I updated the tutorial above. echo "dtoverlay=dwc2" | sudo tee -a /boot/config.txt is now all you need.

Is there a chance to load this overlay by default or is there any disadvantage for this?

There is also another bug that /etc/modprobe.d/g_ether.conf is not recognized sometimes. I think its mostly after first loading g_ether. If you remove it and load it again it will be applied.

[lurch]

Is there a chance to load this overlay by default or is there any disadvantage for this?

See the messages from @clivem earlier in this discussion.

[NicoHood]

So its unstable for host mode on some devices and it will be kept like this?

Cant we load/unload those overlays at runtime? (Sorry i never did such kernel things before).
Is there any chance to see this somehow improved in the future or is this just the limitation we have?

[braian87b]

Hey, what about using with usbip client as host on Raspberry Pi Zero (as usbip server running in another rasbperry pi with a device connected), then wirelessly you can plug Raspberry Pi Zero on a computer and see the device if it where connected directly to the computer. Can this be done?

[lurch]

@braian87b I've read your comment several times, and I'm still not quite sure what you're asking for?

I think what you're suggesting is having a PiZero in gadget-mode connected over USB to a PC, and then having the PiZero communicating wirelessly with another Raspberry Pi, and then having a USB device you connect to this second Raspberry Pi "tunnelled" wirelessly to the PiZero, and then exposing it as a 'virtual' USB device to the PC which the PiZero is connected to?

However the PiZero only has one USB OTG port, which can operate in either host or device mode. So if you've got the Pi connected in device-mode to a PC, there's then no 'spare' USB host port into which to plug a Wifi dongle. There are ways of communicating with a wifi chip over the Pi's GPIO pins e.g. https://shop.pimoroni.com/products/esp8266-phat but that only runs at 1mbps, whereas USB2 runs at up to 480mbps (even USB1 is 12mbps).

[braian87b]

@lurch Right... sorry, I didn't notice... thanks!

[dtaht]

I was catching up on this discussion in light of some discussion elsewhere ( https://plus.google.com/u/0/+EricRaymond/posts/DR2zNNyNs3Z )

and I see my pi2 had in 4.4.12+/

for dwc2.ko

but not in my latest update (4.4.12-v7). Does the OTG stuff work on the pi2 or pi3?

[lurch]

Does the OTG stuff work on the pi2 or pi3?

No. The USB hub in the LAN9514 'gets in the way' and means that the single USB port in the SoC on those devices can only work in host (master) mode. It's only because the PiZero has a single USB port (i.e. no USB hub) that it's also able to (optionally) work in device (slave) mode.

[Dygear]

Anyone happen to have documentation on how to use the g_serial option. With only

• Raspberry Pi Zero (W),
• Formatted SD Card with Jessie Lite
• A USB Cable.

I want to just connect it to my desktop computer and connect to it via ttyACM0: USB ACM device.

The CHIP does this out of the box, so I was hoping to get the same sort of interface out of the Pi Zero. Can someone point me in the right direction for that?

(I'm willing to be a guinea pig as I have 2 Pi Zero Ws and 1 Pi Zero - All of them I intend on using as headless servers. So never having to get a USB keyboard and Mini HDMI to HDMI connector is a bonus.)

[t3chguy]

@Dygear you can use this for reference https://bit.ovh/2016/01/31/Raspberry-Pi-Zero-Gadget-Mode/

You can ignore rpi-update and run all those commands in a chroot of the mounted sd card (or even looped iso/img)

You will have to create an appropriate symlink so systemd starts the tty/getty, and ignore the interfaces related commands and replace g_ether with g_serial

I have notes on my laptop, I'll update when I get home

[bastijr]

I now need PI zero to implement a function: use USB Wire to connect PIzero and iPhone so that iPhone is the host, PIzero is the slave? I want to known if the funtion has been finished? Is there open source code?

[pelwell]

This is a question, not an issue. Please open a topic in the Raspberry Pi forums, stating what functionality the PiZero should provide - mass storage, etc.