12 posts
by noeska » Sun Nov 13, 2011 8:57 pm
When the board is released will there be a sdk for the device? Providing documentation and possibly example code.

Will that provide the necessary drivers? E.g. the binary opengles blob and instruction on how to use that?

I know i can do some hunting and find things on the inet but it would be nice to find it all from single starting point.
Posts: 9
Joined: Sun Nov 13, 2011 8:50 pm
by Jessie » Sun Nov 13, 2011 9:25 pm
Software will depend on which OS you decide to install on your device. For most I imagine this will be Linux, so the SDK would be any language avalible for Linux, and on a lower level any ASM for ARM. There are many options for Linux and many avalible libraries of code.
User avatar
Posts: 1754
Joined: Fri Nov 04, 2011 7:40 pm
Location: C/S CO USA
by abishur » Mon Nov 14, 2011 4:02 am
My understanding is that there isn\'t actually anything on the board proper that would require an SDK. Maybe the gpio, but that\'s more a driver....

As for the GPU blob, my guess is there will not be an SDK released for it as a) it\'s proprietary to broadcom and not the r-pi foundation so they can\'t release an SDK for a product they don\'t own and b) it operates at such a low level that there\'s nothing you need to do with it. There are items that will interface with it, but you\'ll have to use an SDK for those items, not for the binary blob ;)
Dear forum: Play nice ;-)
User avatar
Posts: 4478
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
by cnxsoft » Mon Nov 14, 2011 2:09 pm
If you want to get started, you\'ll need

1. an ARM cross-compiler, e.g.

2. Compile the kernel for ARMv6:

3. Get an ARM rootfs, e.g. with debootstrap

Using those you can run it in an emulator.
Once you get the board, you\'ll also need some extra files like the GPU blob (anything else?).

That\'s how I understand it.

Edit: With that method, it won\'t use hardware acceleration (GPU) and if you use Linux with a GUI it will look slow (check out the videos) but Fedora ARM will be ported to the raspberry pi with hw acceleration (for BCM 2835).
User avatar
Posts: 190
Joined: Sat Oct 15, 2011 2:33 pm
Location: Chiang Mai, Thailand
by noeska » Mon Nov 14, 2011 6:50 pm
What i want in an sdk is instructions on what to do with the blob (if anything) and what binary files to place where to be able to use opengles (to learn how to program opengles is not a topic for an sdk). To put it in parallel with an pc a pc with x hardware needs to provide drivers to make the hardware work. So an ati card needs ati drivers otherwise it will be framebuffer only. For low level people it would be nice to get a head start on the hardware with the needed documents in one place. E.g. one doc on framebuffer, one on audio, one on the arm cpu. I think all can be found on the inet when looking hard enough.

A sdk can be os specific also. I think for this device only linux comes to mind. Unless there are plans to support other os\'es also. Again needed drivers that are specific for this device should be provided or made clear where they can be retrieved. Together with references on the api that should be used for them.
Posts: 9
Joined: Sun Nov 13, 2011 8:50 pm
by abishur » Mon Nov 14, 2011 7:41 pm
There is nothing to be done with blob. My understanding is that once they get a certain protocol working (h.264, opengles, etc) then the only work anyone will need to do is on the protocol, not the blob. At that point it becomes an issue of getting an SDK for that particular protocol which is out of the r-pi team\'s jurisdiction ;)
Dear forum: Play nice ;-)
User avatar
Posts: 4478
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
by noeska » Tue Nov 15, 2011 7:16 pm
Agree, but in that case at least the correct drivers or .so libraries need to be provided with the raspberry-pi. As said using the opengles api is not an issue for the sdk, much better info on that can be retrieved elsewhere. But if no driver .so libary is provided with the raspberry-pi there will be no opengles or h.264 useable. So my idea is that such .so files should be provided as sdk together with some platform / os instructions. E.g. for linux install .so in folder x and make sure kernel module y is loaded and use bootloader z that makes sure the blob is ready for use.

On a more low level way it would be nice if the sdk provided some more low level docs like on the arm and on accessing things like a framebuffer and audio that makes developing drivers more easy and gives those people who want to use the raspberry-pi without an os a way.
Posts: 9
Joined: Sun Nov 13, 2011 8:50 pm
by eggn1n3 » Tue Nov 15, 2011 7:55 pm
What about header files that define the GPIO pins? If you want to make use of these GPIO pins in your C code, we would at least needs the definitions for the Raspberry Pi. Are these files released when the board becomes available (or documented)?
Posts: 106
Joined: Fri Jul 29, 2011 10:36 am
by Dapman02 » Tue Nov 15, 2011 8:58 pm
You shouldn\'t really need an sdk since it runs on an ARM linux install.
Posts: 7
Joined: Tue Nov 15, 2011 3:14 pm
by st599 » Wed Nov 16, 2011 11:33 am
Not sure he wants an SDK. More a \"How to decode H.264 using the RaspberryPi GPU\" Tutorial.
Posts: 26
Joined: Mon Sep 05, 2011 1:29 pm
by obarthelemy » Wed Nov 16, 2011 12:08 pm
Yep, the question is not clear to me: do you want to develop/port
- an OS variant ? which one ?
- a regular app (includes video stuff) ? which one ? in which language ?
- low-level hardware control stuff (using GPIO...) ? same questions as above.
Posts: 1399
Joined: Tue Aug 09, 2011 10:53 pm
by noeska » Wed Nov 16, 2011 6:18 pm
Tutorials are always a nice addition, but is not what i primary want in an sdk. What i want in an sdk are drivers and hardware documentation as said before. The binary drivers should come with instruction on how to install them and if for linux an opengles .so lib is provided no additional docs are needed other then if there are platform specific issues and where to install them and what kernel modules should be enabled (there are some nice books on opengles way better to learn opengles). Also \'the blob\' brings some functions that can be called from linux to bring things like opengl es and h.264. So i assume that blob should be called in some ways and i hope an sdk could bring documents on how to call / use it.

Proposed folder structure for an sdk:
--kernel modules
--chipset documentation
--arm documentation
--blob api

I want a sdk to support linux and to bring some more low level docs that help linux developer and developers of other os\'s or those who want to develop their own os. The linux part of an sdk could bring the binary drivers for opengl es while the generic part of the sdk could bring info on how to enable the linear framebuffer without linux.
Posts: 9
Joined: Sun Nov 13, 2011 8:50 pm