New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 124 commits into
base: rpi-4.4.y
from

Conversation

Projects
None yet
@notro
Contributor

notro commented Dec 26, 2015

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 notro changed the title from Add USB gadget support to Pi Zero to rpi-4.4.y: Add USB gadget support to Pi Zero Dec 26, 2015

@notro

This comment has been minimized.

Show comment
Hide comment
@notro

notro Dec 26, 2015

Contributor

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

Contributor

notro commented Dec 26, 2015

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

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Dec 26, 2015

Collaborator

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.

Collaborator

popcornmix commented Dec 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@MrEngman

MrEngman Dec 27, 2015

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

MrEngman commented Dec 27, 2015

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

@notro

This comment has been minimized.

Show comment
Hide comment
@notro

notro Dec 27, 2015

Contributor

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
Contributor

notro commented Dec 27, 2015

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

This comment has been minimized.

Show comment
Hide comment
@MrEngman

MrEngman Dec 27, 2015

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.

MrEngman commented Dec 27, 2015

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

This comment has been minimized.

Show comment
Hide comment
@clivem

clivem Dec 27, 2015

Contributor

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.

Contributor

clivem commented Dec 27, 2015

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

This comment has been minimized.

Show comment
Hide comment
@notro

notro Dec 27, 2015

Contributor

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.

Contributor

notro commented Dec 27, 2015

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.

Steve Glendinning and others added some commits Feb 19, 2015

smsx95xx: fix crimes against truesize
smsc95xx is adjusting truesize when it shouldn't, and following a recent patch from Eric this is now triggering warnings.

This patch stops smsc95xx from changing truesize.

Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
irqchip: bcm2835: Add FIQ support
Add a duplicate irq range with an offset on the hwirq's so the
driver can detect that enable_fiq() is used.
Tested with downstream dwc_otg USB controller driver.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
irq-bcm2836: Prevent spurious interrupts, and trap them early
The old arch-specific IRQ macros included a dsb to ensure the
write to clear the mailbox interrupt completed before returning
from the interrupt. The BCM2836 irqchip driver needs the same
precaution to avoid spurious interrupts.

Spurious interrupts are still possible for other reasons,
though, so trap them early.
irqchip: irq-bcm2835: Add 2836 FIQ support
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
pinctrl-bcm2835: Set base to 0 give expected gpio numbering
Signed-off-by: Noralf Tronnes <notro@tronnes.org>
pinctrl-bcm2835: Fix interrupt handling for GPIOs 28-31 and 46-53
Contrary to the documentation, the BCM2835 GPIO controller actually has
four interrupt lines - one each for the three IRQ groups and one common. Rather
confusingly, the GPIO interrupt groups don't correspond directly with the GPIO
control banks. Instead, GPIOs 0-27 generate IRQ GPIO0, 28-45 GPIO1 and
46-53 GPIO2.

Awkwardly, the GPIOS for IRQ GPIO1 straddle two 32-entry GPIO banks, so it is
cleaner to split out a function to process the interrupts for a single GPIO
bank.

This bug has only just been observed because GPIOs above 27 can only be
accessed on an old Raspberry Pi with the optional P5 header fitted, where
the pins are often used for I2S instead.
pinctrl-bcm2835: Only request the interrupts listed in the DTB
Although the GPIO controller can generate three interrupts (four counting
the common one), the device tree files currently only specify two. In the
absence of the third, simply don't register that interrupt (as opposed to
registering 0), which has the effect of making it impossible to generate
interrupts for GPIOs 46-53 which, since they share pins with the SD card
interface, is unlikely to be a problem.
ARM: bcm2835: Set Serial number and Revision
The VideoCore bootloader passes in Serial number and
Revision number through Device Tree. Make these available to
userspace through /proc/cpuinfo.

Mainline status:

There is a commit in linux-next that standardize passing the serial
number through Device Tree (string: /serial-number):
ARM: 8355/1: arch: Show the serial number from devicetree in cpuinfo

There was an attempt to do the same with the revision number, but it
didn't get in:
[PATCH v2 1/2] arm: devtree: Set system_rev from DT revision

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
spi-bcm2835: Support pin groups other than 7-11
The spi-bcm2835 driver automatically uses GPIO chip-selects due to
some unreliability of the native ones. In doing so it chooses the
same pins as the native chip-selects would use, but the existing
code always uses pins 7 and 8, wherever the SPI function is mapped.

Search the pinctrl group assigned to the driver for pins that
correspond to native chip-selects, and use those for GPIO chip-
selects.

Signed-off-by: Phil Elwell <phil@raspberrypi.org>
bcm2835-i2s: add 24bit support, update bclk_ratio to more correct values
Code ported from bcm2708-i2s driver in Raspberry Pi tree.

