Interesting "Competitors" for the Raspberry Pi

I like the thought of the 16 core machine ! To be honest, I think the Pi will spawn a number of alternatives / competitors and sooner or later one will hit another price / performance ratio that resonates with the market.

If I had a bit more cash, I'd think about committing $99 to that kickstarter :-)

The hardware specs look very nice for all the new low-cost ARM computers,

with more ram and faster cpu's than the RPi.  What the articles don't say,

and what we've all learned to ask is: does the USB work without dropping packets? 

Can I use a keyboard with a built-in hub?  Can I mix USB 1.1 with USB 2.0? 

Can I use any SD card?  at high speed? Is X11 accelerated?  Does mplayer work? 

Are the drivers included in mainline Linux?

Eventually it will happen.

I'm not surprised with that lead time as I can't see the market being huge for them. I would find it a bit hard to believe that the fundamental problem is with the USB core. There are tones of MCUs on the market with USB Host functionality and I haven't heard of others having the limitations that are happening with the RPi. Although, it might make sense that it was a know problem and presented to the foundation and offered to them at a discount if they could live with the limitations. For them to continually push for users to just use a powered hub might make sense and support the fact that they really don't address this as a real problem.

I know 1st hand that not all products are scrapped at testing and are offered to 2nd tier customers at a discount if they can live with the "limitations" of the "defective" product.

Mentioning the junk USB controller brought to mind a little question.  Do any other devices of Broadcom's apart from the unfortunate BCM2835 use the same USB core?

Not sure about that, but seemingly there's other stuff out there that does use the same USB core. There are some ongoing efforts to get a driver of some description into the mainline kernel and apparently this was happening independently of the Pi.

That said, GregKH had some interesting comments on the USB hardware recently:

http://article.gmane.org/gmane.linux.kernel.rpi/78

http://article.gmane.org/gmane.linux.kernel.rpi/80

Is X11 accelerated?

No.

Does mplayer work? 

See above..

Are the drivers included in mainline Linux?

No.

and those answers seem reasonably similar across all of the various arm boards.  No X11 accel is usually due to the same problem of no useful documentation available to enable writing an opensource driver. I wouldn't hold my breath waiting for that to change. There is an effort to reverse engineer the Mali GPU drivers, but even there if you look at x86 and the work that's been going for years to produce an nVidia driver I'd not expect too much in the lifetime of any of these boards.

Other than GPU, most things seem to be functional, but when you start digging it's amazing how many of the other boards have network, SATA, or whatever hanging off USB anyway. Experience with USB on the Pi and the tendency of a lot of the arm stuff to be aimed at phones, tablets or such like consumer crap and therefore have usb-otg certainly makes me thing twice about anything with arm & usb in the same chip

Interesting comments from GergKH. Forgive my ignorance but if the USB core is in the arm then wouldn't Broadcom have just licensed it from ARM? I'm in no means defending Broadcom but if the core is bad and it's a standard core then wouldn't the USB troubles be more wide spread across other designs?

George Ioakimedes wrote:

 

Interesting comments from GergKH. Forgive my ignorance but if the USB core is in the arm then wouldn't Broadcom have just licensed it from ARM? I'm in no means defending Broadcom but if the core is bad and it's a standard core then wouldn't the USB troubles be more wide spread across other designs?

The USB core is from Synopsys.  Here's the quote from the BCM2835 ARM Peripherals document: "The USB core used in the Videocore is build from Synopsys IP.  Details about the block can be found in DWC_otg_databook.pdf (Which can also be downloaded from https://www.synopsys.com/dw/ipdir.php?ds=dwc_usb_2_0_hs_otg)".

I don't know what's required for a successful registration at Synopsys to download the document.

My opinion from reading a lot about RasPi USB issues is that it's not that the Synopsys core is bad, it's just that the core is limited and requires a lot of software support to act as a general-purpose host controller.  In Roku, the BCM2835 just needs to talk to a Flash drive, while RasPi Model B goes through a USB hub (adding another layer of problems) and has peripherals like Ethernet which produce input data asynchronously.

