Raspberry Pi • View topic

by **tufty** » Sun Jun 10, 2012 4:39 pm

Morgaine wrote:In a nutshell, <snip>

No, in a nutshell, the Linux driver supplied by the third party who developed the USB IP used in the SoC is a pile of cark, not only when used on this SoC, but on other SoCs using the same IP.

A non-USB reliant ethernet implementation would be great, but would require more silicon real estate for the SoC.

simon

by **jamesh** » Sun Jun 10, 2012 5:26 pm

Morgaine wrote:
dom wrote:(My knowledge on this is pretty limited. We bought in a block of hardware and got with it the dwc_otg linux driver. No one at Broadcom knows in detail how it works.)

Never put yourselves at the mercy of closed software. It always bites you eventually.

I've got broken records that repeat less than this.

For those of your too young to know what a record is....http://en.wikipedia.org/wiki/Gramophone_record

by **johnbeetem** » Sun Jun 10, 2012 8:13 pm

tufty wrote:Generally speaking, in linux-land, if it's not already been done, it's probably either a really stupid idea, or it's really, really, hard to do. This applies for GL/ES or OpenVG accelerated X, too.

I would venture to say that things get done either because one or more people got really interested in doing it, or a company has found it important enough to hire people to do it. If a task is uninteresting and unfunded, there's no reason to expect progress.

You can also stop a task dead in its tracks by impeding access to the information needed to perform it. This is a general statement, not applied to any particular task.

by **mahjongg** » Tue Jun 12, 2012 9:41 pm

I'm probably in danger of sounding "blasphemous", but what about a hack that would allow the connection and use of a serial mouse and a PS/2 keyboard?
Mouse on the UART port, and keyboard on a "bitbanged" GPIO port (with interrupts for "key events").
LOL. :mrgreen:

Would probably piss off the Risc OS people because they worked very hard to add a USB stack, but a 20% speed gain may make this a worthwhile effort.

P.S. I'm only kidding! :roll:

Although I definitely would try to add such interfaces if I had a PI, shouldn't be too difficult to design a 2 x 3 cm PCB with these interfaces and a RTC to top it off. For me the "hard part" would be the software.

In fact I think the use of commercially available peripherals (mouse, keyboard) makes implementing USB almost unavoidable if you are designing a "little computer", I'm not sure this is a blessing! I remember having searched for some kind of small microcontroller that would take care of this task, but these seem to be non existant, you quickly end up with some kind of a SoC if you want to use USB peripherals.

by **densipe** » Fri Jun 22, 2012 3:46 pm

I have noticed that at power-on (or after reboot), the interrupts are ~8000. But after time, they drop dramatically. Today, after being left on over night, vmstat shows that the interrupts are 136. can anyone else verify?

Debian.
Linux raspberrypi 3.1.9+ #125 PREEMPT Sun Jun 17 16:09:36 BST 2012 armv6l

by **RaTTuS** » Fri Jun 22, 2012 4:24 pm

what command are you using?

Code: Select all: vmstat -s 188104 K total memory 53104 K used memory 19940 K active memory 23500 K inactive memory 135000 K free memory 11100 K buffer memory 24764 K swap cache 262140 K total swap 0 K used swap 262140 K free swap 69439 non-nice user cpu ticks 0 nice user cpu ticks 30918 system cpu ticks 1088095 idle cpu ticks 2414 IO-wait cpu ticks 97 IRQ cpu ticks 2064 softirq cpu ticks 0 stolen cpu ticks 33509 pages paged in 23956 pages paged out 0 pages swapped in 0 pages swapped out 96246375 interrupts 649970 CPU context switches 1340370267 boot time 7736 forks

by **densipe** » Sat Jun 23, 2012 12:33 am

vmstat ( in was ~8000 after reboot, now 81? if i read it correctly)
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 700 12568 22160 128984 0 0 2 3 81 33 0 0 99 0

