jonathan68
Posts: 10
Joined: Mon Jun 08, 2015 2:36 am

Bare Metal "Hello Framebuffer World"

Sat Jun 27, 2015 9:11 am

Ok so this might be a complex hello world "assignment", but i was pondering how hard it would be to code a bare metal hello world (as kernel.img which is loaded by start.elf) in c, which then loads a hello.bmp (or hello.png, whichever is easier) and displays it as a static image, viewable on the hdmi. i suppose the file would need to be the correct dimensions for the given display mode. also, i am assuming the task of accessing a file on the SD card is possible, given that the GPU has already done so at least 3 times in order to boot the device up.

is this a huge undertaking? or are we limited to a simple flashing LED example as show in this excellent tutorial here:

http://www.valvers.com/open-software/ra ... g-in-cpt1/

it's a shame the author of that tutorial hasn't got to part 5 yet, which was going to explain how frame buffers work.

User avatar
rpdom
Posts: 15363
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: Bare Metal "Hello Framebuffer World"

Sat Jun 27, 2015 11:25 am

All my bare metal stuff is in assembler. I learned how to use the framebuffer on the Pi by following bits of the Baking Pi course.

I can display (uncompressed) graphics and text without a problem, but I haven't written anything to access the SD card yet so I can't read files. Currently my graphics data is stored in an initrd file that gets loaded in by the firmware.

The course is based on the early Pi 1 and needs some tweaks to work on a B+ or a 2B (I haven't tried a Pi 2B yet)

JS2
Posts: 14
Joined: Thu May 14, 2015 11:40 pm

Re: Bare Metal "Hello Framebuffer World"

Sat Jun 27, 2015 12:08 pm

I can confirm that baking pi does not work on an RPI2, even after adjusting the peripheral base address. I can give you some working code, however a) it is all in assembly and b) it sounds like you are on an RPI1 anyway.

Interestingly enough, I just implemented the exact thing you're trying to do. The trick was to write a small program to read in a bitmap and convert it to something I could embed in an asm file with .word declarations.

Something to look out for (if you have your own loader) is a 32 bit color 640x480 image takes up 1,228,800 bytes, which takes forever to transfer with any safe UART speed. In my case, paletizing and using RLE got the file size down to 8K, and the decoder was 8 lines of assembly. However, to keep it simple I would just stick to smaller images at first.

TL;DR: just save your file as a bitmap, convert it offline to an include file containing the image data, and then copy it to the framebuffer. Use the FB tutorial here if you are on an RPI1

https://www.cl.cam.ac.uk/projects/raspb ... een01.html

JacobL
Posts: 76
Joined: Sun Apr 15, 2012 2:23 pm

Re: Bare Metal "Hello Framebuffer World"

Mon Jul 06, 2015 12:54 pm

Yes, it is definitely doable. You can follow the BakingPi tutorial linked in previous reply to a point where you actually have a basic printf() implemented. From this point, it is pretty simple to do your printf("Hello world") or whatever you want to print. BakingPi is assembly, but it is pretty simple to just write the matching code in C for each step in the tutorial, at least if you have written C before. Note that you will need an implementation of __aeabi_uidivmod (The tutorial gives a simple division implementation, but I don't know the exact ABI for __aeabi_uidivmod). If your work is GPL compatible then a simple googling of the name will get you many implementations you can use, mostly from various versions of GCC.
i am assuming the task of accessing a file on the SD card is possible
Not directly. You will need to write your own SD host + SD card + FAT filesystem driver, which can then enable access to the SD card. This driver is included in the GPU boot code, but you will not be able to call directly into this code..

Exile In Paradise
Posts: 3
Joined: Wed May 07, 2014 3:57 pm

Re: Bare Metal "Hello Framebuffer World"

Thu Jul 09, 2015 6:30 pm

JS2 wrote:I can confirm that baking pi does not work on an RPI2, even after adjusting the peripheral base address. I can give you some working code, however a) it is all in assembly and b) it sounds like you are on an RPI1 anyway.
I have managed to get the OK02 example from Baking Pi to compile and run on an RPi2B.

Not only has the peripheral base physical address changed from 0x20000000 to 0x3F000000, but the OK/ACT GPIO pin changed to 47, as well.

I have written up the changes to OK02 and put them on the baking pi github as an issue for Alex to review, along with a working OK02 source/main.s to get started with.

Hopefully this can help jumpstart everyone to help figure out how to update Baking Pi ... to Baking Pi 2.

For the OP's project, there is some good emmc.c code out there in github, linked elsewhere in the Bare Metal forum.
You could link against the existing C code at first, then worry about decomposing it to just the assembly bits if that's what you're looking for.

My suggestion would be to first implement the file load using a raw bitmap... just raw RGB triples drawn to the screen in a fixed X by Y manner.

Then worry about reading the stream and decoding image formats like PNG, which have a lot of additional complexity...

User avatar
Arjan
Posts: 262
Joined: Sat Sep 08, 2012 1:59 pm

Re: Bare Metal "Hello Framebuffer World"

Tue Jul 14, 2015 7:23 pm

Not directly. You will need to write your own SD host + SD card + FAT filesystem driver, which can then enable access to the SD card.
I have got a working example for SD host + SD card here : https://github.com/vanvught/rpidmx512/tree/master/emmc
and FAT here : https://github.com/vanvught/rpidmx512/tree/master/ff9b

And an example how to open a file and read from it here https://github.com/vanvught/rpidmx512/b ... ams.c#L172

- Arjan

Are you looking for Raspberry Pi DMX-512 / RDM solutions? Check this http://www.raspberrypi-dmx.com/
http://www.raspberrypi-dmx.org/
Open Source DMX/RDM/MIDI/OSC/Art-Net/sACN solutions

Return to “Bare metal, Assembly language”