Also, my understanding is that the BCM2835 was designed as a multi-media chip.  The ARM11 is there to provide control and I/O, but the bulk of the work in normal BCM2835 applications is video decode using the GPU and audio processing using the alleged DSP.  So in Roku, the GPU is doing most of the work and the ARM11 can easily keep up with USB tasks.  In a cell phone, the GPU and DSP together do most of the work.

With RasPi, we're using the ARM11 as a work-horse GNU/Linux CPU with oodles of tasks and lots of simultaneous I/O, easily maxing out the ARM11 in a number of applications.  IMO the BCM2835 is not a great GNU/Linux engine, but it's cheap and that was RasPi designers' primary concern.  Where else can you get a board that runs GNU/Linux and has high-performance graphics for US$25 or US$35?

My understanding is that the USB software is getting better as people better understand what's causing the problems.  I've also read that the low-level driver provided by Synopsys -- perhaps as "demo" code -- is very hard to understand so progress is slowed down accordingly.

These comments are JMO based on what I've read.  YMMV

George Ioakimedes wrote:

 

Interesting comments from GergKH. Forgive my ignorance but if the USB core is in the arm then wouldn't Broadcom have just licensed it from ARM? I'm in no means defending Broadcom but if the core is bad and it's a standard core then wouldn't the USB troubles be more wide spread across other designs?

Well it's not really clear what parts are 'in the arm', what are part of the GPU and what are standalone.  Like most SoC's the bcm2835 is built up out of lots of building blocks glued together. Some are standard IP blocks from Arm, some like the GPU are Broadcom Propietary, and it appears that at least the usb and sdcard are thrid party.

Like any business, which option was the cheapest and was reasonably good enough for the initial design criteria ?   As John says, the SoC was originally intended for something other than the Pi, so different design considerations mean something not ideal for what it's now being asked to do.

Has anyone done any tests on a Model A board or popped off the LAN9512? That would allow a USB device to plug directly into the BCM2835. I could see where the LAN9512 could be part of the problem since it's bridging ethernet onto the USB bus. I can understand the slow throughput and dropped characters when typing but what really has me scratching my head is whn you plug in a USB drive and the system reboots. Clearly there's some panic event happening but nobody has said what it is. For me it seems like there are multiple potential issues happening and my bet on the reboots are tied to the LAN9512 1.8V output tied back into the BCM2835 (as discussed elsewhere).

All I want to do is understand the problems and potentially help fix them since currently there isn't any other board out there with the potential of this board at a $35 price.

George Ioakimedes wrote:

 

... what really has me scratching my head is whn you plug in a USB drive and the system reboots.

This might be a problem with 5V0 dipping when you plug in the USB drive due to "charge sharing" issues.  We saw this on the BeagleBoard, and here's my explanation of the phenomenon: http://elinux.org/BeagleBoardFAQ#USB_OTG_connection_.233

I don't know how serious this is in practice on RasPi.  The proper solution is to have "slow start" circuits that limit +5V current to a newly-inserted USB device so that its capacitor charges up slowly and doesn't cause a dip in 5V0.  But as Peter Falk says in All the Marbles: "Those frills cost money".

I've watched the 5V rail on the scope and although I do seem some dip it wasn't much. The BCM2835 only has connection to the 5V rail for what I'm assumming is a battery monitor so a dip to ~4.7V shouldn't raise any panics. I can understand how on the BB a USB device might be dropped when the rail falls below the USB lower level but that in real practise doesn't happen as often as you might think.

I agree with the slow start. A simple part like a TPS2560 (or others that are lower cost) would have been a better solution than the polyfuses and would not have impacted the cost.

If the Raspberry Pi did not use the USB bus for ethernet,

1.  would that cause less issues with USB devices?

2.  would it be much more expensive?

3.  Would that mean the LAN9512 USB controller would be removed?

If the Raspberry Pi did not use the USB bus for ethernet,

1.  would that cause less issues with USB devices?

2.  would it be much more expensive?

3.  Would that mean the LAN9512 USB controller would be removed?