Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
Forum Thread Details
  • Replies 35 replies
  • Subscribers 708 subscribers
  • Views 4670 views
  • Users 0 members are here
Related

troubleshooting topics zooms past 1000 (now 6000)

e14 Contributor

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=10869

 

In my experience, when you have around 10 known issues, you can

discuss the status of each of them in a 1 hour weekly meeting.  You can

easily notice when two are duplicates of each other, and combine them.

You can keep track of which ones have been reproduced, and which

need further information in order to reproduce.  You can keep track of

who is assigned to work each issue, and in what order they should work

them.  You can remember from week to week what the issues are about,

without having to spend all your time coming up to speed again on each

issue.  You can ask whether each issue presents an opportunity to

improve the documentation, or to improve the QA process.  You can

ask to review in detail the proposed fix for each problem, until you are

satisfied that the fix actually solves the problem without creating other problems.

You can ask whether each problem was caused by a fault in the tools used,

or the process used, and if so, whether to make improvements in those.

You can notice when multiple problems relate to the same component,

and perhaps decide to redesign that component rather than continually

patch it.  You can thoughtfully decide whether to deliver a fix as an urgent

update, or wait to deliver it in the next general release.  You can develop

regression tests to prevent the same or similar problems from ever being

shipped again.  And when a problem is fixed and the fix delivered, you

can move it off your agenda.

 

When you have about 100 known issues, it becomes much more

difficult to do the same tasks.  You can try to prioritize and focus on

just the top 10, but then the others suffer.  When you have about 1000

known issues, it becomes impossible to manage, and you will completely

lose track of which issues are duplicates of others, which are fixed, and

which are urgent.  If you release a product update, you will have no idea

