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

Pi vs BeagleBone-Black

Former Member

So, just over a year on from the initial availability of the R-Pi and the new BeagleBone Black is upon us.  They've obviously taken a leaf out of the RPF's playbook and produced a cost reduced version at a price only marginally above the Pi.

 

I find it interesting that the compromises are very different, for example there's a proper PMIC and the ethernet is not troubled by being connected to USB, however the on-board HDMI seems less capable.

 

Other differences are in the documentation, I'm currently viewing the pcb gerbers for the beaglebone..  Have yet to see any sign of those for the R-Pi a year later. There's even an up to date devicetree capable kernel too.

 

Technology has also moved on somewhat, we get a 1GHz Cortex A8 which is better than the Pi, along with various other stuff and lots more GPIO's too.

 

Ok, so it's clear that I like the look of the new beaglebone, and given the price I'm likely to put any further R-Pi plans on hold until I have a chance to play with this. It's also making things like the Olinuxino-maxi I bought recently look very slow/expensive while still being cheaper than the similarly specced Olinuxino-A13

 

Some details of the beaglebone-black here http://circuitco.com/support/index.php?title=BeagleBoneBlack

 

What do the rest of you think ?   I don't expect this to displace the Pi anytime soon, but I expect it to be very attractive to those people who don't simply want to put XBMC on it and duct tape it to the back of the TV..

  • Morgaine Dinova wrote:

     

    mynameisJim wrote:

     

    Ah. the PRUSS was my main bugabee, can you link for the SoC?  Maybe I'm blind but I just couldn't find anything that was more than 10ish pages long. 

    The full 289-page AM335x PRU-ICSS Reference Guide is located in the same place on Github as all the other PRU-related materials --- https://github.com/beagleboard/am335x_pru_package.

     

    It's right there at the top level bearing the accurately descriptive file name of am335xPruReferenceGuide.pdf .

    thank you!

     

    > Billy Bob Wrote: I thought the raspberry pi docs covered all the arm side stuff

     

    A quick google search of Raspberry Pi arm datasheet led me to this link (thanks for the point in the right direction)

     

    http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

     

    John could you expound on how this is less than what TI did?  It seems like the same level of information on both sides with the main hold out being both their GPU info. 

  • mynameisJim wrote:

     

    http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

     

    John could you expound on how this is less than what TI did?  It seems like the same level of information on both sides with the main hold out being both their GPU info. 

    I'll do a quick compare with the AM335X TRM rev C, which is the one I have handy.

     

    The first clue is the number of pages: BCM = 205, TI = 4593.

     

    USB: BCM has reference to a Synopsys document, which I think you have to register with Synopsys to download.  Even then I'm not sure it's available or useful.  TI has 1612 pages on USB.

     

    Interrupts: BCM has 10 pages, not sure if it covers what you need to write an OS.  TI has 200 pages.  Don't know if this is just because TI is more versatile, or whether it covers more ground.

     

    System initialization and booting: BCM has 0 pages, TI has 60.  This is something you need to know to write an OS or do bare-metal programming.  BCM actually boots using the GPU, so totally closed.

     

    Chip pinout: not in BCM documents, present in TI AM335X data sheet.  Ditto for detailed pin electrical information, such as absolute max voltages.

     

    As Billy has said upstream, most people don't need this information.  RasPi is indended for end users who will use it as a programming tool, so the information given is adequate.  Beagles are intended for serious development, with Bone intended for "makers" who need lots of I/O.  Some people have done bare-metal programming with RasPi, and it's possible by treating the GPU's "binary blob" as a closed boot ROM.  However, if I'm doing bare-metal programming, I really want to understand what I'm doing and I want the level of documentation provided by TI.

  • John Beetem wrote:

     

    mynameisJim wrote:

     

    http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

     

    John could you expound on how this is less than what TI did?  It seems like the same level of information on both sides with the main hold out being both their GPU info. 

    I'll do a quick compare with the AM335X TRM rev C, which is the one I have handy.

     

    The first clue is the number of pages: BCM = 205, TI = 4593.

     

    USB: BCM has reference to a Synopsys document, which I think you have to register with Synopsys to download.  Even then I'm not sure it's available or useful.  TI has 1612 pages on USB.

     

    Interrupts: BCM has 10 pages, not sure if it covers what you need to write an OS.  TI has 200 pages.  Don't know if this is just because TI is more versatile, or whether it covers more ground.

     

    System initialization and booting: BCM has 0 pages, TI has 60.  This is something you need to know to write an OS or do bare-metal programming.  BCM actually boots using the GPU, so totally closed.

     

    Chip pinout: not in BCM documents, present in TI AM335X data sheet.  Ditto for detailed pin electrical information, such as absolute max voltages.

     

    As Billy has said upstream, most people don't need this information.  RasPi is indended for end users who will use it as a programming tool, so the information given is adequate.  Beagles are intended for serious development, with Bone intended for "makers" who need lots of I/O.  Some people have done bare-metal programming with RasPi, and it's possible by treating the GPU's "binary blob" as a closed boot ROM.  However, if I'm doing bare-metal programming, I really want to understand what I'm doing and I want the level of documentation provided by TI.

    Great run down!  Thanks for the quick compare/contrast.

  • Getting stuff out of synopsys is like getting blood out of a stone. But since the number of people who can write decent USB code is pretty small its not a great loss!

     

    Out of interest, if the boot sequence results in a machine ready to run baremetal code, why do you need information about it? You can drive the arm as much as you like from that point onwards. All you need that information for is to write a bootloader, which you already have...my readin of the baremetal forum (not my interest so I didnt do a lot of readin) is that its all going pretty well. If you want to do it you can, the docs are not particularly limiting.

     

    And why do you need chip pinouts? Youve got the header pinouts which is where it all happens. Noone can buy the chip, so no need of the pinouts.

  • Billy Thornton wrote:

     

    Getting stuff out of synopsys is like getting blood out of a stone. But since the number of people who can write decent USB code is pretty small its not a great loss!

    Thank you for confirming my suspicion about Synopsys.  Regarding whether or not it's a loss, I would suggest that we can't expect good USB code without good USB hardware documentation.

     

    Out of interest, if the boot sequence results in a machine ready to run baremetal code, why do you need information about it? You can drive the arm as much as you like from that point onwards. All you need that information for is to write a bootloader, which you already have...my readin of the baremetal forum (not my interest so I didnt do a lot of readin) is that its all going pretty well. If you want to do it you can, the docs are not particularly limiting.

    As with any closed source code, if there's anything wrong with it you can't fix it.  It was this frustration that led RMS to the Four Freedoms.  In the RasPi case, it's apparently working out OK for bare-metal programmers but I'm not following the bare-metal forum either so I don't know if they're exposing problems that require "binary blob" fixes.

     

    Personally, I prefer having the flexibility of knowing what my boot code is doing.  Maybe this comes from memorizing the PDP-8 RIM loader at an impressionable age, and knowing what it did in assembly and machine language.  Having this kind of access lets me do unusual things, like the time I booted an IBM PPC403GA embedded PowerPC through a FIFO.  That was a challenge, because a FIFO can only execute sequential code -- you can't branch.  Having full control of the machine language was necessary in that case.  Besides, it gives me Isaac Asimov's "Feeling of Power", which makes computing in general more enjoyable IMO.

     

    And why do you need chip pinouts? You've got the header pinouts which is where it all happens. No one can buy the chip, so no need of the pinouts.

    I simply included this as part of the differences between BCM and TI documentation.

  • John Beetem wrote:

     

     

    Personally, I prefer having the flexibility of knowing what my boot code is doing.  Maybe this comes from memorizing the PDP-8 RIM loader at an impressionable age, and knowing what it did in assembly and machine language.  Having this kind of access lets me do unusual things, like the time I booted an IBM PPC403GA embedded PowerPC through a FIFO.  That was a challenge, because a FIFO can only execute sequential code -- you can't branch.  Having full control of the machine language was necessary in that case.  Besides, it gives me Isaac Asimov's "Feeling of Power", which makes computing in general more enjoyable IMO.

     

     

    I wonder if it would be possible to get a flowchart on the boot process that went something beyond power->bootcode.bin->config.txt->kernel.img->OS (or whatever order they go in).  Obviously it couldn't be anything that gave away too much or else we'd never get antyhing, and they'd probably have to be careful not to reveal information that could potentially create a boot time security threat, and it's not like it would actually enable us to do anything extra, but it would be pretty cool and informative just to see. 

     

    It's constantly facinating to me that if the Foundation had chosen to add an eprom and put this information in there where it could never be touched and then rolled the cost of the two gpu codecs into the price of the pi, it would be considered more open source than them giving us power over boot configurable run time tweaks and the option of paying codec fees if we want them.

  • Thank you for your post. I am keen to learn more about Beaglebone Black in relationship to the field of robotics as I am totally new to its application. Will appreciate all the help in getting started.

  • mynameisJim wrote:

     

    It's constantly facinating to me that if the Foundation had chosen to add an eprom and put this information in there where it could never be touched

    That's the thing though isn't it. It would need to be a mask programmed rom and inside the SoC.  People have become far to conditioned into the way of thinking that says you can 'flash' the firmware or that rooting your phone or overclocking your device is the done thing for any sort of external chip to survive for long without thorough examination.  If nothing else, the Pi has proven that there's a lot of people out there who are interested in doing things with it that the RPF never considered.

    Besides, if they had made the GPU code unchangeable, it seems unlikely that the camera board would have been possible.

  • Billy Thornton wrote:

     

    Getting stuff out of synopsys is like getting blood out of a stone. But since the number of people who can write decent USB code is pretty small its not a great loss!

    Self defeating argument. If the number of people who can write USB code is limited by the number who can get access to the docs necessary to do it.

     

    The goal of the Pi is supposedly education, but the assumption that something like this is no great loss is rather flawed. Somehow, somewhere, we need to educate the next generation of programmers in how to write decent USB code or else the number will rapidly dwindle away.  Who gets to make the value judgement that USB isn't worthy ?

     

    I think all these things that get dismissed as not important are missed opportunities and we'll simply trade one perceived deficiency for a different one over time.

  • John Beetem wrote:

     

    As with any closed source code, if there's anything wrong with it you can't fix it.  It was this frustration that led RMS to the Four Freedoms.  In the RasPi case, it's apparently working out OK for bare-metal programmers but I'm not following the bare-metal forum either so I don't know if they're exposing problems that require "binary blob" fixes.

    Various problems have arisen over time that can only be fixed in the GPU blob. JamesH in particular seems to often dismiss these things with something along the lines of "the gpu binary is closed so nobody can help apart from rpf/broadcom and we're all too busy to look" and seems to combine that with an attitude of the broadcom engineers being the smartest people on the planet and it being impossible for anyone else to be smart enough to help anyway, which I find rather condescending if not outright arrogant.

     

    Interestingly, in a thread about the camera, 'gsh' at least hints at having discussions with Broadcom to allow the CSI peripheral details to be added to the arm datasheet. Seemingly to allow others to remove the roadblock of the gpu being the only thing that can talk to the camera/csi and the lack of resource from Broadcom/RPF to do things to the gpu blob.

    http://www.raspberrypi.org/phpBB3/viewtopic.php?f=43&t=24660&p=346189&hilit=CSI+peripheral&sid=7c21f71bcdec17f98913be74a083680c#p346189

    Whether that will ever actually come to anything is anyone's guess, but as at least some sort of acknowledgment that the binary blob can't/won't do everything and that there needs to be other ways it seems significant.