RPi commit 62c05a0 ("ASoC: BCM2708:
Add 24 bit support")

This adds 24 bit support to the I2S driver of the BCM2708.
Besides enabling the 24 bit flags, it includes two bug fixes:

MMAP is not supported. Claiming this leads to strange issues
when the format of driver and file do not match.

The datasheet states that the width extension bit should be set
for widths greater than 24, but greater or equal would be correct.
This follows from the definition of the width field.

Signed-off-by: Florian Meier <florian.meier@koalo.de>

RPi commit 3e8c672 ("bcm2708-i2s:
Update bclk_ratio to more correct values")

Discussion about blck_ratio affecting sound quality:
#681

Signed-off-by: Matthias Reichl <hias@horus.com>
bcm2835-i2s: get base address for DMA from devicetree
Code copied from spi-bcm2835. Get physical address from devicetree
instead of using hardcoded constant.

Signed-off-by: Matthias Reichl <hias@horus.com>
bcm2835-i2s: setup clock only if CPU is clock master
Code ported from bcm2708-i2s driver in Raspberry Pi tree.

RPi commit c14827e ("bcm2708: Allow
option card devices to be configured via DT")

Original work by Zoltan Szenczi, committed to RPi tree by
Phil Elwell.

Signed-off-by: Matthias Reichl <hias@horus.com>
bcm2835-i2s: Register PCM device
Code ported from bcm2708-i2s driver in Raspberry Pi tree.

RPi commit ba46b49 ("ASoC: Add
support for BCM2708")

This driver adds support for digital audio (I2S)
for the BCM2708 SoC that is used by the
Raspberry Pi. External audio codecs can be
connected to the Raspberry Pi via P5 header.

It relies on cyclic DMA engine support for BCM2708.

Signed-off-by: Florian Meier <florian.meier@koalo.de>

Signed-off-by: Matthias Reichl <hias@horus.com>
bcm2835-i2s: Eliminate debugfs directory error
Code ported from bcm2708-i2s driver in Raspberry Pi tree.

RPi commit fd7d7a3 ("bcm2708:
Eliminate i2s debugfs directory error")

Qualify the two regmap ranges uses by bcm2708-i2s ('-i2s' and '-clk')
to avoid the name clash when registering debugfs entries.

Signed-off-by: Matthias Reichl <hias@horus.com>
dmaengine: bcm2835: Add slave dma support
Add slave transfer capability to BCM2835 dmaengine driver.
This patch is pulled from the bcm2708-dmaengine driver in the
Raspberry Pi repo. The work was done by Gellert Weisz.

Tested using the bcm2835-mmc driver from the same repo.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
bcm2835-i2s: Enable MMAP support via a DT property
Code ported from bcm2708-i2s driver in Raspberry Pi tree.

RPi commit 7ee829f ("bcm2708-i2s:
Enable MMAP support via a DT property and overlay")

The i2s driver used to claim to support MMAP, but that feature was disabled
when some problems were found. Add the ability to enable this feature
through Device Tree, using the i2s-mmap overlay.

See: #1004

Signed-off-by: Matthias Reichl <hias@horus.com>
dmaengine: bcm2835: set residue_granularity field
bcm2835-dma supports residue reporting at burst level but didn't report
this via the residue_granularity field.

Without this field set properly we get playback issues with I2S cards.

[by HiassofT, taken from bcm2708-dmaengine]
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
dmaengine: bcm2835: Load driver early and support legacy API
Load driver early since at least bcm2708_fb doesn't support deferred
probing and even if it did, we don't want the video driver deferred.
Support the legacy DMA API which is needed by bcm2708_fb.
Don't mask out channel 2.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
bcm2835: Add support for uart1
This is a hack until a proper solution is agreed upon.
Martin Sperl is doing some work in this area.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
bcm2835-dma: Fix dreq not set for slave transfers
Set dreq to slave_id if it is not set like in bcm2708-dmaengine.
bcm2835-dma: Limit cyclic transfers on lite channels to 32k
Transfers larger than 32k cause repeated clicking with I2S soundcards.
The exact reason is yet unknown, so limit to 32k as bcm2708-dmaengine
did as an intermediate fix.
Main bcm2708/bcm2709 linux port
Signed-off-by: popcornmix <popcornmix@gmail.com>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
firmware: bcm2835: Add missing property tags
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Add dwc_otg driver
Signed-off-by: popcornmix <popcornmix@gmail.com>

usb: dwc: fix lockdep false positive

Signed-off-by: Kari Suvanto <karis79@gmail.com>

usb: dwc: fix inconsistent lock state

Signed-off-by: Kari Suvanto <karis79@gmail.com>

Add FIQ patch to dwc_otg driver. Enable with dwc_otg.fiq_fix_enable=1. Should give about 10% more ARM performance.
Thanks to Gordon and Costas

Avoid dynamic memory allocation for channel lock in USB driver. Thanks ddv2005.

Add NAK holdoff scheme. Enabled by default, disable with dwc_otg.nak_holdoff_enable=0. Thanks gsh

Make sure we wait for the reset to finish

dwc_otg: fix bug in dwc_otg_hcd.c resulting in silent kernel
	 memory corruption, escalating to OOPS under high USB load.

dwc_otg: Fix unsafe access of QTD during URB enqueue

In dwc_otg_hcd_urb_enqueue during qtd creation, it was possible that the
transaction could complete almost immediately after the qtd was assigned
to a host channel during URB enqueue, which meant the qtd pointer was no
longer valid having been completed and removed. Usually, this resulted in
an OOPS during URB submission. By predetermining whether transactions
need to be queued or not, this unsafe pointer access is avoided.

This bug was only evident on the Pi model A where a device was attached
that had no periodic endpoints (e.g. USB pendrive or some wlan devices).

dwc_otg: Fix incorrect URB allocation error handling

If the memory allocation for a dwc_otg_urb failed, the kernel would OOPS
because for some reason a member of the *unallocated* struct was set to
zero. Error handling changed to fail correctly.

dwc_otg: fix potential use-after-free case in interrupt handler

If a transaction had previously aborted, certain interrupts are
enabled to track error counts and reset where necessary. On IN
endpoints the host generates an ACK interrupt near-simultaneously
with completion of transfer. In the case where this transfer had
previously had an error, this results in a use-after-free on
the QTD memory space with a 1-byte length being overwritten to
0x00.

dwc_otg: add handling of SPLIT transaction data toggle errors

Previously a data toggle error on packets from a USB1.1 device behind
a TT would result in the Pi locking up as the driver never handled
the associated interrupt. Patch adds basic retry mechanism and
interrupt acknowledgement to cater for either a chance toggle error or
for devices that have a broken initial toggle state (FT8U232/FT232BM).

dwc_otg: implement tasklet for returning URBs to usbcore hcd layer

The dwc_otg driver interrupt handler for transfer completion will spend
a very long time with interrupts disabled when a URB is completed -
this is because usb_hcd_giveback_urb is called from within the handler
which for a USB device driver with complicated processing (e.g. webcam)
will take an exorbitant amount of time to complete. This results in
missed completion interrupts for other USB packets which lead to them
being dropped due to microframe overruns.

This patch splits returning the URB to the usb hcd layer into a
high-priority tasklet. This will have most benefit for isochronous IN
transfers but will also have incidental benefit where multiple periodic
devices are active at once.

dwc_otg: fix NAK holdoff and allow on split transactions only

This corrects a bug where if a single active non-periodic endpoint
had at least one transaction in its qh, on frnum == MAX_FRNUM the qh
would get skipped and never get queued again. This would result in
a silent device until error detection (automatic or otherwise) would
either reset the device or flush and requeue the URBs.

Additionally the NAK holdoff was enabled for all transactions - this
would potentially stall a HS endpoint for 1ms if a previous error state
enabled this interrupt and the next response was a NAK. Fix so that
only split transactions get held off.

dwc_otg: Call usb_hcd_unlink_urb_from_ep with lock held in completion handler

usb_hcd_unlink_urb_from_ep must be called with the HCD lock held.  Calling it
asynchronously in the tasklet was not safe (regression in
c4564d4).

This change unlinks it from the endpoint prior to queueing it for handling in
the tasklet, and also adds a check to ensure the urb is OK to be unlinked
before doing so.

NULL pointer dereference kernel oopses had been observed in usb_hcd_giveback_urb
when a USB device was unplugged/replugged during data transfer.  This effect
was reproduced using automated USB port power control, hundreds of replug
events were performed during active transfers to confirm that the problem was
eliminated.

USB fix using a FIQ to implement split transactions

This commit adds a FIQ implementaion that schedules
the split transactions using a FIQ so we don't get
held off by the interrupt latency of Linux

dwc_otg: fix device attributes and avoid kernel warnings on boot

dcw_otg: avoid logging function that can cause panics

See: raspberrypi/firmware#21
Thanks to cleverca22 for fix

dwc_otg: mask correct interrupts after transaction error recovery

The dwc_otg driver will unmask certain interrupts on a transaction
that previously halted in the error state in order to reset the
QTD error count. The various fine-grained interrupt handlers do not
consider that other interrupts besides themselves were unmasked.

By disabling the two other interrupts only ever enabled in DMA mode
for this purpose, we can avoid unnecessary function calls in the
IRQ handler. This will also prevent an unneccesary FIQ interrupt
from being generated if the FIQ is enabled.

dwc_otg: fiq: prevent FIQ thrash and incorrect state passing to IRQ

In the case of a transaction to a device that had previously aborted
due to an error, several interrupts are enabled to reset the error
count when a device responds. This has the side-effect of making the
FIQ thrash because the hardware will generate multiple instances of
a NAK on an IN bulk/interrupt endpoint and multiple instances of ACK
on an OUT bulk/interrupt endpoint. Make the FIQ mask and clear the
associated interrupts.

Additionally, on non-split transactions make sure that only unmasked
interrupts are cleared. This caused a hard-to-trigger but serious
race condition when you had the combination of an endpoint awaiting
error recovery and a transaction completed on an endpoint - due to
the sequencing and timing of interrupts generated by the dwc_otg core,
it was possible to confuse the IRQ handler.

Fix function tracing

dwc_otg: whitespace cleanup in dwc_otg_urb_enqueue

dwc_otg: prevent OOPSes during device disconnects

The dwc_otg_urb_enqueue function is thread-unsafe. In particular the
access of urb->hcpriv, usb_hcd_link_urb_to_ep, dwc_otg_urb->qtd and
friends does not occur within a critical section and so if a device
was unplugged during activity there was a high chance that the
usbcore hub_thread would try to disable the endpoint with partially-
formed entries in the URB queue. This would result in BUG() or null
pointer dereferences.

Fix so that access of urb->hcpriv, enqueuing to the hardware and
adding to usbcore endpoint URB lists is contained within a single
critical section.

dwc_otg: prevent BUG() in TT allocation if hub address is > 16

A fixed-size array is used to track TT allocation. This was
previously set to 16 which caused a crash because
dwc_otg_hcd_allocate_port would read past the end of the array.

This was hit if a hub was plugged in which enumerated as addr > 16,
due to previous device resets or unplugs.

Also add #ifdef FIQ_DEBUG around hcd->hub_port_alloc[], which grows
to a large size if 128 hub addresses are supported. This field is
for debug only for tracking which frame an allocate happened in.

dwc_otg: make channel halts with unknown state less damaging

If the IRQ received a channel halt interrupt through the FIQ
with no other bits set, the IRQ would not release the host
channel and never complete the URB.

Add catchall handling to treat as a transaction error and retry.

dwc_otg: fiq_split: use TTs with more granularity

This fixes certain issues with split transaction scheduling.

- Isochronous multi-packet OUT transactions now hog the TT until
  they are completed - this prevents hubs aborting transactions
  if they get a periodic start-split out-of-order
- Don't perform TT allocation on non-periodic endpoints - this
  allows simultaneous use of the TT's bulk/control and periodic
  transaction buffers

This commit will mainly affect USB audio playback.

dwc_otg: fix potential sleep while atomic during urb enqueue

Fixes a regression introduced with eb1b482. Kmalloc called from
dwc_otg_hcd_qtd_add / dwc_otg_hcd_qtd_create did not always have
the GPF_ATOMIC flag set. Force this flag when inside the larger
critical section.

dwc_otg: make fiq_split_enable imply fiq_fix_enable

Failing to set up the FIQ correctly would result in
"IRQ 32: nobody cared" errors in dmesg.

dwc_otg: prevent crashes on host port disconnects

Fix several issues resulting in crashes or inconsistent state
if a Model A root port was disconnected.

- Clean up queue heads properly in kill_urbs_in_qh_list by
  removing the empty QHs from the schedule lists
- Set the halt status properly to prevent IRQ handlers from
  using freed memory
- Add fiq_split related cleanup for saved registers
- Make microframe scheduling reclaim host channels if
  active during a disconnect
- Abort URBs with -ESHUTDOWN status response, informing
  device drivers so they respond in a more correct fashion
  and don't try to resubmit URBs
- Prevent IRQ handlers from attempting to handle channel
  interrupts if the associated URB was dequeued (and the
  driver state was cleared)

dwc_otg: prevent leaking URBs during enqueue

A dwc_otg_urb would get leaked if the HCD enqueue function
failed for any reason. Free the URB at the appropriate points.

dwc_otg: Enable NAK holdoff for control split transactions

Certain low-speed devices take a very long time to complete a
data or status stage of a control transaction, producing NAK
responses until they complete internal processing - the USB2.0
spec limit is up to 500mS. This causes the same type of interrupt
storm as seen with USB-serial dongles prior to c8edb23.

In certain circumstances, usually while booting, this interrupt
storm could cause SD card timeouts.

dwc_otg: Fix for occasional lockup on boot when doing a USB reset

dwc_otg: Don't issue traffic to LS devices in FS mode

Issuing low-speed packets when the root port is in full-speed mode
causes the root port to stop responding. Explicitly fail when
enqueuing URBs to a LS endpoint on a FS bus.

Fix ARM architecture issue with local_irq_restore()

If local_fiq_enable() is called before a local_irq_restore(flags) where
the flags variable has the F bit set, the FIQ will be erroneously disabled.

Fixup arch_local_irq_restore to avoid trampling the F bit in CPSR.

Also fix some of the hacks previously implemented for previous dwc_otg
incarnations.

dwc_otg: fiq_fsm: Base commit for driver rewrite

This commit removes the previous FIQ fixes entirely and adds fiq_fsm.

This rewrite features much more complete support for split transactions
and takes into account several OTG hardware bugs. High-speed
isochronous transactions are also capable of being performed by fiq_fsm.

All driver options have been removed and replaced with:
  - dwc_otg.fiq_enable (bool)
  - dwc_otg.fiq_fsm_enable (bool)
  - dwc_otg.fiq_fsm_mask (bitmask)
  - dwc_otg.nak_holdoff (unsigned int)

Defaults are specified such that fiq_fsm behaves similarly to the
previously implemented FIQ fixes.

fiq_fsm: Push error recovery into the FIQ when fiq_fsm is used

If the transfer associated with a QTD failed due to a bus error, the HCD
would retry the transfer up to 3 times (implementing the USB2.0
three-strikes retry in software).

Due to the masking mechanism used by fiq_fsm, it is only possible to pass
a single interrupt through to the HCD per-transfer.

In this instance host channels would fall off the radar because the error
reset would function, but the subsequent channel halt would be lost.

Push the error count reset into the FIQ handler.

fiq_fsm: Implement timeout mechanism

For full-speed endpoints with a large packet size, interrupt latency
runs the risk of the FIQ starting a transaction too late in a full-speed
frame. If the device is still transmitting data when EOF2 for the
downstream frame occurs, the hub will disable the port. This change is
not reflected in the hub status endpoint and the device becomes
unresponsive.

Prevent high-bandwidth transactions from being started too late in a
frame. The mechanism is not guaranteed: a combination of bit stuffing
and hub latency may still result in a device overrunning.

fiq_fsm: fix bounce buffer utilisation for Isochronous OUT

Multi-packet isochronous OUT transactions were subject to a few bounday
bugs. Fix them.

Audio playback is now much more robust: however, an issue stands with
devices that have adaptive sinks - ALSA plays samples too fast.

dwc_otg: Return full-speed frame numbers in HS mode

The frame counter increments on every *microframe* in high-speed mode.
Most device drivers expect this number to be in full-speed frames - this
caused considerable confusion to e.g. snd_usb_audio which uses the
frame counter to estimate the number of samples played.

fiq_fsm: save PID on completion of interrupt OUT transfers

Also add edge case handling for interrupt transports.

Note that for periodic split IN, data toggles are unimplemented in the
OTG host hardware - it unconditionally accepts any PID.

fiq_fsm: add missing case for fiq_fsm_tt_in_use()

Certain combinations of bitrate and endpoint activity could
result in a periodic transaction erroneously getting started
while the previous Isochronous OUT was still active.

fiq_fsm: clear hcintmsk for aborted transactions

Prevents the FIQ from erroneously handling interrupts
on a timed out channel.

fiq_fsm: enable by default

fiq_fsm: fix dequeues for non-periodic split transactions

If a dequeue happened between the SSPLIT and CSPLIT phases of the
transaction, the HCD would never receive an interrupt.

fiq_fsm: Disable by default

fiq_fsm: Handle HC babble errors

The HCTSIZ transfer size field raises a babble interrupt if
the counter wraps. Handle the resulting interrupt in this case.

dwc_otg: fix interrupt registration for fiq_enable=0

Additionally make the module parameter conditional for wherever
hcd->fiq_state is touched.

fiq_fsm: Enable by default

dwc_otg: Fix various issues with root port and transaction errors

Process the host port interrupts correctly (and don't trample them).
Root port hotplug now functional again.

Fix a few thinkos with the transaction error passthrough for fiq_fsm.

fiq_fsm: Implement hack for Split Interrupt transactions

Hubs aren't too picky about which endpoint we send Control type split
transactions to. By treating Interrupt transfers as Control, it is
possible to use the non-periodic queue in the OTG core as well as the
non-periodic FIFOs in the hub itself. This massively reduces the
microframe exclusivity/contention that periodic split transactions
otherwise have to enforce.

It goes without saying that this is a fairly egregious USB specification
violation, but it works.

Original idea by Hans Petter Selasky @ FreeBSD.org.

dwc_otg: FIQ support on SMP. Set up FIQ stack and handler on Core 0 only.

dwc_otg: introduce fiq_fsm_spin(un|)lock()

SMP safety for the FIQ relies on register read-modify write cycles being
completed in the correct order. Several places in the DWC code modify
registers also touched by the FIQ. Protect these by a bare-bones lock
mechanism.

This also makes it possible to run the FIQ and IRQ handlers on different
cores.

fiq_fsm: fix build on bcm2708 and bcm2709 platforms

dwc_otg: put some barriers back where they should be for UP

bcm2709/dwc_otg: Setup FIQ on core 1 if >1 core active

dwc_otg: fixup read-modify-write in critical paths

Be more careful about read-modify-write on registers that the FIQ
also touches.

Guard fiq_fsm_spin_lock with fiq_enable check

fiq_fsm: Falling out of the state machine isn't fatal

This edge case can be hit if the port is disabled while the FIQ is
in the middle of a transaction. Make the effects less severe.

Also get rid of the useless return value.

squash: dwc_otg: Allow to build without SMP

usb: core: make overcurrent messages more prominent

Hub overcurrent messages are more serious than "debug". Increase loglevel.

usb: dwc_otg: Don't use dma_to_virt()

Commit 6ce0d20 changes dma_to_virt() which breaks this driver.
Open code the old dma_to_virt() implementation to work around this.

Limit the use of __bus_to_virt() to cases where transfer_buffer_length
is set and transfer_buffer is not set. This is done to increase the
chance that this driver will also work on ARCH_BCM2835.

transfer_buffer should not be NULL if the length is set, but the
comment in the code indicates that there are situations where this
might happen. drivers/usb/isp1760/isp1760-hcd.c also has a similar
comment pointing to a possible: 'usb storage / SCSI bug'.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

dwc_otg: Fix crash when fiq_enable=0

dwc_otg: fiq_fsm: Make high-speed isochronous strided transfers work properly

Certain low-bandwidth high-speed USB devices (specialist audio devices,
compressed-frame webcams) have packet intervals > 1 microframe.

Stride these transfers in the FIQ by using the start-of-frame interrupt
to restart the channel at the right time.

dwc_otg: Force host mode to fix incorrect compute module boards

dwc_otg: Add ARCH_BCM2835 support

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

dwc_otg: Simplify FIQ irq number code

Dropping ATAGS means we can simplify the FIQ irq number code.
Also add error checking on the returned irq number.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

dwc_otg: Remove duplicate gadget probe/unregister function
dmaengine: Add support for BCM2708
Add support for DMA controller of BCM2708 as used in the Raspberry Pi.
Currently it only supports cyclic DMA.

Signed-off-by: Florian Meier <florian.meier@koalo.de>

dmaengine: expand functionality by supporting scatter/gather transfers sdhci-bcm2708 and dma.c: fix for LITE channels

DMA: fix cyclic LITE length overflow bug

dmaengine: bcm2708: Remove chancnt affectations

Mirror bcm2835-dma.c commit 9eba553:
chancnt is already filled by dma_async_device_register, which uses the channel
list to know how much channels there is.

Since it's already filled, we can safely remove it from the drivers' probe
function.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

dmaengine: bcm2708: overwrite dreq only if it is not set

dreq is set when the DMA channel is fetched from Device Tree.
slave_id is set using dmaengine_slave_config().
Only overwrite dreq with slave_id if it is not set.

dreq/slave_id in the cyclic DMA case is not touched, because I don't
have hardware to test with.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

dmaengine: bcm2708: do device registration in the board file

Don't register the device in the driver. Do it in the board file.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

dmaengine: bcm2708: don't restrict DT support to ARCH_BCM2835

Both ARCH_BCM2835 and ARCH_BCM270x are built with OF now.
Add Device Tree support to the non ARCH_BCM2835 case.
Use the same driver name regardless of architecture.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

BCM270x_DT: add bcm2835-dma entry

Add Device Tree entry for bcm2835-dma.
The entry doesn't contain any resources since they are handled
by the arch/arm/mach-bcm270x/dma.c driver.
In non-DT mode, don't add the device in the board file.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

bcm2708-dmaengine: Add debug options

BCM270x: Add memory and irq resources to dmaengine device and DT

Prepare for merging of the legacy DMA API arch driver dma.c
with bcm2708-dmaengine by adding memory and irq resources both
to platform file device and Device Tree node.
Don't use BCM_DMAMAN_DRIVER_NAME so we don't have to include mach/dma.h

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

dmaengine: bcm2708: Merge with arch dma.c driver and disable dma.c

Merge the legacy DMA API driver with bcm2708-dmaengine.
This is done so we can use bcm2708_fb on ARCH_BCM2835 (mailbox
driver is also needed).

Changes to the dma.c code:
- Use BIT() macro.
- Cutdown some comments to one line.
- Add mutex to vc_dmaman and use this, since the dev lock is locked
  during probing of the engine part.
- Add global g_dmaman variable since drvdata is used by the engine part.
- Restructure for readability:
  vc_dmaman_chan_alloc()
  vc_dmaman_chan_free()
  bcm_dma_chan_free()
- Restructure bcm_dma_chan_alloc() to simplify error handling.
- Use device irq resources instead of hardcoded bcm_dma_irqs table.
- Remove dev_dmaman_register() and code it directly.
- Remove dev_dmaman_deregister() and code it directly.
- Simplify bcm_dmaman_probe() using devm_* functions.
- Get dmachans from DT if available.
- Keep 'dma.dmachans' module argument name for backwards compatibility.

Make it available on ARCH_BCM2835 as well.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

dmaengine: bcm2708: set residue_granularity field

bcm2708-dmaengine supports residue reporting at burst level
but didn't report this via the residue_granularity field.

Without this field set properly we get playback issues with I2S cards.

dmaengine: bcm2708-dmaengine: Fix memory leak when stopping a running transfer

bcm2708-dmaengine: Use more DMA channels (but not 12)

1) Only the bcm2708_fb drivers uses the legacy DMA API, and
it requires a BULK-capable channel, so all other types
(FAST, NORMAL and LITE) can be made available to the regular
DMA API.

2) DMA channels 11-14 share an interrupt. The driver can't
handle this, so don't use channels 12-14 (12 was used, probably
because it appears to have an interrupt, but in reality that
interrupt is for activity on ANY channel). This may explain
a lockup encountered when running out of DMA channels.

The combined effect of this patch is to leave 7 DMA channels
available + channel 0 for bcm2708_fb via the legacy API.

See: #1110
     #1108

dmaengine: bcm2708: Make legacy API available for bcm2835-dma

bcm2708_fb uses the legacy DMA API, so in order to start using
bcm2835-dma, bcm2835-dma has to support the legacy API. Make this
possible by exporting bcm_dmaman_probe() and bcm_dmaman_remove().

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

dmaengine: bcm2708: Change DT compatible string

Both bcm2835-dma and bcm2708-dmaengine have the same compatible string.
So change compatible to "brcm,bcm2708-dma".

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

dmaengine: bcm2708: Remove driver but keep legacy API

Dropping non-DT support means we don't need this driver,
but we still need the legacy DMA API.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
bcm2708 framebuffer driver
Signed-off-by: popcornmix <popcornmix@gmail.com>

bcm2708_fb : Implement blanking support using the mailbox property interface

bcm2708_fb: Add pan and vsync controls

bcm2708_fb: DMA acceleration for fb_copyarea

Based on http://www.raspberrypi.org/phpBB3/viewtopic.php?p=62425#p62425
Also used Simon's dmaer_master module as a reference for tweaking DMA
settings for better performance.

For now busylooping only. IRQ support might be added later.
With non-overclocked Raspberry Pi, the performance is ~360 MB/s
for simple copy or ~260 MB/s for two-pass copy (used when dragging
windows to the right).

In the case of using DMA channel 0, the performance improves
to ~440 MB/s.

For comparison, VFP optimized CPU copy can only do ~114 MB/s in
the same conditions (hindered by reading uncached source buffer).

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

bcm2708_fb: report number of dma copies

Add a counter (exported via debugfs) reporting the
number of dma copies that the framebuffer driver
has done, in order to help evaluate different
optimization strategies.

Signed-off-by: Luke Diamand <luked@broadcom.com>

bcm2708_fb: use IRQ for DMA copies

The copyarea ioctl() uses DMA to speed things along. This
was busy-waiting for completion. This change supports using
an interrupt instead for larger transfers. For small
transfers, busy-waiting is still likely to be faster.

Signed-off-by: Luke Diamand <luke@diamand.org>

bcm2708: Make ioctl logging quieter

video: fbdev: bcm2708_fb: Don't panic on error

No need to panic the kernel if the video driver fails.
Just print a message and return an error.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

fbdev: bcm2708_fb: Add ARCH_BCM2835 support

Add Device Tree support.
Pass the device to dma_alloc_coherent() in order to get the
correct bus address on ARCH_BCM2835.
Use the new DMA legacy API header file.
Including <mach/platform.h> is not necessary.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>

BCM270x_DT: Add bcm2708-fb device

Add bcm2708-fb to Device Tree and don't add the
platform device when booting in DT mode.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Jan 9, 2016

Collaborator

Okay.
sudo BRANCH=next rpi-update
should get the latest kernel with these commits.

Collaborator

popcornmix commented Jan 9, 2016

Okay.
sudo BRANCH=next rpi-update
should get the latest kernel with these commits.

popcornmix added a commit to raspberrypi/firmware that referenced this pull request Jan 9, 2016

kernel: Bump to 4.4.0-rc8
kernel: Add dwc2 overlay for Pi Zero
See: raspberrypi/linux#1239

popcornmix added a commit to Hexxeh/rpi-firmware that referenced this pull request Jan 9, 2016

kernel: Bump to 4.4.0-rc8
kernel: Add dwc2 overlay for Pi Zero
See: raspberrypi/linux#1239
@NicoHood

This comment has been minimized.

Show comment
Hide comment
@NicoHood

NicoHood Jan 9, 2016

Ahm just a small question:
I tried the command above (with a clean full jessie image) and this installs kernel 4.4.0-rc8+ . I then set the device tree in config.txt and loaded the g_ether module via /etc/modules.

#config.txt (appended, the rest was kept unchanged)
device_tree=bcm2708-rpi-b.dtb
dtoverlay=mmc

Its not working the same way as @gbaman s tutorial did. So something must be missing, possibly the modules?

NicoHood commented Jan 9, 2016

Ahm just a small question:
I tried the command above (with a clean full jessie image) and this installs kernel 4.4.0-rc8+ . I then set the device tree in config.txt and loaded the g_ether module via /etc/modules.

#config.txt (appended, the rest was kept unchanged)
device_tree=bcm2708-rpi-b.dtb
dtoverlay=mmc

Its not working the same way as @gbaman s tutorial did. So something must be missing, possibly the modules?

@clivem

This comment has been minimized.

Show comment
Hide comment
@clivem

clivem Jan 9, 2016

Contributor

Erm..... I haven't actually looked at that next branch, but I think your config.txt should be more like ....

device_tree=bcm2708-rpi-zero.dtb
dtoverlay=dwc2
and "dtoverlay=mmc" if you'd prefer to revert back to mmc rather than sdhost driver.

..... if you want to use g_ether on Zero.

You might want to wait for @popcornmix to reply before you blindly follow my advice and risk ending up with something that doesn't boot. ;)

Contributor

clivem commented Jan 9, 2016

Erm..... I haven't actually looked at that next branch, but I think your config.txt should be more like ....

device_tree=bcm2708-rpi-zero.dtb
dtoverlay=dwc2
and "dtoverlay=mmc" if you'd prefer to revert back to mmc rather than sdhost driver.

..... if you want to use g_ether on Zero.

You might want to wait for @popcornmix to reply before you blindly follow my advice and risk ending up with something that doesn't boot. ;)

@NicoHood

This comment has been minimized.

Show comment
Hide comment
@NicoHood

NicoHood Jan 9, 2016

Okay so an even smaller tutorial now, but with more details after installing added.
https://github.com/NicoHood/NicoHood.github.io/wiki/Raspberry-Pi-USB-Gadget-Tutorial

Thanks for all the help! I just wrote down all my notes, most work was done by other great people!


Also an still unanswered question is, if the pi zero is protected if I power it from the OTG port and the nativ power port at the same time. Otherwise switching from host to device at runtime (with separate PSU) is dangerous and might kill one of the devices connected to it.

Edit: Here is a solution: #1212 (comment)

NicoHood commented Jan 9, 2016

Okay so an even smaller tutorial now, but with more details after installing added.
https://github.com/NicoHood/NicoHood.github.io/wiki/Raspberry-Pi-USB-Gadget-Tutorial

Thanks for all the help! I just wrote down all my notes, most work was done by other great people!


Also an still unanswered question is, if the pi zero is protected if I power it from the OTG port and the nativ power port at the same time. Otherwise switching from host to device at runtime (with separate PSU) is dangerous and might kill one of the devices connected to it.

Edit: Here is a solution: #1212 (comment)

@nmaas87

This comment has been minimized.

Show comment
Hide comment
@nmaas87

nmaas87 Jan 9, 2016

Hey @NicoHood

regarding the question about the MAC address,
it should work like this (change in /etc/network/interfaces)

allow-hotplug usb0
iface usb0 inet static
address 192.168.7.2
netmask 255.255.255.0
network 192.168.7.0
broadcast 192.168.7.255
gateway 192.168.7.1
dns-nameservers 8.8.8.8
hwaddress ether 00:01:04:1b:2C:1F

According to this site: http://www.youritronics.com/how-to-set-the-mac-address-from-etcnetworkinterfaces-in-debian/ (have not tested it, yet)

Regarding the powering problem, I think the only way to be sure would be to see, wheter there are some kind of protection diodes sepearting both (potential) power sources or such. Problem is, the electrical schematics of the pi zero are not (yet) available online (at least not where the rest of the stuff is found at: https://www.raspberrypi.org/documentation/hardware/raspberrypi/schematics/README.md )

nmaas87 commented Jan 9, 2016

Hey @NicoHood

regarding the question about the MAC address,
it should work like this (change in /etc/network/interfaces)

allow-hotplug usb0
iface usb0 inet static
address 192.168.7.2
netmask 255.255.255.0
network 192.168.7.0
broadcast 192.168.7.255
gateway 192.168.7.1
dns-nameservers 8.8.8.8
hwaddress ether 00:01:04:1b:2C:1F

According to this site: http://www.youritronics.com/how-to-set-the-mac-address-from-etcnetworkinterfaces-in-debian/ (have not tested it, yet)

Regarding the powering problem, I think the only way to be sure would be to see, wheter there are some kind of protection diodes sepearting both (potential) power sources or such. Problem is, the electrical schematics of the pi zero are not (yet) available online (at least not where the rest of the stuff is found at: https://www.raspberrypi.org/documentation/hardware/raspberrypi/schematics/README.md )

@NicoHood

This comment has been minimized.

Show comment
Hide comment
@NicoHood

NicoHood Jan 9, 2016

You can do

echo "options g_ether host_addr=00:11:22:33:44:55" | sudo tee /etc/modprobe.d/g_ether.conf

#or
sudo nano /etc/modprobe.d/g_ether.conf
options g_ether host_addr=00:11:22:33:44:55
options g_ether dev_addr=00:66:77:88:99:00

Which works perfectly for me. I dont know which one is more reliable. the "host" setting sets the mac, that the connected host PC sees. The "dev" setting (just replace host with dev) sets the mac that the pi sees itself for its own usb0 adapter. This is confusing me. Shouldnt they be the same anyways? You can modify them in the way that the host sees the pi with a different mac than the pi sees itself.

Too bad about the schematics. Someone who inspected the pcb told me to better be carefully since it looks to him that the lines are just 1:1 connected. Thats a pity.

NicoHood commented Jan 9, 2016

You can do

echo "options g_ether host_addr=00:11:22:33:44:55" | sudo tee /etc/modprobe.d/g_ether.conf

#or
sudo nano /etc/modprobe.d/g_ether.conf
options g_ether host_addr=00:11:22:33:44:55
options g_ether dev_addr=00:66:77:88:99:00

Which works perfectly for me. I dont know which one is more reliable. the "host" setting sets the mac, that the connected host PC sees. The "dev" setting (just replace host with dev) sets the mac that the pi sees itself for its own usb0 adapter. This is confusing me. Shouldnt they be the same anyways? You can modify them in the way that the host sees the pi with a different mac than the pi sees itself.

Too bad about the schematics. Someone who inspected the pcb told me to better be carefully since it looks to him that the lines are just 1:1 connected. Thats a pity.

@nmaas87

This comment has been minimized.

Show comment
Hide comment
@nmaas87

nmaas87 Jan 9, 2016

@NicoHood
Thanks for the heads up, regarding the MAC address 👍 :)!

IMHO:
I think the host_addr and dev_addr are important in the fact that they are different. Yes, normally you are completly right, a ethernet/network interface is only allowed to have one mac address. But, I think the OTG Ethernet does emulate a "complete network" in that sense that you can see the OTG connection between host pc and pi zero not only as ONE network interface, but instead two.
So you got the ethernet interface on your pizero, which has the dev_addr and you got another ethernet interface on the pc, which needs to have a different mac, the host_addr. And those two virtual ethernet interfaces do communicate with each other.

HOST PC ------------------------------------------- OTG Ethernet ----------------------------------------------- PiZero
equals
HOST PC --- HOST Virtual Ethernet Card --- Virtual Wire ---- PiZero Virtual Ethernet Card ---- PiZero

So that would make sense - but I could be complelty wrong here.

About the OTG Power - yes, that would make sense - regarding the little space they got on the pcb as well as the price point (yes, not really expensive to do stuff like this - but every cm² and cent/penny counts!). So - I would really refrain from testing OTG + USB Power on a PiZero. Chances are the poor bugger would just die (maybe not instantly, but in given time :/)

nmaas87 commented Jan 9, 2016

@NicoHood
Thanks for the heads up, regarding the MAC address 👍 :)!

IMHO:
I think the host_addr and dev_addr are important in the fact that they are different. Yes, normally you are completly right, a ethernet/network interface is only allowed to have one mac address. But, I think the OTG Ethernet does emulate a "complete network" in that sense that you can see the OTG connection between host pc and pi zero not only as ONE network interface, but instead two.
So you got the ethernet interface on your pizero, which has the dev_addr and you got another ethernet interface on the pc, which needs to have a different mac, the host_addr. And those two virtual ethernet interfaces do communicate with each other.

HOST PC ------------------------------------------- OTG Ethernet ----------------------------------------------- PiZero
equals
HOST PC --- HOST Virtual Ethernet Card --- Virtual Wire ---- PiZero Virtual Ethernet Card ---- PiZero

So that would make sense - but I could be complelty wrong here.

About the OTG Power - yes, that would make sense - regarding the little space they got on the pcb as well as the price point (yes, not really expensive to do stuff like this - but every cm² and cent/penny counts!). So - I would really refrain from testing OTG + USB Power on a PiZero. Chances are the poor bugger would just die (maybe not instantly, but in given time :/)

@NicoHood

This comment has been minimized.

Show comment
Hide comment
@NicoHood

NicoHood Jan 9, 2016

You are totally right, that MAC explanation makes sense. So I think we got a nice module solution here. I like it more than the network interface setting.

I just have no idea why the module doesnt load at startup. I could provide additional information if you like to. This new feature looks very promising and runs very smooth so far.

NicoHood commented Jan 9, 2016

You are totally right, that MAC explanation makes sense. So I think we got a nice module solution here. I like it more than the network interface setting.

I just have no idea why the module doesnt load at startup. I could provide additional information if you like to. This new feature looks very promising and runs very smooth so far.

@nmaas87

This comment has been minimized.

Show comment
Hide comment
@nmaas87

nmaas87 Jan 9, 2016

Ok, I tried your small tutorial and can reproduce your problem:
While I could do the update without problems, the reboot after the kernel update already "broke" my setup ;). After that, I inserted

# This is required in the config.txt (make sure to use "zero" now)
device_tree=bcm2708-rpi-zero.dtb
# Regarding the readme this is applied automatically for a pi zero (and yes it works without)
# dtoverlay=dwc2
# The new kernel causes sd card errors for me, so i use the old sd card driver
# dtoverlay=mmc

into my /boot/config.txt and tried to boot again: Nothing. Or well - at least something: My windows machine at least did mention that there was an usb device which could not be recognized, which proofed your idea that the module is not loaded correctly via the /etc/modules file (yes, I got the g_ether entry there - of course - as well :)). Last try was to add modprobe g_ether to my /etc/rc.local - and - voilá - it came up - not a problem :). So you're right - I don't know what it is - but the entry in /etc/modules is somehow "ignored" (technically, I am sure it is not ignored, but some dependency is not yet loaded at that point of the boot process or something else happens which causes the g_ether to be not loaded if done via /etc/modules...). So I think maybe we could get some more infos via dmesg and other log files. Problem: I did neither got my Serial TTL device, nor my mini usb cable with me - so debugging that matter while beeing in need of the virtual ethernet will be a little bit hard :/.

Ah, I got the problem. Just a moment, I figure out what is really needed, but I got it working again via "only /etc/modules" :)

