uhrheber
Posts: 4
Joined: Thu Mar 05, 2015 10:08 am

Running bare metal code on only one core?

Thu Mar 05, 2015 10:15 am

Hi.
Can I run bare metal code on only one core, and Linux on the other three?
Background: I want to use one core for realtime bit banging the I/Os.
Example applications would be:
- driving multiple WS2812 strings
- high speed logic analyzer
- high speed arbitrary waveform generator
- reading high speed ADCs (for GnuRadio)

So the one core would just transfer data from I/O to memory and convert it on the way.
I can do this with a Beaglebone and it's PRUs, but can it also be done with a Raspi 2?

mimi123
Posts: 583
Joined: Thu Aug 22, 2013 3:32 pm

Re: Running bare metal code on only one core?

Fri Mar 06, 2015 5:27 pm

uhrheber wrote:Hi.
Can I run bare metal code on only one core, and Linux on the other three?
Background: I want to use one core for realtime bit banging the I/Os.
Example applications would be:
- driving multiple WS2812 strings
- high speed logic analyzer
- high speed arbitrary waveform generator
- reading high speed ADCs (for GnuRadio)

So the one core would just transfer data from I/O to memory and convert it on the way.
I can do this with a Beaglebone and it's PRUs, but can it also be done with a Raspi 2?
It depends if Linux supports that but I did it on Plan9 and RISC OS(as they leave the slave cores for other uses)

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

Re: Running bare metal code on only one core?

Fri Mar 06, 2015 6:08 pm

Should be doable by making/finding a bootloader for this. You then let the bootloader inform linux about only the 3 spare cores and the subsection of RAM you want to allocate for linux, keeping the rest for baremetal. Note though that you cannot share devices with Linux so you need to decide where each device resides

ronyoung1
Posts: 6
Joined: Fri Oct 11, 2013 6:37 am

Re: Running bare metal code on only one core?

Fri Mar 06, 2015 6:16 pm

JacobL wrote:Note though that you cannot share devices with Linux so you need to decide where each device resides
One possible approach for this would be to have a server process on the linux side that has a shared
memory segment that is shared with the bare metal core... The linux side could handle all of the I/O and it would look like memory mapped devices/buffers (mailboxes??) on the bare metal side.

mimi123
Posts: 583
Joined: Thu Aug 22, 2013 3:32 pm

Re: Running bare metal code on only one core?

Fri Mar 06, 2015 6:19 pm

ronyoung1 wrote:
JacobL wrote:Note though that you cannot share devices with Linux so you need to decide where each device resides
One possible approach for this would be to have a server process on the linux side that has a shared
memory segment that is shared with the bare metal core... The linux side could handle all of the I/O and it would look like memory mapped devices/buffers (mailboxes??) on the bare metal side.
Can you run code VideoCore-side or you imperatively need an ARM core?
I think you can make Linux ignore one core and just setting up the address for that core

ronyoung1
Posts: 6
Joined: Fri Oct 11, 2013 6:37 am

Re: Running bare metal code on only one core?

Fri Mar 06, 2015 8:10 pm

mimi123 wrote:Can you run code VideoCore-side or you imperatively need an ARM core?
I think you can make Linux ignore one core and just setting up the address for that core
I'm not sure. I haven't actually tried any of this yet. I'm still doing research and trying things. My last experiment last night was to try and disable a core from linux using the following:

echo 0 > /sys/devices/system/cpu3/online

It did not go well... locked up the system with blank screen requiring power cycle. maybe the
maxcpus= argument on boot will work, but it would be nice to be able to disable/enable cores on an active system. Maybe some combination of disabling cores with mailbox writes and linux (might have to migrate processes off of core before mailbox write to disable?)

cleverca22
Posts: 331
Joined: Sat Aug 18, 2012 2:33 pm

Re: Running bare metal code on only one core?

Mon Mar 09, 2015 12:35 pm

i think it would be much simpler to just use a custom kernel driver to run a chunk of baremetal code in linux's kernel space and maybe turn off preemption on that core
so whatever program ran your custom ioctl on the custom device, will basically hijack an entire core until your job is done running

from a normal app viewpoint, the ioctl takes a long time to complete and one core is pegged at 100% system cpu usage

Return to “Bare metal, Assembly language”