USB discussions getting a bit heated

Reading that "USB - the Elephant in our Room" thread on the RPF forum again is really depressing.

From the fanbois' typical "It works for me so your complaints make no sense", or "You shouldn't expect it to work because the Foundation makes no money", to JamesH's repeated strawman of "We would need to test EVERY SINGLE USB DEVICE", it makes you wonder what it is about the Foundation that its most vocal defence comes from those with impaired logic ability.  The correlation seems strong.

There's probably some kind of thesis in psychiatry available there.

Reading that "USB - the Elephant in our Room" thread on the RPF forum again is really depressing.

Don't read it then   I think it's unfortunate that while there's a couple of people who seem willing to discuss solutions, Pete & dom spring to mind, most of the productive discussions are getting swamped in the noise.

selsinork wrote:

 

Don't read it then

I haven't been following RPF for months personally, which has greatly improved my quality of life.

But when one of you masochists links to something over there then I do follow your links to understand what you're talking about.  Fortunately it doesn't happen often!

I think it's unfortunate that while there's a couple of people who seem willing to discuss solutions, Pete & dom spring to mind, most of the productive discussions are getting swamped in the noise.

Amid all the noise and illogic, I did notice one positive thing:  the Foundation is now admitting openly that Pi's USB is faulty, you don't need to read between the lines to infer it,  The admission is done very much through gritted teeth, and fanboi logic is of course still unable to grasp that it has been admitted, but nevertheless the existence of the problem is now official.

Also, the extent of the problem is now accepted to be all Pi boards, not just a few rogue ones.  Anyone who thinks that their Pi doesn't have the problem will find that actually it does if they add a USB device or two.

There seems to be a limit of 8 endpoints, and by default the Model B seems to use one for the host, one for the LAN9512 hub itself, one for Ethernet, and one for each of the LAN9512's host ports, which is 5 altogether.  Add an external hub and that adds one endpoint for a 4-port or two endpoints for a 7-port (because a 7-port is usually implemented as two 4-port hubs in cascade), which means that you can attach only one or two USB devices to a hub before the USB system dies completely on all ports.  That kills off your networking too of course.

What's more, the limit of 8 endpoints doesn't mean that Pi's USB will work if you use fewer.  It just means that it won't die completely and totally if everything else is OK and if the Pi can cope with the interrupt rate.  Unfortunately there's more.

In addition, and this is the killer, even if you use fewer endpoints than the maximum, USB events will get lost occasionally on all Pi boards with the current driver if you use low-speed or full-speed USB devices, because split transactions occasionally get broken by Linux interrupt response latency often being longer than 1 ms, which causes the USB event to be discarded.

Linux is not a realtime operating system, so if your driver or your hardware require interrupt response within a specific time constraint, correct operation will fail periodically when the system has other work to do.  There is always other work to do in a Linux system, which is why the Pi's USB has a continuous non-zero error rate no matter how few USB endpoints you use.

In engineering, the first step to finding a solution is admitting the problem, so this is progress.  But god, that first step sure is hard with RPF.

Morgaine.

Anyone who thinks that their Pi doesn't have the problem will find that actually it does if they add a USB device or two.

My Pi doesn't have a problem. Really.

lack of a USB connector probably has something to do with it

It looks like the ethernet function of the lan9512 uses three endpoints, one bulk in, one bulk out and one interrupt. With just a simple keyboard and mouse my system lists 8 active endpoints.  Oh, and hotplugging the keyboard/mouse just reset one of the newer ones. The original one doesn't have that problem.

So is that 8 endpoint limit a hardware one ?  Or a crappy driver problem ?    The actual question has to be whether it's fixable in software or not and what limits that might have.

If it's simply an interrupt latency problem there will be ways to help mitigate that. One possible way to help would be to up the clock speed to 1GHz as they've mentioned they want to find a way to do, it's not like that's a cure, more like a short term band-aid while other avenues are explored.

It probably also explains why people like me who don't use a bloated deskptop distro and literally have init, two gettys, dhcpcd and sshd running really don't see the problem to the same degree - I'm simply not adding lots of extra latency running lots of irrelevant crap. I do see dropped and/or repeating keypresses now and again, so no denying there is an issue.