nmaas87 commented Jan 9, 2016

Ok, I tried your small tutorial and can reproduce your problem:
While I could do the update without problems, the reboot after the kernel update already "broke" my setup ;). After that, I inserted

# This is required in the config.txt (make sure to use "zero" now)
device_tree=bcm2708-rpi-zero.dtb
# Regarding the readme this is applied automatically for a pi zero (and yes it works without)
# dtoverlay=dwc2
# The new kernel causes sd card errors for me, so i use the old sd card driver
# dtoverlay=mmc

into my /boot/config.txt and tried to boot again: Nothing. Or well - at least something: My windows machine at least did mention that there was an usb device which could not be recognized, which proofed your idea that the module is not loaded correctly via the /etc/modules file (yes, I got the g_ether entry there - of course - as well :)). Last try was to add modprobe g_ether to my /etc/rc.local - and - voilá - it came up - not a problem :). So you're right - I don't know what it is - but the entry in /etc/modules is somehow "ignored" (technically, I am sure it is not ignored, but some dependency is not yet loaded at that point of the boot process or something else happens which causes the g_ether to be not loaded if done via /etc/modules...). So I think maybe we could get some more infos via dmesg and other log files. Problem: I did neither got my Serial TTL device, nor my mini usb cable with me - so debugging that matter while beeing in need of the virtual ethernet will be a little bit hard :/.

