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.

coder27 wrote:

 

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?

The Pi's USB problems stem from use of that dreadful USB controller, which must be seen as a hardware fault in the Broadcom SoC.  Presumably this problem is also shared by any other device which uses that same  piece of junk hardware.

I'm not aware of any other computer in existence with such an utterly broken USB.  All past and future competitors are likely to be completely superior to Pi in that respect.

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?

I sure hope that the answer is 'No', otherwise the potential exists for the next generation of Pi to have the same USB problems as the current one.

Doesn't the Roku HD use almost the same design (BCM2835 and LAN9512) yet AFAIK there are no constraints with their USB port. http://www.mycablealternatives.com/2011/07/roku-2-xs-teardown/

How would you know the roku isn't having the same usb problems?

Most people will just use the usb port on that to connect an usb stick, and they don't have a way to figure out if there is an issue.

Besides that, some on the foundation say that the problems occur due to the interrupt latency being 2 high. One of the troublemakers for that

seems to be the sd card driver. The roku has an on board flash, so it probably isn't using the sd card slot and it's driver during normal operation.

The official pi troubleshooting forum even had someone passing by that had used the synoptic usb core in another design.

He wished them good luck with it to get it going as it should.

Fact is, if I can choose between 2 product, and one is powered by broadcom, I will choose the other one. Not just because that BCM2835 is having issues, but mainly because of the way the foundation (mostly broadcom employees) tries to hide and minimise them.

I didn't say that the Roku didn't have problems but I haven't run across any threads that say that there is. Trust me, I'm not a fan of Broadcom solely based on the fact that they don't sell to you unless you're a multi-million dollar account and also for the fact that you brought up about "hiding" issues. This also goes for NVidia to a certain extent with their Tegra line.

I've been trying to get a straight answer on the USB issues and as no surprise it doesn't appear that anyone is offerring any help. I would think that the amount of trouble with the USB port that this would be a major focus yet it certainly doesn't appear to be. I don't even know if anyone has ruled out hardware problems or if it's a firmware problem. I would think that if it's a firmware issue that someone with experience would use the JTAG port and try to capture the events. The problems are fairly repeatable so I would think it wouldn't take a long time to narrow down a fix.

The board has done well and it set new grounds with what you can do for $35 but I might take a different view of the Foundation if they released the version 2 board and didn't address the USB problem.

There's no reason to believe that any other product based on the BCM2835 wouldn't have exactly  the same USB problems as Pi, since those problems are determined by the USB core used in the SoC.  That's why I asked whether Broadcom continues to use the same USB core in their more recent SoCs.  If they do then a new generation of Raspberry Pi boards based on a newer SoC could be at risk of having the same issues.

After all, we know that the Foundation won't use anything except Broadcom for the Pi SoC because they are strongly tied to that company by numerous factors.  I bet RS at least wishes it were otherwise, from what we've heard about device shortage leading to RS's terribly long wait queue.

Do you mind if I ask how know that this is a problem with the USB core? When you say that it makes me think that the hardware design and firmware are OK but the SoC itself is flawed.

Morgaine Dinova wrote:

 

After all, we know that the Foundation won't use anything except Broadcom for the Pi SoC because they are strongly tied to that company by numerous factors.  I bet RS at least wishes it were otherwise, from what we've heard about device shortage leading to RS's terribly long wait queue.

I've heard that the BCM2835 is made to order with a 23 week lead time.  (Yes, that's what I heard.)  So you have to predict future needs very carefully or you'll end up with a shortage (can't make boards) or a surplus (which you can't sell to anyone else because you can't provide data sheets).

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

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

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?