Pi vs BeagleBone-Black

@Billy/Mor - It would be an interesting case study to see a company open up on what had previously been tightly locked up and get hard evidence on if opening it up improved the technology.  We have some rational evidence that would seem to indicate it would be beneficial but no one has step up and done it so there is a complete lack of empirical evidence.  I imagine the reluctance thus far is very similar to the cold war nuke situation.  The hippies called for a end to nukes and have some very good reasons for calling for that, in fact from a rational stand point, the world is better off without nuclear weapons.  That said, the fact we had nukes prevented the Soviets from attacking us with their nukes.  Likewise, while we the end user may benefit in the short term by nVidia opening up their GPU, if that means Broadcom can come in, swoop up their technology, and then put nVidia out of business we suffer in the long run as not only do we no longer have that source of openness, but now we have one less competitor so they're going to be even more hush hush about it and charge us more for it.

I can understand, even if I disagree with, their reluctance.

On the weighted average we were discussing, I agree that it would be hard, but I do think it would be possible to take a dispassionate view and give fair rankings.  I mean the (hacker/hobbyist) community already spends that energy attacking, why not use that energy for something positive.  I think Billy has been dancing around this statement for a bit on the thread, but companies are going to do what's best for their pocket books.  Constantly saying "everyone sucks because no one is truly open" doesn't really provide incentive.  A fair report on openness and encouraging people to positively petition for more openness while using their money to support those who are making progress in the right direction will provide additional incentive.

mynameisJim wrote:

 

It would be an interesting case study to see a company open up on what had previously been tightly locked up and get hard evidence on if opening it up improved the technology.

That would indeed be interesting.  I seem to recall reading some case studies on the business effects of open sourcing software by one of the many free and open source advisary bodies, but I don't recall having read anything like that regarding opening hardware.  If any reader encounters such material, please link us.

On the weighted average we were discussing, I agree that it would be hard, but I do think it would be possible to take a dispassionate view and give fair rankings.

There's an inherent and inescapable problem with that though.  A ranking is either going to favour one interest over another and therefore by definition not be fair to those whose main interest it ranks lower, or else it is going to rank all interests equally and hence not be a ranking at all.  Because of the variety in the target audience, there is no actual way to accomplish what you're suggesting.  The diversity precludes meaningful averaging and fair ranking, because averaging of disparate interests cannot be done and ranking itself cannot be fair.

A fair report on openness and encouraging people to positively petition for more openness while using their money to support those who are making progress in the right direction will provide additional incentive.

An accurate description of which parts are not currently open is completely fair.  It may not be appreciated by some people who might find it inconvenient, but it has the fairness and impartiality of hard fact.  It's hard to beat.

Note however that the above doesn't preclude others from dancing tactfully around the subject and using tricks of diplomacy to help management lean more towards openness.  If you think that's going to work, by all means try it!  It's not going to change the facts about which elements are currently closed though.

selsinork wrote:

 

So how do you get to be an expert ?   You're absolutely right that someone starting out is unlikely to fix usb on the Pi, but everyone has to start somewhere.  Just maybe, learning how to tackle the problem from the expert that does fix it, is a step towards someone becoming an expert themselves ?

Unfortunately there is and there will be no real fix for the usb issues with the Rpi. The Synopsys IP is very limited and there is not much more you can do as a workaround to make OTG to behave as a full fledged HOST implementation.

The only possible fix besides the current workaround and trying to live with its limitations is to throw away the SoC and start fresh with a better USB implementation that fully supports a Host interface, but it is very unlikely that this will ever happen.

-J

jamodio wrote:

 

Unfortunately there is and there will be no real fix for the usb issues with the Rpi. The Synopsys IP is very limited and there is not much more you can do as a workaround to make OTG to behave as a full fledged HOST implementation.

 

The only possible fix besides the current workaround and trying to live with its limitations is to throw away the SoC and start fresh with a better USB implementation that fully supports a Host interface, but it is very unlikely that this will ever happen.

While servicing USB interrupts on the VideoCore to make up for the inability of the ARM to meet the 1ms realtime response requirement when it's busy doing something else is the much-touted future solution, whether it will be done or not probably depends on whether RPF and Broadcom consider it a wise investment of time and effort (ie. money) by their skilled engineers.

That in turn probably depends on whether other Broadcom SoCs also employ the same dreadful Synopsys USB controller which is the cause of all this pain in the first place.  If they do use it then that substantial development effort may be worthwhile to prevent all the affected Broadcom devices suffering the same problems as the BCM2835.  In contrast, if more modern Broadcom devices use a different and fully functional USB controller then such development might well be seen as wasted effort and not see the light of day.

These two different situations could result in two different outcomes for Raspberry Pi.  Does anyone know whether the BCM11311 that has been mentioned in connection with the next-generation Pi employs the same Synopsys USB core?

My reading on the latest stuff on the raspberry pi website seems to show that most of the problems are fixed, at least good enough for most people. I presuming there are some devices that will never work, but i reckon they are rarely used ones. So its good enough now for most stuff. I

Changing a USB block on a chip would cost a lot of bucks.

Billy Thornton wrote:

 

My reading on the latest stuff on the raspberry pi website seems to show that most of the problems are fixed, at least good enough for most people. I presuming there are some devices that will never work, but i reckon they are rarely used ones. So its good enough now for most stuff.

The work being reported in the "USB FIQ testing" thread on the RPF forum continues to this very day, so it would seem that the engineers doing the development do not share your assessment of the gravity of the fault.

jamodio wrote:

 

Unfortunately there is and there will be no real fix for the usb issues with the Rpi.

All sounds like an even better learning experience, a real world problem that can't be fixed. Lots of those exist, so learning how to deal with them and how to chose a compromise would be a useful skill ?

Morgaine Dinova wrote:

 

That in turn probably depends on whether other Broadcom SoCs also employ the same dreadful Synopsys USB controller which is the cause of all this pain in the first place.  If they do use it then that substantial development effort may be worthwhile to prevent all the affected Broadcom devices suffering the same problems as the BCM2835.  In contrast, if more modern Broadcom devices use a different and fully functional USB controller then such development might well be seen as wasted effort and not see the light of day.

In one of the lengthy usb threads, JamesH implied that the same core was used in many of their devices, but also that it's almost never used in host mode. You can probably infer from there that a fix would be up to the RPF.

selsinork wrote:

 

All sounds like an even better learning experience, a real world problem that can't be fixed. Lots of those exist, so learning how to deal with them and how to chose a compromise would be a useful skill?

  "We are leaving this USB fault unfixed to provide further opportunities for engineering education."

selsinork wrote:

 

In one of the lengthy usb threads, JamesH implied that the same core was used in many of their devices, but also that it's almost never used in host mode.

Oh dear.  I don't know if we can take it as given that RPF will remain with Broadcom SoCs, but if we make that assumption for now, it means that the next generation of Raspberry Pi boards is likely to have the same USB limitations as the current generation, and consequently exhibit all the same USB faults unless they get it fixed in the VideoCore.  It will be highly unfortunate if RPF can't make the USB problem vanish just by choosing a later SoC in the range.

One additional point with bearing on the matter is that more advanced Broadcom SoCs may well have Ethernet natively on the SoC, which could make the USB fault slightly more tractable.

You can probably infer from there that a fix would be up to the RPF.

RPF + support from Broadcom engineers + expensive USB equipment.  It all adds up to time and money invested by a lot of people, but they probably have no choice if leaving the Broadcom stable is not an option.  I doubt that anyone over there wants these USB problems to continue for years into the indefinite future.