Ah, I got the problem. Just a moment, I figure out what is really needed, but I got it working again via "only /etc/modules" :)

@nmaas87

This comment has been minimized.

Show comment
Hide comment
@nmaas87

nmaas87 Jan 9, 2016

OK, solution for the "g_ether does not work, even though included in /etc/modules" is to include following lines in in /etc/modules:

dwc2
g_ether

dwc2 is needed and not loaded automatically(!). So the basic problem is: modprobe tries to include g_ether, but the dependency of it (dwc2) is missing and that fails. If you're trying to do that via sudo modprobe (probably later in the boot process) - dwc2 was already loaded by some other stuff - at least that is me - guessing what is going on.

@NicoHood Could you test that? Would that also work for your setup?

nmaas87 commented Jan 9, 2016

OK, solution for the "g_ether does not work, even though included in /etc/modules" is to include following lines in in /etc/modules:

dwc2
g_ether

dwc2 is needed and not loaded automatically(!). So the basic problem is: modprobe tries to include g_ether, but the dependency of it (dwc2) is missing and that fails. If you're trying to do that via sudo modprobe (probably later in the boot process) - dwc2 was already loaded by some other stuff - at least that is me - guessing what is going on.

@NicoHood Could you test that? Would that also work for your setup?

@shrx

This comment has been minimized.

