BeagleBone Black vs. Raspberry Pi

This project intends to bring Asterisk and FreePBX to the recently announced BeagleBone Black. It is a spin-off from Asterisk for Raspberry Pi, where more than 1 year of experience has been collected in running low-cost, low-power Asterisk based PBXs on the Raspberry Pi (RPi) hardware platform. The BeagleBone Black (BBB) has obviously been created as a direct competition to the RPi, featuring better hardware performance with a price tag of only $10 more. Having the application of a VoIP PBX in mind, several improvements of the BBB compared to the RPi look promising:

1. The Cortex A8 processor (ARM v7) with a clock speed of 1GHz compared to the 700MHz clocked ARM v6 processor of the RPi provides more than twice the performance.

2. Badly regulated power supplys have been a frequent cause of crashes or data corruption on the RPi’s SD cards. Having a well regulated power supply with enough available current is key to reliability on the RPi. The BBB includes better power management on the board itself, thus improving the situation a lot.

3. The BBB has 2 GB of storage memory on it’s on-board eMMC, while still being equipped with a micro-SD slot for memory expansion. The RPi instead has to boot from the external SD card, making it vulnerable to issues with low-cost cards.

Whenever users experienced data corruption with their RPis, in almost all cases it originated from either the power supply or the SD card itself. On the BBB this situation should improve considerably, making it an excellent choice as low-power PBX platform where reliability is key when running it 24/7.

Additional postings will follow soon on this website, once more experience has been gained with the BBB. Stay tuned!

