SoC Broadcom BCM2835

The RaspberryPi has a most intriguing Soc (System on Chip) -- CPU plus GPU plus more on the one chip. It is a Broadcom BCM2835, and has the ARM1176JZF-S CPU running at 700MHz.

Raffy recently posted a link to a PDF for the CPU:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301g/DDI0301G_arm1176jzfs_r0p7_trm.pdf

However, the GPU remains a mystery. I can't find any details specs on-line, only this:
http://www.broadcom.com/products/BCM2835

Here is another board that has the BCM2835, the Roku2:
http://www.mycablealternatives.com/2011/07/roku-2-xs-teardown/

I would love to locate Xorg driver source for the GPU. I presume that the RaspberryPi people have such a thing, and will release the source.


Posted on 5 Nov 2011, 9:37


Comments:

Posted on 5 Nov 2011, 17:28 by lobster
Pi and chips
Still using Slacko on a X86 awaiting Pi . . .
I compiled Brandy Basic for Slacko, So BBC Basic (one of Rpi aims) is available as is the superior Linux only Bacon Basic. Vovchik is taking an active Bacon steak [eh . . . stake] and others are also hamming it . . .
John (aka Judge Dredd our beloved and beleaguered forum uber meister) who created MurgaLua might well update and develop Lua on this board
MU might come out of Puppy retirement (unless he hangs out in the German section of the forum)
and offer Puppy Basic . . .
We also have Vala and Genie as potential alternatives to C and Pythonesque languages
NetLogo (requires Java) would be a great teaching language. Runs OK in Puppy.
X-basic I have had running on Puppy etc, etc . . .

I look forward to devx-arm


Posted on 5 Nov 2011, 21:46 by Raffy
Booting Sequence
Here's how the elinux.org wiki describes the booting sequence in R-Pi:

"BootRom

The boards do not include NAND or NOR storage - everything is on the SD card, which has a FAT32 partition with GPU firmware and a kernel image, and an EXT2 partition with the rootfs.

We're not currently using a bootloader - we actually boot via the GPU, which contains a proprietary RISC core (wacky architecture ;) . The GPU mounts the SD card, loads GPU firmware and brings up display/video/3d, loads a kernel image, resets the SD card host and starts the ARM.

You could replace the kernel image with a bootloader image, and that would work fine."


Am still looking for the GPU binary...


Posted on 5 Nov 2011, 22:19 by BarryK
Re boot sequence
Yeah, I read that, it is fascinating.



Posted on 5 Nov 2011, 22:26 by tempestuous
framebuffer graphics
ARM devices are generally aimed at dedicated small devices like mobile phones, and as I understand it such devices use direct framebuffer access, with the display interface usually custom written. There's no X server, and no window manager.
Once you introduce an X server and window manager, the streamlined ARM CPU/GPU then incurs a processing penalty that was not generally intended by the ARM developers.
I'm really a bit surprised about the hype on the forum about getting Puppy onto ARM devices, since it may take a lot of optimisations for it to work properly ... but anyhoo,
I think the Xorg solution in this case will be fbdev/uvesafb. See -
http://www.murga-linux.com/puppy/viewtopic.php?t=67166
Note: the uvesafb kernel module is not enabled in most Puppy versions to date.


Posted on 6 Nov 2011, 4:48 by Dougal
RasPi GPU
Barry, this was answered in the Q&A:
http://www.raspberrypi.org/archives/169#comment-2441
One of the guys is the head of graphics in Broadcom, so he has the knowledge (and connections) which enabled him to create that hybrid SoC.

It looks like a decent toy, but not being able to use it with a VGA monitor kind of makes it useless for me (I'm certainly not going to connect it to the TV...).


Posted on 6 Nov 2011, 4:50 by mavrothal
Koji
Through the OLPC project, Fedora has done major strides in ARM building. Today they have almost identical builds for x86- and ARM-based XO laptops
They use the koji build system (http://fedoraproject.org/wiki/Koji) and currently their ARM branch has 11000+ packages (http://arm.koji.fedoraproject.org/koji/packages).
Cross compiling tools can be found in http://ftp.linux.org.uk/pub/linux/arm/fedora/cross/latest/
You may want to take a look.


Posted on 6 Nov 2011, 4:57 by Dougal
Xorg Driver
Note that while they might have an open xorg driver, he said (somewhere) that the kernel DRM driver will not be opened -- for the same reason no other 3D drivers exist for embedded devices...


Posted on 6 Nov 2011, 20:32 by Raffy
A GPU with ARM11
To help explain the boot sequence, here is a useful quote from the Hardware Q&A:

"jamesh on September 14, 2011 at 12:24 pm said:

As Liz said the 2835 is basically a Videcore IV with the Arm11 bolted in (And Gert was on the team that did the bolting). Its why it has a rather unusual boot sequence the chip is a GPU with added Arm goodness, rather than an Arm with added GPU goodness."



Posted on 7 Nov 2011, 6:06 by dogle
ARM -VGA
Concur with Dougal, (and appreciate Raffy's preceding quote) ... nice toy, interesting challenges ... but no VGA = not serious stuff for practical purposes.


Posted on 2 Jan 2012, 24:24 by Philip Machanick
VGA: it does HDMI
It has HDMI out so you can get an adapter to connect to a VGA device. Analog TV out is a nice extra for low-income parts of the world but isn't the only port.


Posted on 28 Feb 2012, 23:47 by Jim Manley
Embedded SW Engineer
Folks need to understand that the primary purpose of the R-Pi is educational at the _lowest_possible_cost_, not a be-all, end-all computing device for geeks doing high-end development. The cost factor eliminated VGA support which, in the grand scheme of things, is an end-of-life analog technology, as virtually no devices to be made in the future will support it, and the R-Pi could easily have a lifespan of a decade, or more, in various improved forms. Some may question why, then, is there support for composite video and the answer is that is much more common than VGA on analog TVs, VCRs, DVD players, etc., found at the lower end of the economic ladder around the world. The single signal line (plus ground) required for composite also makes it much simpler to support than the 10 lines associated with VGA. I'm guessing that composite comes free on the GPU's ouput, so, bringing it out to a connector is trivial.

It should also be noted that, since the BCM2835 is a GPU with an ARM11 CPU tacked on, and not the other way around, high-resolution color graphics are going to be a primary focus in educational applications for the R-Pi, just as they were when the Apple ][ debuted 35 years ago (yeah, I'm an original owner of one, and picked it over the Radio Shack Model I, which only had lo-res B&W block graphics).

The fact that it supports 3-D via OpenGL ES 2.0 shouldn't be lost on anyone, as it's pretty obvious that kids will be able to develop some pretty nifty games and virtual world simulations at 1080p/60 at the XBox 1 level, on a $25+ system.

It will be interesting to see what the kids gravitate towards, and we can only hope the educators expose them to as many options as possible, if the kids don't ferret them out themselves.


Posted on 12 Apr 2012, 20:12 by Roger Wolff
TV support.
Jim Wrote:
Some may question why, then, is there support for composite video and the answer is that is much more common than VGA on analog TVs, VCRs, DVD players, etc., found at the lower end of the economic ladder around the world.
I don't think that's it. the RPI is basically a breakout board for the BCM2835. The BCM2835 supports CVBS out, so the RPI does too.
Why does the BCM2835 support CVBS? Because it is a chip intended to be used as a mobile phone or media center. Both of these traditionally have TV out.
And also CVBS is a very "slow" signal, easily integrated onto a chip like the BCM2835. VGA can reach quite high bitrates so it is not something that is easily added with a few gates here and there.