selsinork wrote:

 

My Pi doesn't have a problem. Really.

<image>

lack of a USB connector probably has something to do with it

Hahaha, nice one.

It looks like the ethernet function of the lan9512 uses three endpoints, one bulk in, one bulk out and one interrupt. With just a simple keyboard and mouse my system lists 8 active endpoints.  Oh, and hotplugging the keyboard/mouse just reset one of the newer ones. The original one doesn't have that problem.

Oh dear, it's a bit worse than I gathered from that thread then, the hard limit arrives a bit sooner.

So is that 8 endpoint limit a hardware one ?  Or a crappy driver problem ?    The actual question has to be whether it's fixable in software or not and what limits that might have.

I gather that 8 endpoints is a hardware limit because a Foundation or Broadcom person said that they found it in the Verilog for the SoC's USB controller, IIRC.  The interrupt rate issue is completely separate from that.

If it's simply an interrupt latency problem there will be ways to help mitigate that. One possible way to help would be to up the clock speed to 1GHz as they've mentioned they want to find a way to do, it's not like that's a cure, more like a short term band-aid while other avenues are explored.

It probably also explains why people like me who don't use a bloated deskptop distro and literally have init, two gettys, dhcpcd and sshd running really don't see the problem to the same degree - I'm simply not adding lots of extra latency running lots of irrelevant crap. I do see dropped and/or repeating keypresses now and again, so no denying there is an issue.

You're right to call these "bandaids", and they're poor ones because they cannot make the USB errors disappear but only reduce the rate at which they occur.  That rate cannot be made arbitrarily small on Linux without either adding realtime patches so that the housekeeping processes receive guaranteed scheduling priority, or else removing the need for realtime response in the driver.  If the SoC's crappy USB core requires that split transactions be handled in software then the second alternative is not available.

Even a completely quiescent Linux system has processes that get scheduled to run occasionally, even if it's only the periodic filestore sync/update process that is scheduled by a timer.  If scheduling triggers in the middle of USB split transaction handling, the probability that the USB event will be lost is non-zero.

It's just the way Linux works, and all Unixes have worked that way since the dawn of time, so Broadcom designers can hardly express surprise nor point a finger of blame at Linux.  If they genuinely are surprised then Broadcom's problems run far deeper than a broken Pi.

Morgaine.

I gather that 8 endpoints is a hardware limit because a Foundation or Broadcom person said that they found it in the Verilog for the SoC's USB controller, IIRC.  The interrupt rate issue is completely separate from that.

Eeewww... a limitation that's hard coded into silicon is going to be difficult   It's what comes of never being designed for what it's being asked to do. 

The model A with SPI ethernet is looking more and  more appealing.   However, with the pragmatic hat on for a moment, if the interrupt rate problem can be resolved it still mostly meets the design goal for a small educational device with wired ethernet, mouse & keyboard. I say mostly as there's a lot to be said for being able to save stuff to a usb key as well as the sd-card, but still, it's not completely fatal - inconvenient yes.

It is going to be really hard, making USB OTG work as a "host" if you excuse my French is a "***" ...

