Pi vs BeagleBone-Black

I'd like to add another pro for the BeagleBoard Black.

With the exceptions of the integer real time processors PRU-ICSS (not sure at this point why that is), and the PowerVR GPU for

well known reasons, the AM3359 technical documentation from TI is excellent to the point of overwhelming. The Technical Reference

Manual is over 4000 pages. No I did not accidentally add any zeros !

Gary Stewart wrote:

 

With the exceptions of the integer real time processors PRU-ICSS (not sure at this point why that is), and the PowerVR GPU for well known reasons, the AM3359 technical documentation from TI is excellent to the point of overwhelming.

You're right about the proprietary GPU, that seems to be an endemic problem for open source in the industry.  It's not true for the PRU-ICSS though.

The PRU-ICSS is fully documented in the Technical Reference Manual SPRUH73C, with the entirety of chapter 4 (250 pages) devoted to it.  Also, there is a full package of PRU-related materials on Github, including more documentation and source code of the PRU's PASM assembler, a Linux loader, demos, etc.  I've even checked that the assembler compiles and it does.

The BeagleBone materials on Github are at https://github.com/beagleboard/am335x_pru_package

The PRU has been used successfully in quite a number of projects as a quick web search shows, and this long predates the BeagleBone Black since the original BeagleBone uses a slightly different version of the same AM3359 SoC.

Morgaine.

Addendum: Repeating the link to TI's wiki pages on PRU which I gave in my first post on this thread, in case it was missed when looking for docs.  There is a developers' link at the bottom of that first page.

Morgaine Dinova wrote:

 

John Beetem wrote:

 

PSoC has had limited success, largely because the chips have been rather expensive.  PSoC4 is supposed to change this by providing a highly capable SoC for US$1.

 

Did you notice that the  CY8CKIT-042 PSoC4 Pioneer Kit board contains, in addition to the PSoC4 target device, a PSoC5 device that's used for board programming and debug?  (The intro video mentioned it.)  If PSoC4 is the cheap device, you'd think they'd use a second PSoC4 to provide that function on this cheap board.

 

It seems a little bizarre, but I guess they already had PSoC5 code developed for the required function, and don't expect to sell enough boards to recoup additional development required to use the cheaper part instead.

Yes, I saw that.  It's not at all unusual to have a much more capable part as the program/debug interface.  If I've read the data sheets correctly, the PSoC4 only has 32KB flash and 4KB SRAM, while the PSoC5 has 256KB flash and 64KB SRAM.  It's hard to squeeze much into 32K+4KB, particularly if the code is written by people who didn't grow up carrying around boxes of punched cards (2000 cards per box * one box per arm * two arms per human = 4000 lines of code that you can "comfortably" carry around if you have two arms).

Reminds me of an LPXpresso board I have for the LPC1114FBD48/301,1LPC1114FBD48/301,1 -- a Cortex-M0 with 32KB flash and 4-8 KB RAM.  It's controlled by an LPC3154 -- an ARM9 with 192KB RAM.  I don't know how this compares to an mbed because my mbed has the controller's part number erased.

It's often the case that the control SoC is the one to play with, provided that the vendor hasn't disabled access.

John Beetem wrote:

 

Reminds me of an LPXpresso board I have for the LPC1114FBD48/301,1LPC1114FBD48/301,1 -- a Cortex-M0 with 32KB flash and 4-8 KB RAM.  It's controlled by an LPC3154 -- an ARM9 with 192KB RAM.

Haha.  That's a pretty severe case of an application processor in servitude to a microcontroller.  It can't be impressed.

I guess it's only a matter of time before Cortex-A series devices are given such roles too, particularly if a small realtime microcontroller needs a full-function IPv6 stack and comprehensive networking apps, and the simplest way of providing this is by giving it an entire Linux subsystem on a different SoC.

Morgaine Dinova wrote:

 

I guess it's only a matter of time before Cortex-A series devices are given such roles too, particularly if a small realtime microcontroller needs a full-function IPv6 stack and comprehensive networking apps, and the simplest way of providing this is by giving it an entire Linux subsystem on a different SoC.

Actually, at some point it might be a good idea just to have the vendor's eval board be a BeagleBone cape.  That way they don't have to design their own controller hardware.  One problem with this is that the vendor has to worry about whether the user has a compatible operating system.  I don't have experience with Linux device drivers, but it may also be that it's a lot easier to write the whole debug controller on a bare chip than to write the Linux driver   Note that I didn't mention RasPi -- the vendor needs an open hardware project so it's not stuck if the controller board is discontinued.

John Beetem wrote:

Note that I didn't mention RasPi -- the vendor needs an open hardware project so it's not stuck if the controller board is discontinued.

How is any ARM SOC with a proprietary GPU considered to be open hardware ? Isn't that a contradiction of terms ?

Gary Stewart wrote:

 

John Beetem wrote:

 

Note that I didn't mention RasPi -- the vendor needs an open hardware project so it's not stuck if the controller board is discontinued.

 

How is any ARM SOC with a proprietary GPU considered to be open hardware ? Isn't that a contradiction of terms ?

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 don't know what discussion OSH advocates are having about GPUs.  I suspect some argue that if you provide a GPU + binary blob, then as long as the API interface is fully documented you can think of the GPU as an OpenGL black box that happens to be implemented with downloadable black-box microcode.  However, in that case I would say you can't call it a GPU -- it's an embedded OpenGL engine where the implementation is hidden the same way you don't expose the innards of the ARM implementation.  IMO if you call it a GPU, then you have to let me program it or it's not OSH.

I find the fact that FPGA bit streams are undocumented is much more annoying.  Yet, OSH champions like FPGAs since it lets them design their own open CPU architectures.  So plenty of opportunities to argue about how many angels can dance on the head of a pin.

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. 

There's no argument that GPU's are a problem and are likely to remain locked up behind a wall of patents, cross licensing and whatnot. So regardless of other issues the Pi isn't on the same playing field here. 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.

Another advantage for the BeagleBone Black, beyond OSHW, is that the BeagleBoard.org development community (TI employees, Linux kernel maintainers & various individuals) have been working hard to get all remaining patches accepted by the mainline.  jkridner has told me that is an important goal for the project to be able to just git clone Linus's kernel and go.

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.

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.