I have been working with embedded systems (mostly micro controllers) for about 3 years. I want to know how much of RPi of actually open source?? I know arduino gives us complete details of hardware /software etc. But what about RPi? This is important since my team and I want to do the following with the raspberry pi [this project intends to use the RPi exactly like an arduino => no OS] :

  1. Rewrite the primary bootloader (ROM) to boot from flash rather than external SD card.
  2. Have a secondary bootloader in the on board flash, this activates the usb port of the pi and listens to it. It must accept binary code (that it will get from my PC) and save it on the flash. later start executing it.
  3. Develop our own device drivers to handle communication protocols.
  4. Develop our own uploader and debug environment for the PI, along with our custom implementation of embedded C for ARM (necessary to control GPIO's etc).
  5. Implement our own OS for embedded systems if possible.

Is this possible with the raspberry Pi? If not :
-> Which of my five goals are not possible with raspberry pi. what changes must I make to my project if I have to work with the PI?
-> What other boards are there in the market which will let me accomplish exactly what I want?


Some background

The most important thing you should know is that the RaspberryPi is a strange beast where the ARM CPU is the not main CPU - it's only a co-processor to the VideoCore GPU. When the RaspberryPi starts, a GPU blob is read from the SD card to the L2 cache and executed. This code then brings up all the important peripherals (RAM, clocks etc) and starts the ARM CPU. Then the 2nd stage bootloader or some operating system itself can be run on ARM CPU.

GPU blob is not only a bootloader. It's actually an operating system (Video Core OS) by itself. Some important elements of the system are not directly accessible by ARM CPU and it has to communicate with GPU (using mailbox messaging system) to use them. There is partial documentation about this available. Now Video Core OS (VCOS) is extended from time to time by Broadcom employees to enable features needed by Linux kernel, RISC OS or sometimes even some hobby OSes. There is no good documentation about this however, you would have to dig in the RaspberryPi forum, github and possibly other places to find information about this. But it's there.. somewhere. And there are a few people who write their own bare metal code or even OSes on the RaspberryPi to help you out. And of course a lot of open source code - RasbperryPi's Linux kernel for example.

VideoCore is proprietary, there is no official documentation and development tools. So unless you want to put a lot of effort, you can't rewrite VCOS with your own code. There is, however, some effort to reverse engineer the Video Core, you can find some information here.

Another problem is that the USB stack by Synopsys is proprietary and again there is no documentation for it and it seems that even with documentation it's hard to implement it reliably. But again, the code is available (Linux kernel, u-boot, CSUD). Using advanced graphics capabilities of Video Core may also be hard - there is some open source code for the graphics libraries, but it's only for the ARM side.

That being said, it was possible to make the RISC OS port from the information available (it's not entirely clear to me if they were using only publicly accessible information, though), some people are rewriting (independently from Broadcom) the Linux kernel for mainline, there is a FreeBSD port, 'U-boot` and others. So it is definitively possible to write your own OS. It's just not as easy as it might possibly be.

Your goals

Number 1

As far as I know, there is no way that the SoC could start in another way than the one described. So first stage bootloader has to be on SD card. And it has to be a GPU binary, not an ARM binary which is another problem. And there is no on board flash in the RaspberryPi which is also a problem.

Number 2

The main problem is that there is no on-board flash on RaspberryPi. You could add one and it could be activated in your bootloader (which would have to be the 2nd stage bootloader already). Writing a USB driver could be problematic, however.

Number 3, 4, 5

This shouldn't be much of a problem. Most of the peripherals (at least those accessible to the ARM) are documented here. Existing bootloader makes this even easier since you get your SoC completely configured. You can look here and here for some code and documentation.


I don't know any other board as good as RaspberryPi so it's hard to recommend something but you may take a look at some mature projects like OMAP based Beagleboard/Beaglebone/Pandaboard or you can follow the development of some new boards like the Allwinner based Cubieboard or PCduino. It all depends on what exactly you want to accomplish.

  • 3
    I want to +100 this answer. Well done.
    – orithena
    Apr 21 '13 at 20:57
  • @maligree lol, don't worry - it's already been done! :) Apr 23 '13 at 2:30
  • 1
    +1 for Beablebone because it is 100% opensource and you do have the ability to "respin" the hardware and make your own circuit board
    – benathon
    Apr 21 '15 at 4:09

To update Krzysztof's great answer, Broadcom finally publicly released some code, licensed as 3-Clause BSD, to aid the making of an open source GPU driver. The "rpi-open-firmware" effort to replace the Raspberry Pi VPU firmware blob started in 2016: https://github.com/christinaa/rpi-open-firmware. See more at https://news.ycombinator.com/item?id=11703842

There are a number of alternative boards briefly described and linked to from RaspberryPi - Debian Wiki, including ODROID-C1, Cubieboard, Banana Pi, Olimex's OLinuxIno Wifi and OlinuxIno Mini, EOMA68, and Beaglebone black.

  • Personally, I think the alternatives aren't as great, a lot of ODROID boards enforce signature checking on the bootloader and stop you from running your own code on them. TI OMAP3 family exists secure mode before calling your code also limiting what you can do with it. The VPU on RPi is actually pretty nice, I think it's what gives it the edge over other boards and now that we have a nice toolchain for it, things are looking good. May 18 '16 at 10:19

There is actually quite a lot you can do with the U-boot bootloader with Raspberry Pi. You basically just let the GPU load your ARM coprocessor SoC with the U-boot image as the "OS".

I found this article was helpful as an example. I haven't done it (yet), but I plan to. I happened to find your question while I was searching for a way to do this myself, and then I found the article and it looked like it might be useful to others seeking similar.

There's another article that contains more extensive instructions for building the U-boot image.

  • 1
    This is the kind of answer which may be useful in the beginning, but after a couple of years links stop working and there's not a single hint to what their content was. Consider at least telling which U-boot branch and which compiler you have used. Dec 12 '18 at 13:43
  • Thanks Dmitry. I'll come back to this soon and fix it up when I get some time.
    – Alan Mimms
    Dec 17 '18 at 7:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.