Posts: 7
Joined: Fri Sep 15, 2017 7:31 am

Bare metal multi core programming

Fri Sep 15, 2017 7:38 am

I have seen some posts on this topic in this forum itself but could some one please tell me what are the docs which one should go through before starting to do these bare metal multi core programming other sense which docs and the sections in the docs will give me the registers or the way how multiple cores are controlled enabling only two core etc ....
I request to please put a detailed answer as I am novice to this stuff ...

Thank you very much in advance

W. H. Heydt
Posts: 8662
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)

Re: Bare metal multi core programming

Fri Sep 15, 2017 2:37 pm

You may want to start with the Bare Metal sub-forum (Programming --> Bare Metal). There is a sticky labeled "Bare Metal resources", which would appear to be a good start point.

Posts: 783
Joined: Wed Dec 07, 2016 2:29 pm

Re: Bare metal multi core programming

Fri Sep 15, 2017 5:26 pm

We have samples to get the cores into mode to be able to use, not sure they are in the stickies

I have one on my site in C ... /Multicore
David Welch has one (in Assembler) ... er/multi00
Peter Lemon (in Assembler) ... MP/SMPINIT
There are a few others.

We all deal with the basics of parking the cores ready to be tasked for multicore operation. So that part is fairly easy and basically just read the source code it's readily documented what it's all doing. The main thing you will need is the ARM processor you will be using the Cortex-A53 if on a Pi3 or the Cortex-a7 if on a Pi2.

Now the problem is from there it gets far harder and it's a case of hitting the books and learning about multitasking. The subject gets too broad for us to build samples, it's like saying just build an O/S. You need specifics of what you are trying to do, what requirements you want etc to go from there.

User avatar
Posts: 2073
Joined: Wed Aug 28, 2013 3:31 am

Re: Bare metal multi core programming

Sat Sep 16, 2017 1:28 am

If you are a noob you might want an easier way to do multicore.
There is a multicore example here.

I find I can make a baremetal kernel.img application in hours without reading lots of books etc.
Probably the difference with Ultibo is you can use it immediately without having to know ARM assembler.

You could say it is like doing Arduino stuff on Pi's, you have an IDE with libraries and you just write the application.
That way you can avoid the lower level messing about with registers stuff that most baremetalers have to do.
I am not a coder, just a hardware guy who likes an easy way to make code to get the hardware going.
The hardware these days is 32 or even 64bit , sometimes multicore, runs real fast and has lots of memory.

I have pretty much given up trying to learn much more Linux to do everything I want to do on the Pi's.
And I don't think I have much time left to learn everything that comes on Pi SoC's chips.
They have more than 50 ALU's on them, 48 just in the 12 QPU's.

Ultibo gave me a nice way to do stuff on Pi's without an OS, including multicore, multithread, 64bit, NEON but still with enough extras to make it easy to write an single purpose application in hours compared to days and weeks.

It is the difference between learning baremetal and using baremetal, learning multicore or using multicore.
By doing and using Ultibo I learn just a little bit more each time but I also have working gadgets, which keeps the boss happy.
Ultibo is also evolving at a rate I can just about keep up with as new stuff gets figured out and added.

LdB has pointed you to the best of the best baremetal.
One day I may go back and I will have learned enough to understand them :oops:
These Pi's are complex and I don't know if any one person could ever understand them completely.
Especially as some things are still hush hush. For me it is about understanding enough to use them to make stuff work.

One day/month/year I may go and do the baking pi stuff here.

Some people like to build/restore cars, I am now the sort to get in a car and go somewhere, i can put in petrol and oil.
My first car I could fix, it was old and simple. Look under the hood of new cars, hmm, how to change spark plugs, er where are the spark plugs?
That's pretty much what it looks like when you peak into the SoC things that come on Pi pcbs.
One day you are doing 8bit micros with just one datasheet/manual, blink and then everything is 32bits plus the kitchen sink. and a pile of manuals taller than me, if you could get the printed ones.

Now you can use Arduino and Ultibo to do stuff and not even get near a manual ;)
Maybe in 10years RPF will bring out an 8 bit Pi version because people have forgotten how to use them.
Or a FPGA version to roll your own 8,16,24,32...128bit cpu.
Hmm that would be interesting, have not done much FPGAs.
If RPF made FPGA PCBs for $10 I would use them, not sure for what , I will find a reason :lol:
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Posts: 7
Joined: Fri Sep 15, 2017 7:31 am

Re: Bare metal multi core programming

Mon Sep 18, 2017 2:53 pm

Thank you guys I am new to this site and I was not knowing how to search my question .... Finally I got answers and one more thing to ask to you guys . I went to through some git hubs and there I found the mail box things where we write our function address that is to be run by our core number say some x . Where can I find this information regarding those mailboxes ....

Posts: 783
Joined: Wed Dec 07, 2016 2:29 pm

Re: Bare metal multi core programming

Mon Sep 18, 2017 4:38 pm

They are defined by the bootloader stubs
Pi3 AARCH64: ... armstub8.S
Pi2,Pi3 AARCH32: ... armstub7.S

You can actually move them to your own memory address and setup your own scheme if you like. The CPU's are just looping reading that specific memory location and for any value other than zero it jumps to the address and zeros the location behind itself. Both 32/64 bit stubs work by multiplying the Core CPU id by some value and adding it to an offset to arrive at a final address. It's barely 20 lines of assembler code just write out what each line does.

For the 32bit mode It's 0x400000CC, 0x400000DC, 0x400000EC, 0x400000FC (armstub7.S)
For 64bit bode its 0xd8, 0xe0, 0xe8, 0xf0 (armstub8.S)

The addresses were obviously chosen just to be out of the way for the bootload and for the 32bit mode in cache memory. I imagine linux takes control of them and parks them in it's own loop dispatcher.

To make them C safe I had to actually replace the entire bootloader park stub to save registers that C will trash. However I decided to put them back looking at the same address for ease for users, but I could have put them anywhere I liked.

There really isn't anymore to it than that.

All the real work is after that you have 4 cores that can all access the same memory at the same time and you need to make sure they don't by standard multicore procedures.

Return to “Bare metal, Assembly language”

Who is online

Users browsing this forum: No registered users and 3 guests