vmstat -s
188104 K total memory
175640 K used memory
66616 K active memory
93724 K inactive memory
12464 K free memory
22252 K buffer memory
128984 K swap cache
131068 K total swap
700 K used swap
130368 K free swap
43683 non-nice user cpu ticks
0 nice user cpu ticks
23110 system cpu ticks
17219001 idle cpu ticks
16565 IO-wait cpu ticks
1198 IRQ cpu ticks
4584 softirq cpu ticks
0 stolen cpu ticks
288799 pages paged in
459912 pages paged out
0 pages swapped in
243 pages swapped out
1390400846 interrupts
5657368 CPU context switches
1340238455 boot time
2617 forks

by **reggie** » Sat Jun 23, 2012 2:11 am

mahjongg wrote:I'm probably in danger of sounding "blasphemous", but what about a hack that would allow the connection and use of a serial mouse and a PS/2 keyboard?
Mouse on the UART port, and keyboard on a "bitbanged" GPIO port (with interrupts for "key events").
LOL.

Would probably piss off the Risc OS people because they worked very hard to add a USB stack, but a 20% speed gain may make this a worthwhile effort.

P.S. I'm only kidding! Although I definitely would try to add such interfaces if I had a PI, shouldn't be too difficult to design a 2 x 3 cm PCB with these interfaces and a RTC to top it off. For me the "hard part" would be the software.

In fact I think the use of commercially available peripherals (mouse, keyboard) makes implementing USB almost unavoidable if you are designing a "little computer", I'm not sure this is a blessing! I remember having searched for some kind of small microcontroller that would take care of this task, but these seem to be non existant, you quickly end up with some kind of a SoC if you want to use USB peripherals.

Arduino and the ps2 lib = no need for usb for keyboard on the pi, pi + gpio-mouse driver + joystick (or arduino + mouse + ps2lib + gpio-mouse) = no need for usb for mouse either

It's very doable, it would take you 9 pins (tx/rx + 7 gpio for the mouse driver). It's all built into the kernel, you've just got to add the appropriate structs and pin definitions into mach-bcm2708/bcm2708.c. See here for more details: viewtopic.php?f=50&t=8842

by **rgh** » Sat Jun 23, 2012 9:12 am

RaTTuS wrote:what command are you using?

I used "vmstat 1" which reports the rate per second, every 1 second (or vmstat 60, for example, to give the interrupts per second averaged over 60 second windows).

by **densipe** » Sun Jun 24, 2012 8:52 pm

when the data is collected another way, it comes out as 8000. i see.

Code: Select all: pi@raspberrypi:~$ vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 696 11200 43324 106424 0 0 1 2 26 32 0 0 100 0 0 0 696 11200 43324 106424 0 0 0 0 8071 38 0 0 100 0 0 0 696 10996 43324 106424 0 0 0 0 8089 63 1 4 95 0 0 0 696 10996 43324 106424 0 0 0 0 8062 40 0 0 100 0 0 0 696 10996 43324 106424 0 0 0 0 8064 40 1 0 99 0 0 0 696 10996 43324 106424 0 0 0 16 8043 51 0 0 100 0

by **jbeale** » Fri Jun 29, 2012 7:58 pm

In case of interest: with the R-Pi sitting idle with 'top' load average: 0.00, 0.01, 0.05
No monitor, no video, no USB and no Ethernet devices connected (UART serial port only -see viewtopic.php?f=44&t=9665).
Voltage is measured onboard, TP1-TP2. Ambient surface temperature is 27 C, air temp 24 C.
IR thermometer: MicroTemp MT100 cross-checked with thermocouple sensor.

RPi power draw: 318 mA at 5.0 V (1.59 W) Chip temperatures: SoC: 46 C, Eth/USB: 51 C, SD card: 32 C

after this command as root, and waiting 10 minutes for temperature to stabilize

Code: Select all: echo 1 > /sys/devices/platform/bcm2708_usb/bussuspend

RPi power draw: 182 mA at 5.0 V (0.91 W) Chip temperatures: SoC: 40 C, Eth/USB: 39 C, SD card: 30 C

so the system uses 1.59 W when idle but Eth/USB on, and 0.91 W when Eth/USB shut down, nearly half the power. This could make a difference in some possible use cases, where you want to power up the high-bandwidth link only when needed. Can the Eth/USB system be turned back on after "bussuspend" without doing a full reboot, and if so how? The obvious 'echo 0 > /sys/devices/platform/bcm2708_usb/bussuspend' has no apparent effect- power draw remains 182 mA and no USB device can be mounted.

