Page 1 of 1

VideoCore/EGL on a bare metal OS

Posted: Mon Dec 03, 2012 1:13 am
by benzn
TL;DR: Trying to link against the VC libraries provided with the firmware. Header files expect a real OS with pthreads, I'm nowhere near having an OS that conforms to pthread.

I'm relatively new to RPi (only really started using it yesterday). Started with input02 from Baking Pi (which was an incredible resource), fixed the cache coherency issues around writing to/from the mailbox (it's a shame the tutorials (except CSUD) aren't on GitHub AFAIK where we could submit pull requests/issues) and then managed to modify the terminal/makefile to call C functions that I've set up.

The tipping point for me to buy the RPi and get hacking was the release of at least the user land component of the VC drivers, as I've wondering what it would be like to write an OS with accelerated drawing (read: GPU) as a first principle. Since the documentation here is pretty much non-existant I wanted to verify some assumptions, I've made:

1) I spent a bunch of time grepping around the userland code/linux code/header files and from what I gather, to use EGL and whatnot the Linux driver shuttles along some messages over the VCHI channel (I think #3) of the Mailbox?
2) The static libraries included in the RPi firmware (i.e. libEGL_static.a, etc.) include the routines to talk to the VC through the mailbox. If I can link them, I can use them.
3) Provided I can deduce which messages to send over the VCHI channel (through calling the static libs), I shouldn't actually need any fancy concurrency primitives seemingly required by the header files.

I could comment things out of the header files until gcc stops complaining, or I could just extern the specific functions I need to call (I will probably do this).

Has anyone managed to link against the VC libraries on a bare metal project?

Re: VideoCore/EGL on a bare metal OS

Posted: Mon Dec 03, 2012 2:06 am
by benzn
I tried to extern eglGetDisplay and the linker barfed all over me looking for things like pthreads, etc. Next I disassembled the relevant library and found references to "tls" everywhere, which I had gleaned from other code to stand for Thread Local Storage, meaning it's unlikely I can magically link against the VC libraries without at least mocking out with dumb implementations a fair amount of concurrency primitives.

Earlier I hadn't fully cognitively recognized that the static libs in the firmware repo are actually just things compiled from the userland repo (I think?). I'll guess I'll go diving around the makefiles there to see how much I can turn off that I don't have implemented...

Re: VideoCore/EGL on a bare metal OS

Posted: Wed Dec 05, 2012 11:55 am
by krom
Hi benzn,

Just joined this forum for the 1st time because of your question =D
I've been doing bare-metal work on the R-pi for a long while now using the fasmarm
assembler, with help from my friend Dex to get my 1st pixel on the screen =D
I can confirm VCHI is channel 3...

Ever since the user land component of the VC drivers got released I have been trying to get an EGL Display context setup, but to no avail :(

Also I searched to see if I could find anyone in the world, that has setup an EGL context just using arm assembly or bare-metal on any device.
My search turned up nil...

I know that it would be just a few lines of code to setup an EGL Display from bootup...
Once I have an EGL context working, I should be able to run the EGL initialization &
pluck the correct major & minor version numbers "1.4" from whatever registers store them afterwards!

When I get my 1st triangle on the screen, I will make an exporter in blender that can export shaders/textures/worlds/object & character data automatically for use with EGL layer code. Also as I am a 3D artist I will be able to make nice bare-metal games really quickly...

I just wanted you to know I am in exactly the same boat, & if you find anything out there are people like me that would love to know!

Also I wonder if the mailbox property (Tags Channel 8) interface will ever contain a quick EGL Display setup...
Or is it doing this already when it sets up a frame buffer...
Also is the mailbox channel 1 (FrameBuffer) just an EGL Display???
(Would be funny if we had an EGL context available to us all along!)

If a dev in the know could enlighten me on this, that would be great =D

Anyway cheers for trying to get this to work & good luck.

Re: VideoCore/EGL on a bare metal OS

Posted: Sat Dec 08, 2012 7:33 am
by benzn
Awesome, good to know I'm not the only person wading through the torrential amount of header files in the github userland repo!

So now that it's the weekend, I'm back at it. I've been grepping around a bit more, looking to answer a few more questions, which maybe someone knows or can help investigating.

1) Is there a more accurate term for mailbox? Perhaps port? The userland repo has nothing matching mailbox, but the MMAL (multimedia something something) references ports a lot.

2) This file: ... /message.h , seems like it's close to what I might be looking for, however there's no magic reference to the mailbox addresses anywhere. Are there some other means via which the drivers might find the address to find the mailboxes at (possibly dynamically)?