Show comment
Hide comment
@shrx

shrx Jan 9, 2016

Why do we need the full Jessie image instead of lite?

shrx commented Jan 9, 2016

Why do we need the full Jessie image instead of lite?

@nmaas87

This comment has been minimized.

Show comment
Hide comment
@nmaas87

nmaas87 Jan 9, 2016

@shrx I think the lite Jessie image should work too - basically the needed stuff is included within the kernel - so if you upgrade that, you should have it all together :). I used the latest version of the stripped down Minibian Jessie and it worked ( https://minibianpi.wordpress.com/ ).

nmaas87 commented Jan 9, 2016

@shrx I think the lite Jessie image should work too - basically the needed stuff is included within the kernel - so if you upgrade that, you should have it all together :). I used the latest version of the stripped down Minibian Jessie and it worked ( https://minibianpi.wordpress.com/ ).

@notro

This comment has been minimized.

Show comment
Hide comment
@notro

notro Jan 9, 2016

Contributor

dwc2 is needed and not loaded automatically

It is, but later in the boot process. When /etc/modules is parsed it is not loaded yet, so since g_ether depends on it, it has to be manually loaded.

I believe udev Coldplug all Devices is the one autoloading dwc2, but this service is started after Load Kernel Modules and takes longer to finish:

[    7.603262] systemd[1]: Starting Load Kernel Modules...
         Starting Load Kernel Modules...
[    7.635960] systemd[1]: Starting udev Coldplug all Devices...
         Starting udev Coldplug all Devices...
<...>
[  OK  ] Started Load Kernel Modules.
[    8.060231] systemd[1]: Started Load Kernel Modules.
<...>
[  OK  ] Started udev Coldplug all Devices.
[    8.339931] systemd[1]: Started udev Coldplug all Devices.
<...>
         Starting /etc/rc.local Compatibility...
<...>
[  OK  ] Started /etc/rc.local Compatibility.

/etc/modules is hooked up to systemd through a symlink:

~$ ls -l /etc/modules-load.d/modules.conf
lrwxrwxrwx 1 root root 10 Sep  5 22:23 /etc/modules-load.d/modules.conf -> ../modules

Another thing:
Now I remember why I wanted dwc2 to be the default on Zero, because coupled with a raspian systemd service that would only run only on a zero in usb device mode, it could load g_serial automatically and give an out-of-the-box serial console: Just connect the Zero to a computer and get a console. But all in due time...

Contributor

notro commented Jan 9, 2016

dwc2 is needed and not loaded automatically

It is, but later in the boot process. When /etc/modules is parsed it is not loaded yet, so since g_ether depends on it, it has to be manually loaded.

I believe udev Coldplug all Devices is the one autoloading dwc2, but this service is started after Load Kernel Modules and takes longer to finish:

[    7.603262] systemd[1]: Starting Load Kernel Modules...
         Starting Load Kernel Modules...
[    7.635960] systemd[1]: Starting udev Coldplug all Devices...
         Starting udev Coldplug all Devices...
<...>
[  OK  ] Started Load Kernel Modules.
[    8.060231] systemd[1]: Started Load Kernel Modules.
<...>
[  OK  ] Started udev Coldplug all Devices.
[    8.339931] systemd[1]: Started udev Coldplug all Devices.
<...>
         Starting /etc/rc.local Compatibility...
<...>
[  OK  ] Started /etc/rc.local Compatibility.

/etc/modules is hooked up to systemd through a symlink:

~$ ls -l /etc/modules-load.d/modules.conf
lrwxrwxrwx 1 root root 10 Sep  5 22:23 /etc/modules-load.d/modules.conf -> ../modules

Another thing:
Now I remember why I wanted dwc2 to be the default on Zero, because coupled with a raspian systemd service that would only run only on a zero in usb device mode, it could load g_serial automatically and give an out-of-the-box serial console: Just connect the Zero to a computer and get a console. But all in due time...

@NicoHood

This comment has been minimized.

Show comment
Hide comment
@NicoHood

NicoHood Jan 9, 2016

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.

NicoHood commented Jan 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@clivem

clivem Jan 9, 2016

Contributor

@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! ;)

