USB discussions getting a bit heated

From what I've read, it seems that the fundamental problem is that the BCM2835 SoC has a bare-bones USB host controller which requres a lot of the ARM processor.  Such a USB host controller works fine in BCM2835 intended applications, such as Roku, but if you try to use the ARM11 as a high-performance GNU/Linux engine talking to dozens of USB devices you will run into limitations.  It also sounds like documentation for the SoC's USB host controller is not available and that the low-level "open source" software suffers from "security through obscure code".  If this is indeed the case, it will be hard to improve things.

Please let me know if my impressions are incorrect.  I would be delighted to hear that open documentation for the USB host controller is available (link?) and that the low-level driver is perfectly understandable and well-documented (link?).

From what I've read, it seems that the fundamental problem is that the BCM2835 SoC has a bare-bones USB host controller which requres a lot of the ARM processor.  Such a USB host controller works fine in BCM2835 intended applications, such as Roku, but if you try to use the ARM11 as a high-performance GNU/Linux engine talking to dozens of USB devices you will run into limitations.  It also sounds like documentation for the SoC's USB host controller is not available and that the low-level "open source" software suffers from "security through obscure code".  If this is indeed the case, it will be hard to improve things.

Please let me know if my impressions are incorrect.  I would be delighted to hear that open documentation for the USB host controller is available (link?) and that the low-level driver is perfectly understandable and well-documented (link?).

Apparently the documentation for the USB controller isn't even available

to Broadcom, and they are apparently trying to figure out how it works by

reading the code for the driver.

they are apparently trying to figure out how it works by

reading the code for the driver.

Some people, outside the rpf, looked at doing that to get a working driver into the 3.5 porting effort. They gave up after a while, the code seems to be a steaming pile of.......

John Beetem wrote:

 

From what I've read, it seems that the fundamental problem is that the BCM2835 SoC has a bare-bones USB host controller which requres a lot of the ARM processor.  Such a USB host controller works fine in BCM2835 intended applications, such as Roku, but if you try to use the ARM11 as a high-performance GNU/Linux engine talking to dozens of USB devices you will run into limitations.  It also sounds like documentation for the SoC's USB host controller is not available and that the low-level "open source" software suffers from "security through obscure code".  If this is indeed the case, it will be hard to improve things.

This is EXACTLY the same conclusion that I have reached.

The Pi is in reality not a general purpose computer.  It's half a computer, with the ARM being used to fill in the hardware gaps that let the SoC be designed at the lowest possible cost.  If you try to use the ARM at the same time for normal computing, you can kiss your SoC's correct functioning goodbye.

It's this that is wreaking havoc when you attach a correctly-working self-powered hub with added devices downstream.  Linux accepts it, because it doesn't realize what the purpose of the ARM is within the BCM2835.  In reality it should say "Sorry Dave, I don't have the CPU headroom for that" and refuse to attach.

Morgaine.

it should say "Sorry Dave, I don't have the CPU headroom for that" and refuse to attach.

LOL...  but does sound work well enough for it to sing the song ?

Morgaine Dinova wrote:

 

The Pi is in reality not a general purpose computer.  It's half a computer, with the ARM being used to fill in the hardware gaps that let the SoC be designed at the lowest possible cost.  If you try to use the ARM at the same time for normal computing, you can kiss your SoC's correct functioning goodbye.

The BCM2835 is a powerful media processor with a cheap ARM11 hanging off the side as an I/O processor to take care of housekeeping tasks like USB.  We're allowed to use the housekeeping processor for pretty much anything we want, and it's a pretty nice little GNU/Linux processor.  It's sure a lot more powerful than the PDP-11/45 I first used for Unix   We have limited access to the media processor, i.e., we've been given a book of spells and we're allowed to invoke those spells but have no idea what magic makes the spells work.

RasPi does meet its requirements for being a good platform for learning about programming.  Kudos.  RasPi is cheap enough that you can play without worrying about breaking the family PC, and it's a very responsive platform for compiling and running reasonably sized programs.  It can also be a nice little platform for some embedded projects, such as the Pi in the Sky.

I like to compare RasPi to a supercomputer.  It has a powerful supercomputing engine, but we're only allowed free access to the I/O processor.  It's disappointing for people who see that RasPi could so easily be so much more if they would just release documentation, but sometimes life is like that.  There are plenty of alternatives for people who want a more open system.

John Beetem wrote:

 

We're allowed to use the housekeeping processor for pretty much anything we want, and it's a pretty nice little GNU/Linux processor.

We're allowed to use it, sure.  The trouble is that when we do start to use it, the SoC's housekeeping is compromised and perfectly normal computer operations (like receiving USB events) start failing.

The ARM core is working perfectly, but that's not the whole computer.  Add in the I/O systems and it is no longer working perfectly.

John Beetem wrote:

RasPi does meet its requirements for being a good platform for learning about programming.  Kudos.  RasPi is cheap enough that you can play without worrying about breaking the family PC, and it's a very responsive platform for compiling and running reasonably sized programs.  It can also be a nice little platform for some embedded projects, such as the Pi in the Sky.

If everything worked as it should, it would be ideal for everything you mentioned. However if one can't rely on it to function reliably, then instead of worrying about breaking the PC, one has to worry about having the right setup to get the Pi to work.

Morgaine wrote:

 

It should be pointed out that this isn't a case of the community being over-demanding, and the complaints aren't coming from people intent on destructive stress testing.  They come from ordinary users who are expecting (shock horror!) that when they attach a common USB device and it is recognized by an available driver, that it should then work.

+1