3) I'd image there's something in here for setting up the regular framebuffer without any of the fancy EGL/MMAL/etc, but my grepping around doesn't reveal anything named so as to point to this. What would be the easiest way to find where the framebuffer is set up? My linux driver knowledge is a bit rusty.

Re: VideoCore/EGL on a bare metal OS

Posted: Sat Dec 08, 2012 9:40 am
by ghans
I have no idea what you are talking about , but where are you going
to document your findings ? The problem i see that the community
has many apt people like you , but beginners have a hard time and are
basically wasting time you already invested in research !
So i suggest putting your info in the Wiki.
I have seen so many awesome things done with bare metal ,
but am always missing some piece of the puzzle.
Eben already mentioned that the foundation might raise funds
to release docs for the userspace code (!) , but in the meantime
don't let your research get lost in the depth of the interwebz
(or worse , this forum).


Re: VideoCore/EGL on a bare metal OS

Posted: Sat Dec 08, 2012 9:46 am
by benzn
That's a good point, if I find/understand something I'll put it on the wiki (although to be honest I found this forum long before I found the eLinux wiki!) - but at the moment I couldn't add anything to the wiki that says anything meaningful. But when I do (crosses fingers) I will put it there - thanks for the advice/prodding.

Re: VideoCore/EGL on a bare metal OS

Posted: Sat Dec 08, 2012 11:44 am
by benzn
OK, so, the right place to look was really the kernel sources for the core stuff.

Mailbox related code is defined in this file: ... 708/vcio.c

and VCHIQ stuff (I still don't really know what this stands for but I'm pretty sure it's graphics related) is called: ... 2835_arm.c

and uses a mailbox call to send a pointer to a buffer with some other magic inside it.

I had previously been baffled by the lack of implementation files in the userland code and I think that's because it's mostly hanging out in the linux repo...

Also, this repo, which has work in progress getting the video core talking on free BSD may be very helpful as it separates some of the fancier not-needed features of the VC from the bare minimum steps beyond a framebuffer.

Re: VideoCore/EGL on a bare metal OS

Posted: Sat Dec 08, 2012 12:02 pm
by krom
Hi benzn,

Yeah I thought it would be good to message you, as once we have EGL working in bare-metal on the pi, some wonderful things will be possible =D
"Mailbox" is the correct terminology, I thought it was weird too when I started, but you get used to them real quick ;)

I released a bare-metal mandelbrot fractal program a while back, to help people get started on the pi.
It uses the most minimal code to setup a frame buffer on the pi, and turns on the floating point unit to display a fractal =D
The screenshot is here: ... 829#145829
The source is here: ... 411#147411
I also have a real-time julia animation demo using similar code...

I have a really nice pack of source, with many minimal demos I can give you, detailing everything I have found in the hardware.
This includes setting many different screen resolutions / bit colour depths.
8x8 Font character drawing using the cpu, and another demo using DMA with stride to display text.

I also have a Mailbox channel 8 multiple Tags demo that shows every "Get" Tag that you can get from a boot using my character display work.
Checkout this url, as it shows lots of useful Mailbox tags: ... -interface

I have failed at these things:
1. Create simple usb stack.
2. Audio output (Tried lots...)

So yeah if I can help you understand anything you don't know, I will be glad to =D

Re: VideoCore/EGL on a bare metal OS

Posted: Mon Mar 25, 2013 3:41 pm
by bilhew8078
I am working on a bare metal (no OS) embedded project. I've been able to set up interrupts, timers, gpio/i2c, and uart0. Many thanks to the information posted by dwelch67 as this gave me a great start. I have been able to set up the frame buffer through the mailbox system as well. I am now at a point where I want to be able to make calls to the VCU firmware API's to take advantage of the video core accelerated processes. From what I can see (and I may be completely blind...) most of the libraries for doing this are shared rather than static, so they won't work without a full blown OS.

This thread seems to have gone dead, but the discussion here seems to be similar to what I'm looking for. Have either of you made any progress?

Re: VideoCore/EGL on a bare metal OS

Posted: Mon Mar 25, 2013 10:19 pm
by krom
Hi bilhew8078,
Great to see another like minded person!