I found some documentation from Synopsys (http://www.synopsys.com/dw/ipdir.php?ds=dwc_usb_2_0_hs_otg) but didn't have time yet to even browse through it.

-J

The model A with SPI ethernet is looking more and  more appealing.   However, with the pragmatic hat on for a moment, if the interrupt rate problem can be resolved it still mostly meets the design goal for a small educational device with wired ethernet, mouse & keyboard. I say mostly as there's a lot to be said for being able to save stuff to a usb key as well as the sd-card, but still, it's not completely fatal - inconvenient yes.

Hmmm, that would be some interesting project to try, as far as I remember there are some Linux drivers for the Microchip standalone Ethernet controllers, obviously don't expect to power the thing from the regular 3V3 power supply.

I used to produce this board based on the ENC424J600

I'll put on my to-do list of things to try in my protoboard setup... Good idea selsinork

-J

selsinork + jamodio:  TCP offload and USB offload beckons, as you are both suggesting.

It's certainly an engineering solution to the problem, but the trouble is, what's left of the Pi if you have to add those externally?  Just a standalone multimedia chip with SD card and low-end ARM.  It's no longer appealing for $35, and doesn't even make any sense in a networked world.

selsinork + jamodio:  TCP offload and USB offload beckons, as you are both suggesting.

It's certainly an engineering solution to the problem, but the trouble is, what's left of the Pi if you have to add those externally?  Just a standalone multimedia chip with SD card and low-end ARM.  It's no longer appealing for $35, and doesn't even make any sense in a networked world.

Ohh no, it is just for experimenting. I'd rather put more time/money on Beagle or Panda boards, I'm waiting for the guys from Olimex that said their board should be about ready in September.

If RPF does not come up with a decent solution which may require to dig deep into the design, besides being an interesting gadget to tinker with and some stuff that can be donde with model A, asuming you can hookup a keyboard and a mouse that works with an external hub, IMHO the thing is dead.

-J

It's no longer appealing for $35, and doesn't even make any sense in a networked world.

Ok, but... Alternatives ?   With reliable, even if slow, ethernet it still works for me. If we offload anything much then the model A is obviously a better starting point.

If usb can be fixed - within limits of the silicon - that's better. But as you keep saying, it needs to be reliable and 'just work'.

Hmmm another alternative would be, based on something close to the current design but fixing the power supply issues and other things that Pete may have on the list, os for the distributors to bundle the board with a power supply, keyboard and mouse that were proven towork at an attractive price, and it can still be a low cost platform for education.

But a that time, I'd guess that some Linux distro would be running on the APC board, yes sans GPIO now and a bigger board but you get other features ...

-J

selsinork wrote:

 

Ok, but... Alternatives ?

Zillions of alternatives, as long as one is free to choose designs and components in response to functional requirements.  Unfortunately RPF is driven more by politics and facial egg than by engineering so it's academic, but anyway ....

The simplest solution is to use the most appropriate SoC or SoCs for Pi version 2.  If the BCM2835 is still the best multimedia device available, fine, use it, but it's crap for USB, networking, and computing, so put another SoC next to it to do those functions better.

This is no theory, I'm looking at the basis of a solution here on my table.  Since the BeagleBone's TI AM3358/9 SoC costs $5 in volume, throw away the Pi's LAN9512 and add the TI SoC instead.  That would give the Pi a more powerful Cortex-A8, on-chip Ethernet MAC, two on-chip USB (one host and one OTG I think), and a zillion hardware ways of interfacing to the BCM2835 for multimedia.

It's totally pointless even thinking about it though.  RPF has all the mobility of a block of granite entombed in an ancient lava flow.

Morgaine.

If the BCM2835 is still the best multimedia device available, fine, use it,

I'm still uncertain how that matters. Right now all that potential still hasn't found an outlet. Lack of codecs prevents serious multimedia use and lack of accelerated X driver means you get no benefit elsewhere. Those things are being worked on, but without a timetable. So it could still be the best unused multimedia device in 5 years.

Since the BeagleBone's TI AM3358/9 SoC costs $5 in volume, throw away the LAN9512 and add the TI SoC instead.

Hmm. I'd be tempted to throw away much more.  I know it's been commented on before, but if that thing is $5 why hasn't someone done something like the Pi at equivalent cost using it ?  Or alternatively is the BCM2835 available to RPF at significantly less ?

selsinork wrote:

 

If the BCM2835 is still the best multimedia device available, fine, use it,

I'm still uncertain how that matters. Right now all that potential still hasn't found an outlet. Lack of codecs prevents serious multimedia use and lack of accelerated X driver means you get no benefit elsewhere. Those things are being worked on, but without a timetable. So it could still be the best unused multimedia device in 5 years.

+1.

Reminds me of another unrelated discussion I was having, about hidden costs and liabilities.

The BCM2835's closed nature is proving a liability to the Pi community already, and the USB core's closed nature is proving a liability to Broadcom already, as well as to the community.  It's somewhat incredible that the Pi is being marketted on the multimedia strengths of the BCM, yet neither X11 nor open media players like mplayer are accelerated yet just because it's closed tight as a drum.

Well I suppose I'm "reaching out" to Broadcom/RPF and throwing them a crumb (not that they deserve it) by suggesting to continue using their device to handle the graphics at least, but in reality you're right.  Designing in a liability is not sensible.

Morgaine.

[Addendum:  It's worth pointing out that chucking out the BCM2835 wouldn't leave us without graphics.  The TI AM3358/9 contains a PowerVR SGX530 GPU, and it's no slouch.  Of course it's nearly as closed as the Broadcom so it's still a liability, but it comes for free with a Cortex-A8 and proper USB and Ethernet controllers.  Oh and <shock horror>, documentation.]

PS. I've  just discovered that the Ethernet MAC on the TI AM 3358/9 is 10/100/1000 !!  It's only the PHY on the BeagleBone that limits it to 100Mbps.  So it's even more "proper" than I thought. :-)

Morgaine Dinova wrote:

PS. I've  just discovered that the Ethernet MAC on the TI AM 3358/9 is 10/100/1000 !!  It's only the PHY on the BeagleBone that limits it to 100Mbps.  So it's even more "proper" than I thought. :-)

Actually, the AM3358/9 have versions with two 10/100/1G Ethernet ports which can be coupled to make a three port Ethernet switch (the third port being the CPU).  It also has support for IEEE 1588 Precision Time Protocol, if you really want to know what time it is

John Beetem wrote:

 

Actually, the AM3358/9 have versions with two 10/100/1G Ethernet ports which can be coupled to make a three port Ethernet switch (the third port being the CPU).  It also has support for IEEE 1588 Precision Time Protocol, if you really want to know what time it is

Awesome chip.  It needs someone to make a rock-bottom board using it to compete at the Pi price niche.

There are quite a few things that could be whittled off the BeagleBone to bring the BOM cost down from $89:

• The PMIC expansion header and LCD/backlight interface are not essential.
• The PMIC itself has a lot of extra features outside of power management that may be superfluous in a bottom-end board so a cheaper PMIC may be available.
• The front-end USB hub is not essential.
• The front-end FT2232H that connects to the USB hub is not essential.
• The BeagleBone's USB device/host flexibility could be reduced by routing the SoC's two USB OTG ports to a combined host USB connector for lower cost.
• The reset button is not essential.
• The two large expansion headers provide good physical support for daughterboards, but could be shortened to reduce cost.
• If one must play RPF-type marketing tricks, don't supply the micro-SD card with the board.
• It must be remembered that in addition to BOM reductions, there will be at least one increase:  HDMI socket and associated circuitry, which must be on-board..

I bet that such reductions could get the BOM cost down down to the Pi price niche for Pi-type volumes.  BeagleBone is made in much smaller volumes than Pi, so their volume price breaks are probably not very good currently, but with volume sales that would change dramatically.

Morgaine.

Morgaine Dinova wrote:

 

I bet that such reductions could get the BOM cost down down to the Pi price niche for Pi-type volumes.  BeagleBone is made in much smaller volumes than Pi, so their volume price breaks are probably not very good currently, but with volume sales that would change dramatically.

I think the key here is volume.  In large volumns BB could probably come down to under US$50 even with the current BOM, and the DVI cape could come down to US$15 instead of US$50.  Another cost factor is USA manufacturing, but I'm happy to pay a bit more and not wonder about quality.

I like having a separate video cape so you have the choice of VGA (coming soon!) or LCD.  But à la carte is always going to be more expensive.

True, the flexibility of BeagleBone is very high, but unfortunately price is king.

Sadly, the board is priced above the point on the budget radar where price is no barrier for the average pocket in the "West" (often said to be the price of an evening out).  But the board is also so well specified that there is ample room for a bottom-end product of that line created through feature reduction.

The Beagle family would be rounded off beautifully with a "BeagleBite" (to stay within their naming meme), where everything except reliability is sacrificed at the altar of BOM cost.  And when sales rocket in reverse exponential proportion to price, the team would find itself with a whole product line ready to cater for different use cases, unlike Pi.

Morgaine.