by **secretagent** » Sat Jun 30, 2012 4:32 am

jbeale wrote: Can the Eth/USB system be turned back on after "bussuspend" without doing a full reboot, and if so how? The obvious 'echo 0 > /sys/devices/platform/bcm2708_usb/bussuspend' has no apparent effect- power draw remains 182 mA and no USB device can be mounted.

One easy way is to compile dwc_otg as a module and then reload the module when you want to start the usb back (I tried it and it seems to work). I don't know if there is a more "proper" way. Note that in order to be able to reload the module a small change is required to make the driver clean up after itself after it has been unloaded:

Code: Select all: diff --git a/drivers/usb/host/dwc_otg/dwc_otg_driver.c b/drivers/usb/host/dwc_otg/dwc_otg_driver.c index 0e22013..9ef9b9d 100644 --- a/drivers/usb/host/dwc_otg/dwc_otg_driver.c +++ b/drivers/usb/host/dwc_otg/dwc_otg_driver.c @@ -633,6 +633,7 @@ static int dwc_otg_driver_remove( release_mem_region(otg_dev->rsrc_start, otg_dev->rsrc_len); pci_set_drvdata(_dev, 0); #elif defined(PLATFORM_INTERFACE) + release_mem_region(_dev->resource->start, _dev->resource->end - _dev->resource->start + 1); platform_set_drvdata(_dev, 0); return 0; #endif

by **clickykbd** » Sat Jun 30, 2012 7:49 am

Code: Select all: echo 1 > /sys/devices/platform/bcm2708_usb/bussuspend

Handy tip! Am I correct that to re-enable it is the following? Or is the 'busconnected' the way to go?

Code: Select all: echo 0 > /sys/devices/platform/bcm2708_usb/bussuspend

by **dom** » Fri Jul 06, 2012 6:28 pm

We've got a new patch. If you update firmware, then:

Code: Select all: echo on | sudo tee /proc/dwc_sof/SOF_reduction

The interrupts wil be reduced to 300 per second when idle (more when USB is busy).

This has some pros and some cons.

The main benefit is it reduces CPU usage by 10-20%.
Mem bandwidth test improved by 10%
iperf increased by 2%

But:
ping time increases by 4ms on average.
This causes a nfs boot to increase from 39s to 93s.
In the worst case, a copy of 1000 zero length files over nfs increased from 6.8s to 38s.

I'd be interested to hear about other benchmarks that are improved or worsened by enabling this change.

by **gregeric** » Fri Jul 06, 2012 9:24 pm

New patch + shell line gives me stickeeeeeee keys, unusable. Running Raspbian Pisces r1 + updates.

by **dom** » Fri Jul 06, 2012 10:05 pm

gregeric wrote:New patch + shell line gives me stickeeeeeee keys, unusable. Running Raspbian Pisces r1 + updates.

Interesting. Do you have another keyboard to try?
Anyone else seeing this?

by **clickykbd** » Sat Jul 07, 2012 2:39 am

i'll try this too. Curious, how do you tell which firmware revision you are on?

by **ukscone** » Sat Jul 07, 2012 2:40 am

clickykbd wrote:i'll try this too. Curious, how do you tell which firmware revision you are on?

/opt/vc/bin/vcgencmd version

&

uname -a

will tell you

by **clickykbd** » Sat Jul 07, 2012 3:10 am

On wheezy. I get stuck keys very rarely... (but i used to a lot with my other keyboards). This keyboard has been more stable but seems to do device resets fairly often. BUT the frequency of those resets seems to have increased with this patch, making the shell far less usable. It will stick a key if the reset happens to be timed perfectly with some typing, but this keyboard has been a vast improvement over the other 3 I tried. Seeing similar behavior with or without the patch, but seems the frequency has changed.

They happen with quite a frequency when everything is idle.

Code: Select all: Jul 6 21:56:03 raspberrypi kernel: [ 555.511434] usb 1-1.3.2: USB disconnect, device number 52 Jul 6 21:56:03 raspberrypi kernel: [ 555.761102] usb 1-1.3.2: new low speed USB device number 53 using dwc_otg Jul 6 21:56:03 raspberrypi kernel: [ 555.874326] usb 1-1.3.2: New USB device found, idVendor=154a, idProduct=0002 Jul 6 21:56:03 raspberrypi kernel: [ 555.874374] usb 1-1.3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Jul 6 21:56:03 raspberrypi kernel: [ 555.874397] usb 1-1.3.2: Product: Input Device Jul 6 21:56:03 raspberrypi kernel: [ 555.874413] usb 1-1.3.2: Manufacturer: ID Innovations Inc. Jul 6 21:56:03 raspberrypi kernel: [ 555.906546] input: ID Innovations Inc. Input Device as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/input/input47 Jul 6 21:56:03 raspberrypi kernel: [ 555.907701] generic-usb 0003:154A:0002.005F: input: USB HID v1.00 Keyboard [ID Innovations Inc. Input Device] on usb-bcm2708_usb-1.3.2/input0 Jul 6 21:56:03 raspberrypi kernel: [ 555.948936] generic-usb 0003:154A:0002.0060: hiddev0: USB HID v1.00 Device [ID Innovations Inc. Input Device] on usb-bcm2708_usb-1.3.2/input1

They were happening so fast it was hard for me to grab this text from serial console during tail -f.

I just took the hub out of the equation and still get these resets with keyboard as the only USB device, but they do seem slightly less frequent without the hub, but just barely so.

Before I even activated this patch, while doing rpi-update, I was getting CONSTANT resets. I hadn't seen that yet.

I am not 100% convinced my problems are not perhaps hub or power related. I have an alternate microUSB cable on the way, and a meter... if it is power related I might be able to make more progress then.

by **clickykbd** » Sat Jul 07, 2012 3:18 am

just turned that patch off with only keyboard attached. Things are back to my "occasional reset" status when idle (maybe once every 5 minutes or so).

by **rtramon** » Sat Jul 07, 2012 10:08 am

Applied the patch in my head-less raspi. Interrupts 8100-ish to 600-ish. No abnormal effects.

by **chris_c** » Sat Jul 07, 2012 7:14 pm

I assume you need to

Code: Select all: echo on | sudo tee /proc/dwc_sof/SOF_reduction

each boot?

or does the new firmware do this automagically now?

by **asb** » Sat Jul 07, 2012 7:20 pm

chris_c wrote:I assume you need to

Code: Select all
echo on | sudo tee /proc/dwc_sof/SOF_reduction

each boot?

or does the new firmware do this automagically now?

You could edit /boot/cmdline.txt and add dwc_otg.sof_setting=1 I believe. Stuck keys seem to be a problem for me with the sof reduction enabled.

by **chris_c** » Sat Jul 07, 2012 9:30 pm

rats - my keyboard regularly sits resetting for 5 seconds at a time, and frequently misses key released, what a shame!!!
Is a different model of keyboard really likely to make a difference???

by **mpthompson** » Sun Jul 08, 2012 7:08 pm

For a number of weeks I've been having a lot of USB problems with my Raspberry Pi. With my two USB keyboards I would see a lot of dropped keys with the problem getting worse when LXDE is started. Also, when running LXDE I would see networking take big hit in performance (ssh sessions would slow to a crawl) and my USB hard drive became unusable.

Eventually, I discovered the problem seems to be that both of my USB keyboards have built-in low-speed USB 1.1 hubs that allow a mouse to be plugged into the keyboard. If I use a USB/PS2 adapter with the keyboard (one of the keyboards has a PS2 plug) the low-speed USB 1.1 hub internal to the keyboard is removed from the USB bus and all my USB problems disappear. My guess is that the Raspberry Pi USB drivers have problems with low-speed hubs and it's not a well tested configuration. The developers probably assumed people would only want to connect USB 2 hubs to the Raspberry Pi USB bus.

To others having USB keyboard issues, check to see if it has a built-in low-speed USB hub. If so, look to replace the keyboard with one that doesn't have a USB hub or use a USB/PS2 adapter if you keyboard also has a PS2 plug.

Hopefully this will help some people while we all wait for continued improvements in the Raspberry Pi USB drivers to be made.

8000 interrupts per second when idle!

Who is online