Micro OS for the Raspberry Pi ARM (55.html)

ARM Assembly Language.

ARM Assembly Language Programming by Peter Cockerell" is a 1987 book that is now available on the web . . here.

Micro OS for the Raspberry Pi ARM (55.html)

Josh Barretto has apparently created a micro OS for the Raspberry Pi. His notes in the Raspberry Pi Forum describe some the questions that he had and the answers that he received.

POSTED
by joshbarretto » Wed Nov 20, 2013 6:18 pm

Ok, so I've started writing assembly, aiming to make a micro OS for the Raspberry Pi.

I realise of course that it's a massive undertaking, so I have very low goals for the project. Drawing a few pixels on the screen would be a huge achievement for me. However, I've quickly come to the conclusion that the GPU is much better for certain kinds of calculations. Primarily graphics, but also a lot of other things would be far more efficient if run off the Pis GPU such as calculation of large prime, or other such things.

I'm wondering how I would go about connecting together the GPU and CPU in assembly. Would I need to use different assembly for the GPU? Or would ARMv6 assembly function fine on it?
Thanks,

Josh


POSTED
by joshbarretto » Fri Nov 22, 2013 10:27 pm
Thanks all :)

I'm glad to report that I've actually compiled and created my first little OS, a system that outputs power to certain GPIO pins. It's not much, but for me it's a great first step ;)

Thanks for all of your help,

Josh

The GPU is not officially documented, but some progress has been made:
Info: VideoCore IV Programmers Manual
....
I would recommend you write the actual micro OS using ARM assembly and then use the mailbox execution API (
Info: VideoCore IV Kernels under Linux ) for the GPU code.
You definitely cannot use ARM assembly on the GPU though.
....
You are not going to be able to go to first principles on this. Use the Cambridge example to get a frame buffer pointer and just dump bytes into that and that will make pixels on the display. End of gpu discussion. Do everything else in arm, actually that is all arm as well other than asking for and waiting for an answer from the gpu.

If you want to use the gpu, write code for it, that is possible, but you will then have to sacrifice the use of the arm and the display. I assume you dont want to walk away from the arm and video/display.
....
why can't he have the CPU and the GPU using the method I mentioned?
....
If you have a register spec that defines how the gpu starts the arm then you certainly can.
....
No no, I mean let the stock firmware start the gpu, set up the arm core and execute your bare metal arm kernel, which then asks the gpu to execute VC kernels when necessary (how it's done from linux, but without linux).
Info: VideoCore IV Kernels under Linux
....
Yes this is completely supported from the Raspberry Pi perspective... The interface Dom inserted allows you to run code on the VPU (vector processing unit), you just need to make sure you get the physical addresses for anything you want to work with and then write the cool algorithms on the vector unit!
....
If you can actually do anything interesting on the VPU I'll definitely read your CV! ....
Looks good then, enjoy. They are further along than I thought. The GPU is heavy on the math so it may work well for what you are doing.
....
I'm glad to report that I've actually compiled and created my first little OS, a system that outputs power to certain GPIO pins. It's not much, but for me it's a great first step ;)

Thanks for all of your help,
....
A little off-topic, but...

I've heard that C is actually quite efficient when compiled to assembly, often more efficient than assembly due to the fact that it's easier to write an algorithm in C. I was wondering - how do I go about writing certain parts of this system in C rather an assembly? Do I literally just compile the C to assembly and "add it in"?

Thanks,
....
Take a look at :
Info: Raspberry Pi Bare Bones
....
Thanks, I'll definitely take a look. I've now got as far as drawing some basic graphics on the screen, like blocks of pixels!
Thanks, ....
That's pretty much it, yeah.
You *will* need to understand the ARM EABI calling convention if you're calling from assembler code to C or vice versa. And, of course, you'll need to define your called assembler functions within your C code, and vice versa. So, assuming you have an assembler function called putc that puts a character to the current position on the screen and returns nothing, and it's called with the character to output in r0, you'll need to define it as a global in your assembler code (so that the linker knows it's a global name) as follows:
Info: ?

.global putc
.text
.code 32
putc:

....
and then define it in a C header file as follows:
Info: extern void putc (char);
Thanks for the tips tufty. I need as much info as I can get on this project
....
Chapter and verse of the calling convention can be had from:
Info: Application Binary Interface (ABI) for the ARM Architecture


The most important bit for your purposes is the procedure call standard, which for most purposes can be summed up as:


- stack grows downward
- arguments are passed in r0-r3, which should cover 99% of functions. For the others, *do it in C*
- value return in r0 (and, potentially r1-r3)
- called functions *must* save / restore any registers in r4-r11 they overwrite, and restore the stack pointer to where it was on call.
- If you're compiling position independent code (loadable libraries, for example), use of r9 is verboten.



Things get more complex if you're dealing with floating point numbers, my advice would be to do all of that in C and let the compiler deal with it.

By the way, I'm not sure where HermanHermitage's stuff is at WRT C cupport. There was a very experimental llvm back-end in the works, but I don't know where it's at. So for videocore stuff, you're probably still looking at assembler.

Web Sources