Talk:Raspberry Pi/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Archive 6

Non existent documentation for the GPU

The choice of Broadcom (BCM2835) products result in non-existent documentation as always. See this thread at raspberrypi.org. When the RE starts, please post a link to results. Electron9 (talk) 18:51, 19 April 2012 (UTC)

Did you look at the last page of that thread? I would hardly call [ http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf ] "non-existent documentation". There is also some supplemental material on the official Wiki: [ http://elinux.org/RPi_Low-level_peripherals ]. --Guy Macon (talk) 21:58, 19 April 2012 (UTC)

Documentation for the GPU? do you have documentation for the GPU on the videocard in your PC? Probably not, and it only works because there is a "binary blob driver" from the chip manufacturer for windows, and perhaps for Linux for it. Documentation on how the innards of a graphics processor works are almost never released, not for the one in your ATI based videocard, and not for the GPU in the broadcom either. As they are considered a trade secret, also there is almost nothing you on your own could do with detailed knowledge about how the innards of the GPU work. Only a company with hundreds of highly trained employees could. Everything else, not related to graphics processing in the broadcom chip, is fully documented. Even the schematics of the Raspberry PI have recently been published. Mahjongg (talk) 23:56, 19 April 2012 (UTC)

Even in the area of graphics processing, there is extensive documentation available about how to tell the GPU what to do, which is a lot more important than the internal GPU details. The BCM2835 supports OpenGL ES 2.0, which is really nice to work with. You can even buy the OpenGL ES 2.0 Programming Guide at Amazon.com ( http://www.amazon.com/OpenGL-ES-2-0-Programming-Guide/dp/0321502795 ). --Guy Macon (talk) 01:00, 20 April 2012 (UTC)

Yes I know, but I think the OP was complaining about lack of documentation on the internal workings of the GPU, which reminded me of zealots who claim that a Linux computer with a standard graphics card isn't really a (open sourced) "linux computer" because the internal firmware in the video card isn't open sourced. Mahjongg (talk) 10:08, 20 April 2012 (UTC)

What's missing is documentation that is sufficient to write a driver that will provide the same software API for other OS flavors as for Linux Feodora software. So the hardware-API is the required documentation. The internals of the GPU is not really that relevant, but hw-API is. Asfair many Intel-GPUs provide this. But it might have changed. Electron9 (talk) 11:55, 21 April 2012 (UTC)

Intel GPUs have been a bit of a mixed bag:

http://www.phoronix.com/scan.php?page=news_item&px=MTAzOTI

But there are are some interesting developments on the Raspberry Pi / Linux front:

http://www.phoronix.com/scan.php?page=news_item&px=MTA1MTc

http://www.phoronix.com/scan.php?page=news_item&px=MTA0OTQ

http://www.phoronix.com/scan.php?page=article&item=arm_mali_reverse&num=1

For those who are following along, it should be emphasized that we are talking about accelerated video. OpenGL ES 2.0 is more than sufficient to run X, Gnome, KDE, etc. Accelerated video is more of an issue if someone wants to write state-of-the-art games that take full advantage of the GPU. --Guy Macon (talk) 13:56, 21 April 2012 (UTC)

Followup: there is a review at http://www.bit-tech.net/hardware/pcs/2012/04/16/raspberry-pi-review/ that reports a noticeable performance hit while web browsing from the non-accelerated video, so it appears that it is more of an issue than I described above. --Guy Macon (talk)

Time for a Open Graphics Project style of project? ;-) Otoh, maybe a Mali (GPU) based board with a Lima driver would be feasible at a low price? It's desktop, video and 3D that I find important in that order. Locked drivers make moved between operating systems ports messy. And will usually brick hardware in the feature when new kernels will no longer work with old library-APIs. And bare hardware assembler demos will also be f-cked. Electron9 (talk) 14:22, 21 April 2012 (UTC)

Yes having those API's would be nice, but at the moment the list of devices that publish their Video Acceleration API's is a very short list of very low end devices who's manufacturers have nothing much too lose from revealing the details of their (older) hardware to the competition, all the more important manufacturers do not reveal any such details about their hardware, and expect software to use the supplied drivers. But who knows, many people supposed that there never would be schematics for the raspberry PI, as they were not needed for understanding and using the device, and relevant questions were usually answered by people in the know (like the trip value of some of the polyfuses used, etc), but still now we have a complete schematic (only the interface to the top POP RAM chip isn't revealed, but there isn't much that you can do with that). A similar situation exists with the video API, but people who have used it (from the RPF) had to sign a non disclosure statement, so I would not have too high hopes of them revealing the API. nevertheless there is talk of such people having enough access to the API to write accelerated video/2D drivers, and other drivers they have made have not been tied to one single variant of Linux, (or for that matter the OS itself) so it doesn't seem too much of a problem. All this is a very similar situation to the larger bulk of video hardware that is out there. Mahjongg (talk) 14:04, 21 April 2012 (UTC)

GPU firmware

Is the firmware image some kind of FPGA image, or CPU/DSP code? and what's the status on redistribution rights of that binary file? Electron9 (talk) 00:14, 25 April 2012 (UTC)

It's comparable with the firmware of any other video card, it's the code the GPU (which is a vector processing unit) runs to create 2D and 3D images. On Video cards its mostly stored in very fast RAM directly coupled with the GPU, and is normally partly loaded from an on-board flash, containing the "Video BIOS" which contains elementary stuff like fonts so that even without an OS the videocard can display a (text based) image, and later more code is uploaded from storage for doing vector calculations.

As without the "blob" the GPU has nothing to run, AFAIK it is an indivisible part of the "video generator", so if you own the hardware (the SoC, including the GPU) you also have the right to use the "blob". The GPU is worthless without it, and the "blob" is worthless without the GPU.

The only difference between a normal videocard and the GPU is that the latter is much more integrated with the whole SoC (shares memory with it), and the GPU doesn't have a "VideoBIOS" as such, but only a small CPU (yes, a third CPU, after the ARM, and the vector processor) that is tied to a very small ROM containing code that loads the "blob" into the GPU from the SD-card, part of that code is code for the ARM CPU who boots with it, and loads the rest of the code into normal RAM and executes it. So the GPU is also used for booting the system. In fact the SoC is nothing more than a GPU that can boot itself, with an ARM CPU attached to it. For more info you can ask questions on the R-PI forum. Mahjongg (talk) 08:39, 25 April 2012 (UTC)

Block diagram

this block diagram, on the right:

Block diagram

is a bit confusing in that the block marked ethernet actually functions as a USB hub with three USB ports to which one of them the actual USB Ethernet adapter is connected. it Is true that the hub, and the USB ethernet adapter are integrated into a single chip, (the LAN9512) but the block diagram as drawn doesn't make sense. Mahjongg (talk) 23:49, 7 May 2012 (UTC)

Redirect from "Raspi"

Hi, not sure if I'm remembering wrong, but I thought there used to be a redirect from "raspi" to this article.
If not, should there be? Seems to be a common shortening. 118.209.10.121 (talk) 23:27, 21 June 2012 (UTC)

Are you thinking of RasPiRasPi? -- Trevj (talk) 06:08, 22 June 2012 (UTC)

I just checked all the redirects to this page for errors (many had no categories) and added a few. The list of titles that redirect here is now:

R-pi
RASPI
RasPi
Raspi
RaspPi
RaspBerry Pi
Raspberry pi
RaspBerryPi
RaspberryPi
Raspberrypi
Raspberyy Pi
Rasberry Pi
Rasberry pi
Razberry Pi
Razberry pi
(15 redirects)

"Raspberyy Pi" was already there and isn't worth the bother of removing it, but I avoid redirects for things like that. Let the "Did you mean: Raspberry Pi?" system take care of those. --Guy Macon (talk) 08:20, 22 June 2012 (UTC)

Regarding Raspberyy PiRaspberyy Pi, I got pissed off with mistyping it more than once! -- Trevj (talk) 11:05, 22 June 2012 (UTC)

Arch Linux ARM vs Arch Linux

There currently is no Arch Linux ARM article, a project *completely* separate from Arch Linux. Do not "fix" the "Arch Linux ARM" links by making them redirect to the Arch Linux article. Make the article if it bugs you that much. — Preceding unsigned comment added by Buhman (talk • contribs) 15:10, 16 June 2012 (UTC)

Excellent idea, I have done exactly that. No bugs were hurt in the process. Mahjongg (talk) 00:22, 17 June 2012 (UTC)

I like it; much better; thank you very much Buhman (talk) 01:27, 25 June 2012 (UTC)

AROS

When is somebody going to add AROS as a planned operating system choice for Raspberry Pi? In-Correct (talk) 18:51, 21 June 2012 (UTC)

Do you have a reliable source mentioning the porting of AROS to the Raspberry PI? The standard version will never work as its written in x86 code. Mahjongg (talk) 21:26, 9 July 2012 (UTC)