21 thoughts on “BeagleBone Black vs. Raspberry Pi

  1. Crispin


    I am running your RPi version and my only gripe is the GUI is slightly sluggish. Other than that, it works fine for what I need.
    Have you done any comparisons between the BBB and RPi? in terms of performance?
    While both versions are supported, is there a point in converting (other than for “just ’cause”)?

    My overclocked (850MHz) RPi uses about 10% CPU per call and I only ever have 5 or so at a time so I am well within the limits. The only thing I would look for improvement in is the GUI speed which I suspect is just down to grunt of the CPU.

    Thanks for your work on both!


    1. Gernot Post author

      The BBB is definitely a lot faster than the RPi. The web GUI is running at least twice as fast, maybe even more. It is quite convenient to work with FreePBX on the BBB, where on the RPi some patience is required.
      Concerning Asterisk, I haven’t had a chance to bring it to the limits yet, but CPU usage per call is about the same as on the RPi. So I assume the number of concurrent calls will be similar.
      If your RPi is doing well now I wouldn’t change it. You know: never touch a running system. 🙂 But if you are planning to build a second one I would try out the BBB.

      1. Crispin


        I might wait then a bit or until I find another use for the RPi and swap it with a BBB.

  2. Darren Williams

    Hi, I’ve just come across this site and am I glad I did! I will download and try the image you are supplying.

    I’d already been eyeballing the BBB and had preordered one. I definitely liked the idea of a VOIP PBX on it and wanted to check out the performance. I also found the onboard eMMC interesting. I own, from a business point of view you may think that the BBB doesn’t have a place there but I’m hoping its just the opposite.

    When I first got my BBB I manually installed asterisk and FreePBX on debian and it works fine. I did some testing with sipp, I configured one sip trunk and 10 extensions on the BBB. I got the BBB to answer the 10 extensions from sipp on another box. The sipp was configured to plays some sample g711 audio and the BBB was configured to answer the extensions and send them all to voicemail, whereupon they would then record the g711 audio stream. I figured it would be a fair way to simulate load.

    Taking the load up to 10 concurrent calls and then placing a call through the sip trunk caused slight breakup of the call. I eventually settled on five concurrent calls plus the one manual VOIP call over the sip trunk and this was flawless.

    Nothing was tweaked it was just regular debian. I’m sure that without the voicemail etc going on it would easily support ten concurrent calls without transcoding.

    We have many clients with only 3-4 extensions and I figure that this little device would suit many of them, at the price point it is at it means you could easily have a spare sat in a drawer, high(ish) availability on the cheap 🙂

    I’m hoping to get the OS installed on the eMMC and seeing how it fares recording to a class 10 SD card.

    Right, lets get this image downloaded and give it a whirl, thanks again!

    1. Gernot Post author

      Thanks for sharing your test results! Without call recording, the RPi already manages 10 concurrent calls. The BBB should actually be capable of doing more. Would be great if you can share more of your test results. 🙂

        1. Gernot Post author

          I think testing conferences would be great: 10 users on a conf call (without recording) should be no problem as said before, but how much more can the BBB really do? The BBB is still young, there is not so much experience yet…

  3. Darren Williams

    Unfortunately, I’m having a problem. I don’t seem to be able to SSH in and my HDMI has never worked, I’ve tried it on multiple monitors.

    I can access the web interface fine, I even installed the java SSH client too but that got ‘connection refused’ also.

    I’ve even gone in blind with just a keyboard and done a iptables -F to see if it was that, but no joy.

    Are the build scripts available anywhere as I wouldn’t mind trying it with nginx if it uses apache?


    1. Gernot Post author

      SSH not working? That’s strange…
      You should first try to get HDMI working. It works very well for me here. The console messages on boot are printed to the serial device, this is identical to the original Angström image. Edit the file uEnv.txt on the FAT partition and comment out the line


      Insert instead:


      Console messages will be printed on the HDMI monitor on next boot. Maybe you can see some error messages.
      Actually there are no build scripts, it’s all mostly manual work to put the pieces together.

    1. Gernot Post author

      Haven’t tried it myself but eventually yes. If it’s not working out of the box then chances are good it might work by just replacing kernel and bootloader files in the image.

      1. Darren Williams

        I never did get this running on my BBB simply because I think I have a defective HDMI out.

        What I’ve done since then is to get both a cubieboard and just today a cubieboard2.

        The cubieboard2 is the dual core chip, has 1GB RAM and also 4GB NAND flash.

        I’m hoping that if I take the root filesystem and copy it over to the cubieboard2 then things may just work, fingers crossed, I’ll let you know how it goes.

  4. Darren Williams

    Excellent!! 🙂 This image does seem to be working on the Cubieboard2. I’ve really only butchered an image for now, I’m not really that savvy on how the bits roll together so I simply wrote the BBB image to SD card which I them mounted, I then deleted the modules directory and the /boot and just tarred the whole thing up then extracted it over the top of an existing Cubieboard root filesystem.

    The inability to SSH was still there and after doing a little debugging, now that I have a screen to look at, I found that in the /etc/ssh folder, all they ssh_host_* entries were 0 bytes. I have yet to check whether thats the case on my original BBB image and if it is I will be able to fix it without HDMI as it simply needed: rm ssh_host_* followed by a dpkg-reconfigure openssh-server.

    I’ll try an get something running tomorrow in a much cleaner way.

    So Arkesh Kumar, in answer to your question, the answer is yes, this will run on a Cubieboard2 and it looks like without very much modification at all.

    Its only ticking over with no extensions or anything yet but load is very light:

    %Cpu(s): 9.0 us, 2.8 sy, 0.0 ni, 87.1 id, 0.0 wa, 0.0 hi, 1.0 si, 0.0 st
    KiB Mem: 929316 total, 380768 used, 548548 free, 49624 buffers
    KiB Swap: 0 total, 0 used, 0 free, 197056 cached

    The apache process is what keeps taking the CPU up to that 9.0 but then it drops back down to between 0.2 and 1.2.

    1. Gernot Post author

      Wow these are great news. Congratulations!
      A straight forward procedure could look like this: Take the BBB image and delete everything on the boot (FAT32) partition and the contents of /lib/modules/ and /lib/firmware of the root partition. Then take the files in these locations from a working Cubieboard Ubuntu image.

      Concerning ssh: The ssh host keys are automatically regenerated the first time you boot the image. Maybe you have cut power during the first boot and this is why the files have 0 lenght. It’s just a theory, but if it’s true you could have fixed this by just flashing the card again with a fresh image.

  5. Michel


    Just to say that the BeagleBone Black seem to have a very interesting feature: a battery rechargeable onboard chip !!
    For a very small price, adding a small battery, a connector and a resistor or a thermistor, an embedded UPS (Uninterruptable Power Supply) fits in the Beagleboard–rechargeable-on-board-battery-system
    It doesn’t seem to be very difficult to implement a battery back-up on the board.

    I think I’ll order one board to test it.


  6. Riccardo


    First of all my congratulations to the community for this great project (both hardware and software)
    I’m buying my first BBB card in order to deploy a pbx for my offce. We have 5 extensions and 2 trunks (one of these interfaced to a patton smartnode bri).

    I kindly want to know if, in your opinion, this solution should suitable for 24/7 business and which is the maximum number of simultaneous connection it can support.

    Now we are using an old P4 x86 pc, that we want to replace with a low power and smarter solution.

    Thanks in advance


    1. Gernot Post author

      Yes of course it is possible to use the BBB as a 24/7 PBX for your setup. The maximum number of simultaneous calls is currently around 10.

      1. Riccardo

        Thanks for the advice.
        I bought the card and first tests are going very well.

        I see from the documentation that is possible to write internal mmc with raspbx image. My question is what is the best solution to get the maximum performance from the system: SD or internal mmc?

        I already tried both without any appreciable difference using asterisk. What is your opinion?

  7. Mateus Furquim


    I was wondering why I was running out of space on the BBB. After a while I noticed I only had 1.7Gb to use, and that is what is saying on this post, that the BBB has 2GB of internal storage.

    After suffering with this low storage capacity I read the tutorial again and there is a step which you get to use all the storage of the uSD card, and I decided to try it on the eMMC do BBB.

    I was surprised when I saw that the size of the partition increased to 3.5Gb (4GB). I went to see the specifications of the BBB and it says 4GB of internal memory.

    Here it is the link to the specifications of the BBB:
    and here it is the link to the tutorial:
    under the “How to Flash Image the downloaded image” there is a section “Expand root partition”. You can then follow it to make use of the entire internal memory.

    So I guess this post should be edited?
    Hope I have helped anyone.



    1. Gernot Post author

      Thanks for the update! Latest BBB revisions indeed have 4GB eMMC storage, compared to the 2GB of older boards. I’ve updated the manual accordingly.

Comments are closed.