Contributor

clivem commented Jan 9, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@notro

notro Jan 9, 2016

Contributor

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 :-)

Contributor

notro commented Jan 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@NicoHood

NicoHood Jan 9, 2016

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

NicoHood commented Jan 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@nmaas87

nmaas87 Jan 9, 2016

@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 :).

nmaas87 commented Jan 9, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@NicoHood

NicoHood Jan 14, 2016

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 commented Jan 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@NicoHood

NicoHood Jan 15, 2016

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?

NicoHood commented Jan 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@t3chguy

t3chguy Jan 15, 2016

@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

t3chguy commented Jan 15, 2016

@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

NicoHood referenced this pull request in Hexxeh/rpi-firmware Jan 15, 2016

kernel: Bump to 4.4.0
firmware: Fix for h264 picture corruption with german tv
See: raspberrypi/firmware#499

firmware: TC358762: Avoid hanging when no DISPLAY_I2C_PORT defined in blob
See: raspberrypi/firmware#526

firmware: video_render: Ensure pixel_x/pixel_y don't overflow calculations
See: raspberrypi/firmware#525

firmware: arm_loader: Set uart0_clkrate before merging overlays
See: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=113753&sid=df96fc384c4794d3344e5462a2ab0c45&start=150#p879523
@notro

This comment has been minimized.