what to say in the release notes.

  • in reply to e14 Contributor

    Jim,

      I think you're the one suggesting a conspiracy.  Broadcom has very openly

    designed and built the RPi alpha board, even putting their own logo on it, several

    of the most active RPi.org mods are openly employees of Broadcom, Broadcom

    supplies the main chip on the RPi board, Broadcom employs the RPi CEO,

    Broadcom is actively trying to fix bugs in the linux drivers, and the Broadcom

    Foundation is very openly sponsoring RPi marketing events.   Broadcom

    reportedly sent an inspector to the China factory to assess the working conditions.

    When a journalist called for a response from RPF, it was a Broadcom employee

    that responded, although it isn't always clear which hat he wears at any given time.

     

    Sometimes Broadcom's role has been minimized for unknown reasons, such as

    when their logo was taped over on the alpha board photo, or when Liz refers to them

    as just a friendly chip supplier, or when Rob Bishop's employer isn't named,

    but I don't think Jamodio is suggesting a conspiracy.

  • in reply to e14 Contributor

    That is correct, I'm not suggesting any conspiracy, just stating facts being one of them the lack of transparency.

     

    The organization at the center of the mesh is the RPF which I don't blame but clearly I believe in some aspects have done a poor job.

     

    -J

  • in reply to e14 Contributor

    SoCs are designed to suit the market for which they are intended.  Broadcom designed the BCM2835 for media devices such as the Roku 2 which are not generic host computers, and prior to Pi no other commercial customer other than Roku existed for this particular SoC as far as we know.

     

    Given the intended purpose of the chip, it's no surprise that Broadcom built in a cheap cut-down USB core that has very limited ability to act as a generic USB host controller, and it shows in the faults that appear as soon as you try to use Pi's USB as if it were a generic host controller, because it's not.  It's a very limited one.

     

    There's no conspiracy, but only an inappropriate choice of SoC for the Raspberry Pi.  It's inappropriate because the Pi is definitely intended as a general purpose computer with a fully working host USB system, which the actual system as designed does not have as a result of the designer's choice of SoC.

  • in reply to morgaine

    I don't disagree with the thoughts about the SoC, but I really can't use any other word than conspiracy for the way you refer to broadcom image

     

    Yeah, I would agree that it looks like the Pi Foundation used broadcom to manufacture the alpha board, but they did so at their own expense.  Some of the mods (2 if you don't count eben who never posts, maybe 3 if they've made dom a mod) are broadcom employees but the majority of them are independent individuals from the community and the broadcom people contribute in their spare time.  I'm unware of broadcom funding any of the makerting campaing, links?

     

    Sorry but no, you're trying to suggest something more to than the facts would predicate.

     

    Ah well, a difference of thought allignments?  No offense meant, but the more I read on this board the more I see a subtle (and sometimes not so stuble) tone of "The RPF is sinister." A willingness to take an extra step or two beyond what logic shows to be true to stick it to the Pi foundation.  Unforatunately, I'm just not in that boat image.  To each his own though right?  You can enjoy this forum and I can find another, no sense in me pissing on your fun.

     

    Thanks for the chats!

  • in reply to e14 Contributor

    Jim,  

    You said you were familiar with the RPF history, but you have your facts all wrong.

     

    > Yeah, I would agree that it looks like the Pi Foundation used broadcom to manufacture the alpha board, but they did so at their own expense.

    No, they have clearly stated that Broadcom designed and manufactured all 50 alpha boards at its own expense.

    EDIT adding: see page 2 of:

    http://www.element14.com/community/docs/DOC-46998/l/raspberry-pi-the-journey-so-far-and-a-peek-into-the-future

    "Broadcom has been an early supporter of the Raspberry Pi programme.  Although not "officially" a sponsor, ...

    but also supporting the design -- by paying for the PCB design & production of the first 50 (alpha) production boards."

     

    > I'm unware of broadcom funding any of the makerting campaing, links?

    http://blog.broadcom.com/broadcom-innovation/attention-raspberry-pi-oneers-broadcom-helps-spread-the-raspberry-jam/

    http://blog.broadcom.com/broadcom-foundation/broadcom-masters-finalists-get-a-taste-of-raspberry-pi/

     

    >Some of the mods (2 if you don't count eben who never posts, maybe 3 if they've made dom a mod) are broadcom employees

     

    care to name them?

  • in reply to e14 Contributor

    mynameisJim wrote:

     

    I don't disagree with the thoughts about the SoC, but I really can't use any other word than conspiracy for the way you refer to broadcom image

     

     

    I think you need to stick to what is actually written on the page rather than swiping at imagined ghosts and mirages.  We're mostly engineers and technical enthusiasts on this forum, and we tend to say exactly what we mean as clearly and precisely as we can, because that's how technical people are built.  If it's not written on the page then it probably wasn't intended in the first place, but imagined.

     

     

    Thanks for the chats!

     

    You're welcome.  And indeed, everyone is welcome here are long as they engage in polite discussion with other members.  It can take a while though to catch up with the deluge of information which we've been examining in much depth here over the past year.  It's a complex situation, and understanding it takes some effort.

  • in reply to e14 Contributor

    There are now more than 3000 threads in the troubleshooting forum,

    about 550 of which are active in the last month by my count.

     

    Gordon says on this thread:

    http://www.raspberrypi.org/phpBB3/viewtopic.php?f=24&t=26931

    "I am hoping to start working full time soon on the USB issues so should be able to get much further... Watch this space"

     

    Liz says on this thread:

    http://www.raspberrypi.org/phpBB3/viewtopic.php?f=22&t=26412

    "there's Pixman and Wayland optimisation work ongoing, for example, as well as Scratch optimisation"

     

    JamesH says on this thread:

    http://www.raspberrypi.org/phpBB3/viewtopic.php?f=24&t=26644

    "One thing that we do need to do is ensure that what are regarded as minor problems are not continually given exposure. One of these is the USB issue."

     

    JamesH says on this thread:

    http://www.raspberrypi.org/phpBB3/viewtopic.php?t=25501&p=245246

    "Even if 50% go in to drawers and fester, that's still 500k devices out there being used."

  • in reply to e14 Contributor

    I see the same questions asked many times chez RasPi.  They don't have a good mechanism for merging a new thread into an old one so that entia non sunt multiplicanda praeter necessitatem (Occam's Razor).  The Wiki is often very good.  I would suggest they hold a new thread for moderation and provide a link to the Wiki.

     

    Corrolary to JamesH's 50% comment: if 50% go into drawers and fester (sounds uncomfortable as well as smelly, but chacun a son goût), then doesn't that mean that the effective price of a RasPi doubles to US$70 and we might as well purchase a Hardkernel/Samsung ODROID-U with 1.4GHz ARM Cortex-A9 quad core or a Wandboard if you want open i.MX6 documentation (except for GPU)?

  • in reply to johnbeetem

    Yes, they clearly need some way of merging similar threads, in order to have

    someplace to track progress on each issue.  But they don't seem particularly

    interested in tracking progress on technical issues.

     

    JamesH's 50% comment was in response to user richardp who wrote:

    "In total I got 3 of them. I was going to conquer the world! In the end, all my interests were exhausted by broken firmware (ala USB Port) or incomplete examples to achieve anything useful (ala OMX).

    ... I have 1 XBMC player and 2 doing nothing."

     

    So in his case, the 2 doing nothing were due to the combination of

    technical problems (USB) and issues with available training materials.

  • in reply to johnbeetem

    John Beetem wrote:

     

    [...] we might as well purchase a Hardkernel/Samsung ODROID-U with 1.4GHz ARM Cortex-A9 quad core or a Wandboard if you want open i.MX6 documentation (except for GPU)?

     

    Some of us have already started down that route. I got a Sabre-Lite i.MX6 dev board recently and I have to say it's very nice. If you limit it to a 100Mb/s network connection, idle power consumption is on par with the Pi - rather good for a 1GHz quad core with 1GB ram.  Using a 1G network port almost doubles the power consumption, quite scary but not entirely unexpected.

     

    The really interesting things about the iMX6 for me are the SATA port and the PCIe port as it has the potential to open up a whole new set of posibilities that you just don't have with other Arm devices.

     

    So I'm looking forward to some interesting iMX6 based boards appearing in the next year. 

     

    I'd certainly love to see someone do what the RPF did and produce a cost and form-factor optimised board based on an iMX6 solo and 512MB ram. Comparing the Sabre-Lite and RPi side by side it certainly looks like it should be possible if you're prepared to make the same sort of ruthless compromises. No idea what it would cost, or if it would be worth it, but it would certainly be interesting as the SoC itself appears to be far more functional and better documented.