Comparing BeagleBone Black & Raspberry Pi

Drew Fustini wrote:

 

BBB $45 vs RPi Model B $35: BBB includes 2GB built-in flash & can run off

computer USB port [<500mA] so that would make up the cost

difference if one has to buy SD card and power supply for Pi.

I didn't like the onboard eMMC idea at first, and I'm still somewhat undecided. The 'everything you need to get started is in the box' idea is a stroke of genius though and removes all the faffing about with inexperienced users and win32diskimager.

Also, when you start thinking about integrating a BBB into your own 'internet-of-things' device it's actually an incredibly good idea too as you get a tested and known compatible storage device to boot from - at zero additional cost.

For tinkering, trying different distros etc, I still think that the eMMC is a roadblock. The current 45mins to reflash it needs to improve by orders of magnitude.

I believe media center is the best use case for RPi model B over the BBB.

... is the only use case for the RPi over the BBB...

We know from elsewhere that the BBB is technically capable of 1920x1080p60 without sound, or 1920x1080p30 with sound but that in these early days of BBB some driver development may be needed to make those easily available. So the only RPi advantage is the capable video decode hardware.

Actually maybe I'm a bit hasty on the use of 'only' there.  I think the RPi may have a bright future as a very cheap megapixel IP security camera type of device too with the addition of the camera board.

BBB has the ARM v7 instruction set so there is a wider range of distros

Like it or not, the trend certainly seems to be that ARMv7+NEON is going the be the minimum that distros are targeting nowadays. You'll probably be able to get soft float debian for some time to come, but even Debian isn't going to support the slightly unusual combination used in the broadcom device on the Pi.  Hindsight is wonderful, but you can't help thinking that if they'd put at least a cortex A8 into that particular SoC it would have taken a lot longer for someone to catch up with the Pi.

BeagleBoard.org and the BeagleBone leaders are passionate about getting

everything in the mainline kernel. They work with Linux kernel

maintainers to get their patches accepted upstream. I've been told they

hope to have everything in the mainline by sometime this year.

I think it's unlikely it'll happen this year, there's quite a lot of stuff in the beagleboard tree on github that would need to be ready pretty much right now. We're likely only a week or two away from 3.10, so if it's not already in the Arm maintainers tree it's almost certainly missed 3.11. That leaves 3.12 at the tail end of the year, but getting there assumes that everything is ready for the arm maintainers to pull now and the bigger the patchset the longer it'll take to review and it all assumes no issues are found and no changes are requested upstream.

I was quite surprised that one of the interviews with Jason Kridner quoted him as saying they were skipping 3.9 & 3.10 regardless - it would seem to make sense to have spent that time slowly pushing stuff upstream rather than seemingly aiming for a huge code drop in a later merge window.

BBB was a big jump forward from BB White as they went from Linux 3.2 to Linux 3.8

*and* the shift to Device Tree for configuration of peripherals.

The upstream kernel is very much a moving target though, 3.8 is already marked EOL. The only way to keep up is to get over that last hurdle of actually getting the code into mainline.

On the devicetree side, take a look at the thread linked to from this post http://www.element14.com/community/thread/25063?tstart=0 there's certainly some argument there that devicetree may not really be the answer and it certainly gives the impression that BBB could end up being one of the only systems that embraces devicetree fully.

There's been a lot of churn in the Arm parts of the kernel over the last year due to devicetree, BBB could end up being the one that proves it's workable, or could be left out in the cold if another solution eventually wins. I think it could be too early to tell how this will play out.

Drew Fustini wrote:

 

BBB $45 vs RPi Model B $35: BBB includes 2GB built-in flash & can run off

computer USB port [<500mA] so that would make up the cost

difference if one has to buy SD card and power supply for Pi.

I didn't like the onboard eMMC idea at first, and I'm still somewhat undecided. The 'everything you need to get started is in the box' idea is a stroke of genius though and removes all the faffing about with inexperienced users and win32diskimager.

Also, when you start thinking about integrating a BBB into your own 'internet-of-things' device it's actually an incredibly good idea too as you get a tested and known compatible storage device to boot from - at zero additional cost.

For tinkering, trying different distros etc, I still think that the eMMC is a roadblock. The current 45mins to reflash it needs to improve by orders of magnitude.

I believe media center is the best use case for RPi model B over the BBB.

... is the only use case for the RPi over the BBB...

We know from elsewhere that the BBB is technically capable of 1920x1080p60 without sound, or 1920x1080p30 with sound but that in these early days of BBB some driver development may be needed to make those easily available. So the only RPi advantage is the capable video decode hardware.

Actually maybe I'm a bit hasty on the use of 'only' there.  I think the RPi may have a bright future as a very cheap megapixel IP security camera type of device too with the addition of the camera board.

BBB has the ARM v7 instruction set so there is a wider range of distros

Like it or not, the trend certainly seems to be that ARMv7+NEON is going the be the minimum that distros are targeting nowadays. You'll probably be able to get soft float debian for some time to come, but even Debian isn't going to support the slightly unusual combination used in the broadcom device on the Pi.  Hindsight is wonderful, but you can't help thinking that if they'd put at least a cortex A8 into that particular SoC it would have taken a lot longer for someone to catch up with the Pi.

BeagleBoard.org and the BeagleBone leaders are passionate about getting

everything in the mainline kernel. They work with Linux kernel

maintainers to get their patches accepted upstream. I've been told they

hope to have everything in the mainline by sometime this year.

I think it's unlikely it'll happen this year, there's quite a lot of stuff in the beagleboard tree on github that would need to be ready pretty much right now. We're likely only a week or two away from 3.10, so if it's not already in the Arm maintainers tree it's almost certainly missed 3.11. That leaves 3.12 at the tail end of the year, but getting there assumes that everything is ready for the arm maintainers to pull now and the bigger the patchset the longer it'll take to review and it all assumes no issues are found and no changes are requested upstream.

I was quite surprised that one of the interviews with Jason Kridner quoted him as saying they were skipping 3.9 & 3.10 regardless - it would seem to make sense to have spent that time slowly pushing stuff upstream rather than seemingly aiming for a huge code drop in a later merge window.

BBB was a big jump forward from BB White as they went from Linux 3.2 to Linux 3.8

*and* the shift to Device Tree for configuration of peripherals.

The upstream kernel is very much a moving target though, 3.8 is already marked EOL. The only way to keep up is to get over that last hurdle of actually getting the code into mainline.

On the devicetree side, take a look at the thread linked to from this post http://www.element14.com/community/thread/25063?tstart=0 there's certainly some argument there that devicetree may not really be the answer and it certainly gives the impression that BBB could end up being one of the only systems that embraces devicetree fully.

There's been a lot of churn in the Arm parts of the kernel over the last year due to devicetree, BBB could end up being the one that proves it's workable, or could be left out in the cold if another solution eventually wins. I think it could be too early to tell how this will play out.