Show comment
Hide comment
@notro

notro Jan 16, 2016

Contributor

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.

Contributor

notro commented Jan 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@lurch

lurch Jan 16, 2016

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

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

lurch commented Jan 16, 2016

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

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

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Jan 16, 2016

Collaborator

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

Collaborator

popcornmix commented Jan 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@notro

notro Jan 16, 2016

Contributor
Contributor

notro commented Jan 16, 2016

@NicoHood

This comment has been minimized.

Show comment
Hide comment
@NicoHood

NicoHood Jan 16, 2016

@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.

NicoHood commented Jan 16, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@lurch

lurch Jan 16, 2016

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.

lurch commented Jan 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@NicoHood

NicoHood Jan 16, 2016

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?

NicoHood commented Jan 16, 2016

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?

@notro notro closed this Jan 27, 2016

@braian87b

This comment has been minimized.

Show comment
Hide comment
@braian87b

braian87b Mar 15, 2016

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?

braian87b commented Mar 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@lurch

lurch Mar 15, 2016

@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).

lurch commented Mar 15, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@braian87b

braian87b Mar 16, 2016

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

braian87b commented Mar 16, 2016

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

@dtaht

This comment has been minimized.

Show comment
Hide comment
@dtaht

dtaht Jun 9, 2016

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?

dtaht commented Jun 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@lurch

lurch Jun 9, 2016

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.

lurch commented Jun 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Dygear

Dygear Mar 29, 2017

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.)

Dygear commented Mar 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@t3chguy

t3chguy Mar 29, 2017

@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

t3chguy commented Mar 29, 2017

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment