Pi vs BeagleBone-Black

John Beetem wrote:

Well, technically you're right since open source hardware (OSH) requires that all chips be fully documented.  However, my example of using BeagleBone as the controller for a chip's demo board doesn't need the GPU so for this application BeagleBone is indeed OSH.  You have open schematics, everything documented except GPU (I personally believe the PRUSS omission in latest TRM is an oversight), Gerbers, BOM, and all chips can be purchased in low volumes.  This is very different from RasPi, where most of the SoC is undocumented and it cannot be purchased in low volumes, and there are no Gerbers.

I'm not sure not using any particular piece of the hardware is an exemption since "technically" it is still proprietary. What if you decide to add an LCD display to the controller ? Certainly not an unusual possibility.

As I am sure you are aware the Raspberry Pi also has schematics. I find I rarely need Gerbers. I find having schematics essential. I would prefer to have both but I can definately live without Gerbers The only parts

of the BCM2835 that I know of that are not documented well enough to write drivers for are the GPU and the media engine (DSP?). Media engines are usually in the same boat as GPUs for the same reasons.

I'm not sure the AM335x can be purchased in low volumes either, got a source ?

Not talking about angels or pinheads, talking about proprietary hardware which can not by any definition be called open no matter which SOC it is on.

silsinork wrote:

Most other SoCs are an Arm core with an undocumented, propriatary, GPU along for the ride, you can ignore the GPU, probably even turn it off and still use the rest of the SoC. For the Pi, you have an undocumented, propriatary Videocore GPU, with an Arm along for the ride - you can't get to the Arm without the GPU as the SoC is first and foremost a GPU.

Even if the interface into that black box was fully documented it doesn't matter. A patent or licensing dispute could render you unable to legally use the GPU firmware and so unable to access the Arm.

No idea what you are talking about here, you can ignore the GPU on the Pi too. The GPU by itself is useless without the ARM core, the opposite is not true. It is first and foremost an application processor that

expects to have a GPU, but it does not require that the one it has be used. It may require that it have a bare minimum initialization but that does not appear to be a problem since several Linux distros, a BSD,

and RiscOS have been able to do it, and it is not unusual for other hardware to require some initialization as well before the core can get down to the real business at hand.

Since the GPU is a Broadcom design a license dispute is probably not reasonable. As far as patents go any patent dispute on any SOC whether the item in question is being used or not would have exactly the

same effect since the SOC physically contains the "patent". One could never guaranty that it would not be used unless it is removed and I'm sure that it can't be removed from any devices that already exists.

Where you go from there is up to the lawyers, judge, or jury.

Gary Stewart wrote:

 

No idea what you are talking about here, you can ignore the GPU on the Pi too. The GPU by itself is useless without the ARM core, the opposite is not true. It is first and foremost an application processor that

expects to have a GPU, but it does not require that the one it has be used. It may require that it have a bare minimum initialization but that does not appear to be a problem since several Linux distros, a BSD,

and RiscOS have been able to do it, and it is not unusual for other hardware to require some initialization as well before the core can get down to the real business at hand.

Actually you can't ignore the GPU. This device is first and foremost a GPU, albeit a GPU that's much more programmable than most - should you have NDA access to the docs.

The GPU boots first, loads it's binary blob, the GPU then loads the kernel image, then the GPU starts the Arm. Whether it's Linux, Riscos or whatever doesn't matter, the GPU is in control.  Yes this design is unusual, that's why it's of interest, and this architectural peculiarity has been well documented.

See   http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=290&sid=bb579b1214424657140765739307279a&start=28

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=2&t=3042#p40366

"We have implemented a number of configuration options in a file "config.txt" on boot partition (so /boot/config.txt from linux). These are read and acted on by GPU before the ARM boots.", today, one of those options is the filename of the kernel image to boot on the Arm.

http://en.wikipedia.org/wiki/VideoCore note there's several Videocore devices that don't have an Arm core at all.

Since the GPU is a Broadcom design

It's not, it was designed by Alphamosaic.

. As far as patents go any patent dispute on any SOC whether the item in question is being used or not would have exactly the

same effect since the SOC physically contains the "patent".

Unless the patent is in the GPU firmware blob that you require to be able to load the kernel.

Where you go from there is up to the lawyers, judge, or jury.

Absolutely. And you can't guarantee that the outcome of that process will be anything sane or reasonable.

Actually you can't ignore the GPU. This device is first and foremost a GPU, albeit a GPU that's much more programmable than most - should you have NDA access to the docs.

Never said you could ignore it, I said you don't have to use it. No it is not first and foremost a GPU, see next respoonse.

The GPU boots first, loads it's binary blob, the GPU then loads the kernel image, then the GPU starts the Arm.

The fact that the GPU initializes itself first and then loads the kernel image into RAM does not really change anything I wrote. It is still useless without the ARM core, it is the ARM

core that executes the software, not the GPU.

It's not, it was designed by Alphamosaic.

Broadcom bought Alphamosaic in 2004 so it has been their design for over 9 years now. Broadcom owns the IP, all of it.

Unless the patent is in the GPU firmware blob that you require to be able to load the kernel.

See previous response.

Absolutely. And you can't guarantee that the outcome of that process will be anything sane or reasonable.

Same applies to TI or for that matter anybody in the business of manufacturing anything.