I am really sorry but after staring at the released Linux C sources for many hours, I have not got EGL in bare metal working yet :(

This is a very important goal as it would bring console quality 3D graphics to bare metal programming.
Also it would make multi layered 2D GFX blending a breeze.

I have been working on a simple software bare metal VFP 3D engine to tide me over, here is what I have completed:
1. Wireframe Quads/Tris/Cubic Bezier Curves/Lines/Points
2. Filled Quads/Tris
3. Back & Front Face Culling + Z Buffer
4. Matrix XYZ Translation & Rotation
5. Optimized Polys/Cubic Bezier Curves/Lines into Vector Floating point asm (My 1st Vector operations on ARM!)
6. Full Blender Exporter for Quads/Tris/Cubic Bezier Curves/Lines/Points/Material Colours...

I have put all my finished bare metal projects up on github (I have not released the software 3D Engine yet as I am still making the demos):
The instant I get EGL working I am gonna make a nice EGL Blender exporter and post some demos =D

If you get anywhere please update us on this forum as this would be really giant step in coding on the R-Pi =D
I will update here if I get EGL working.
Good Luck!

Re: VideoCore/EGL on a bare metal OS

Posted: Mon Mar 25, 2013 11:44 pm
by bilhew8078
Krom -

Thanks for the reply. I'm actually trying to access the VC for the video decode/playback functions but your thread here seemed to be the closest to identifying the information gap for using the VC in non-linux ways. It looks to me that the mailbox system must have a lot more going on than is documented. If I figure anything out (lol - doubtful), I'll post something here.



Re: VideoCore/EGL on a bare metal OS

Posted: Tue Mar 26, 2013 8:06 am
by tufty
It's on my list of stuff to do as well. Unfortunately, as it stands, the source dump is highly linux-specific. A large part of the problem comes not from the source itself, but from the infrastructure it expects to be around.

In order to minimise the work you need to do, you probably need a pretty much full libc including all the posix threading calls. That's liable to be pretty hard to do, but not impossible, and you can probably take some hints (at least) from the FreeBSD implementation (which, IIRC, only has 3 or 4 kernel level calls for threading, the rest being layered on top of those few calls in userland). From a first look at the source a while back (and thus from memory, which may be fading), it seemed that pthreads was not only the major external dependency, but also deeply ingrained into the design, and thus difficult at best to rip out.

The need for dlopen and friends can probably be mitigated by recompiling the videocore userland stuff static (although dynamic libraries are probably "de rigueur" for any real OS implementation, and, as long as you stick with a known and documented executable format like elf or mach-o, not too arduous to do). That mainly involves buggering about with makefiles.

Which leaves the mailbox interface, you'll have to tailor that to your specific OS implementation, and of course deal with any other linux-isms that crop up.

Of course, I'm "helping" myself by not doing it in "C", not using the "C" calling conventions, not using a standard executable format, and so on. You'll be there before I am.

Re: VideoCore/EGL on a bare metal OS

Posted: Tue Mar 26, 2013 10:35 am
by DexOS
You should take a look at the work of hermanhermitage.
As he's made good progress and as some useful tool to dump core memory.

Re: VideoCore/EGL on a bare metal OS

Posted: Tue Mar 26, 2013 12:39 pm
by jamesh
With regard to trying to abstract away from pthreads, the vcos_xxx stuff is intended to do exactly that. It's a OS independent layer that all the code should be using to use OS features.

So, in bare metal, you would need to re-implement the vcos_xxxx code for your particular OS, then you should be able to recompile the various libraries using your new vcos abstraction

The vcos code is in the userland git repo, and as supplied provides a abstraction for Linux that uses pthreads. See userland/interface/vcos/pthreads for what you will need to reimplement for your underlying library of choice.

Lots to do....

Re: VideoCore/EGL on a bare metal OS

Posted: Tue Mar 26, 2013 3:13 pm
by bilhew8078
It was great to wake up to the replies from all of you this morning. I spent quite a bit of time last night sifting through much of the FreeBSD implementation and had pretty much come to the conclusion that threads were going to be required, so it was great to hear from jamesh that
With regard to trying to abstract away from pthreads, the vcos_xxx stuff is intended to do exactly that. It's a OS independent layer that all the code should be using to use OS features.
Thus far this project has been coded 100% in assembler. I'm an old embedded guy and I feel a lot closer to the hardware talking directly to it - lol.

@jamesh: Thanks for pointing me in the right direction. If I make any progress I'll post here.

Re: VideoCore/EGL on a bare metal OS

Posted: Tue Mar 26, 2013 5:16 pm
by jamesh
I'm sure that somewhere out there there must be a free threads library for ARM that could be adapted...that's the majority of the work. The rest should be relatively simple.

Re: VideoCore/EGL on a bare metal OS

Posted: Tue Aug 27, 2013 8:50 am
by mimi123
Is there any vcos_* abstraction written for bare metal ?