Gary Stewart wrote:

 

I'm not sure the AM335x can be purchased in low volumes either, got a source ?

 

TI's product page: http://www.ti.com/product/am3359#samplebuy

Mouser part # 595-AM3359ZCZD72.  In stock, qty 1 pricing available.

AVNet part # AM3359ZCZD72.  In stock, qty 1 pricing.  (Cheaper than Mouser)

Others available in the US and Europe.

Thanks for finding those links.  I believe Newark/Farnell/element14 offer the AM3359ZCZD72AM3359ZCZD72 in single qty too:

http://uk.farnell.com/texas-instruments/am3359zczd72/mpu-sitara-arm-cortex-a8-324nfbga/dp/2113734

http://www.newark.com/texas-instruments/am3359zczd72/mpu-sitara-arm-cortex-a8-324nfbga/dp/95T5478

http://au.element14.com/texas-instruments/am3359zczd72/mpu-sitara-arm-cortex-a8-324nfbga/dp/2113734

jkridner (of TI and BeagleBoard.org) stated in the DESIGN West The specified item was not found. that they specifically design theBeagle family to use chips that are available in low quantity.

s ork wrote:

Did you catch the table in the BBB SRM showing power consumption ?   I was very interested in the Kernel Idling Display Blank figures of 280mA @ 5v, my Pi shows ~410mA in the same condition. So something is doing a better job.

BBB, with external 5V supply using the barrel connector, max3232 serial adapter and 100Mb network, no capes, sdcard, or usb devices

~230mA with kernel idle and ondemand cpu governor, cpu running at 300Mhz. Switch to performance governor, cpu at 1GHz, and ~300mA.

If anything, the figures from the SRM are worst case - I don't seem to be able to reach them without adding a good number of extras.

Maybe it's the PMIC doing an awesome job of being very efficient.  It's the same TPS65217C as used on the white BeagleBone, and the more I read about its capabilities, the more it's clear that it's quite a little star in its own right.

I suspect that the kernel isn't clever enough yet to control it dynamically through I2C, but in principle a board that uses this PMIC could be run very frugally when not all its subsystems need to be powered at the same time, and some parts put on standby.

I suspect there's several factors contributing to the better power figures. There does appear to be some communication between kernel and PMIC, as I saw a reference in some of the kernel docs that enabling pwm mode causes problems for ethernet (or was it usb, I forget) and it does appear to be used for the power button and shutdown.

I'm sure things will improve, it's still quite early in it's lifetime..

selsinork wrote:

 

I suspect there's several factors contributing to the better power figures. There does appear to be some communication between kernel and PMIC, as I saw a reference in some of the kernel docs that enabling pwm mode causes problems for ethernet (or was it usb, I forget) and it does appear to be used for the power button and shutdown.

I'm sure things will improve, it's still quite early in it's lifetime..

It is not clear from your description, were you using the BB Black as stand alone (using HDMI video) or tethered to a PC (not using HDMI video) ? If you were not that

would explain some of the difference.

Morgaine wrote:

I suspect that the kernel isn't clever enough yet to control it dynamically through I2C, ...

I'm quite sure that the kernel is clever enough since it has been handling power for years on notebooks, netbooks, smart phones, and more recently tablets. It has

been using the motherboard version of I2C (SMB) for years too so no problems there either. Whether the people who ported the kernel were clever enough is another

story but since both the Linux C and header files for using the TP65217 exits I assume they were.

Gary Stewart wrote:

 

It is not clear from your description, were you using the BB Black as stand alone (using HDMI video) or tethered to a PC (not using HDMI video) ? If you were not that

would explain some of the difference.

 

I was quite clear about what I had plugged in. Specifically so that others could duplicate the test.  Yes there will be differences, but unless both you and I have exactly the same things plugged it then the numbers can't be compared anyway. Although the SRM gives some general idea of what was connected there isn't enough detail - was their usb hub powered or not, what was the precise make and model of the thumbdrive etc.

So, for avoidance of doubt, here's some photos of what's connected along with the current reading. this is with the default angstrom build which uses the ondemand cpufreq scaling

root@beaglebone:~# cat /proc/version

Linux version 3.8.6 (koen@rrMBP) (gcc version 4.7.3 20130205 (prerelease) (Linaro GCC 4.7-2013.02-01) ) #1 SMP Sat Apr 13 09:10:52 CEST 2013

root@beaglebone:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

ondemand

root@beaglebone:~# cat /proc/cpuinfo

processor       : 0

model name      : ARMv7 Processor rev 2 (v7l)

BogoMIPS        : 297.40

Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls

CPU implementer : 0x41

CPU architecture: 7

CPU variant     : 0x3

CPU part        : 0xc08

CPU revision    : 2

Hardware        : Generic AM33XX (Flattened Device Tree)

Revision        : 0000

Serial          : 0000000000000000

Whether the people who ported the kernel were clever enough is another

story but since both the Linux C and header files for using the TP65217 exits I assume they were.

The driver exists and is in use, what it's capable of is a different question. From https://github.com/beagleboard/kernel/tree/3.9

• PMIC: working
• PMIC PWM: working, kills ethernet

so it should be clear that some of the drivers are still a work-in-progress at this point.

It appears that as of 3.9 their external patch set is much reduced. As they get more into the upstream kernel we can expect improvements and better integration with the existing power management.