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

turning on SCU on RPI2

Fri May 15, 2015 12:25 am

I have the MMU set up, SMP bit set to 1, and cache turned on with memory mapped as normal shared write-allocate write-back. The cores seem to be able to see each other's writes so I assume coherency is likely working. However my atomic spinlock seems to be broken. Each individual core can get an exclusive lock and strex successfully, but its like each core is only seeing its own copy in L1

Did a little research and found this:
http://infocenter.arm.com/help/index.js ... a8404.html

I'm probably just reading this wrong, but it seems to imply I need the SCU for atomics to work in my case. I found the SCU control and configuration register offsets from PERIPHBASE, and then tried to get the PERIPHBASE address with

Code: Select all

mrc p15, 4, r1, c15, c0, 0
but the address always comes back as zero.

So, my questions are:
0) am I really on the right track, or should the SCU not be needed?
1) PERIPHBASE is the reset value. Should it be zero and do I need to set it somewhere else?
2) is there anything else I may have missed in getting ldrex and strex to work across multiple cores

The other possibility is that I messed up something silly in my setup somewhere and atomic should work fine from normal shared cached regions without the SCU

dwelch67
Posts: 955
Joined: Sat May 26, 2012 5:32 pm

Re: turning on SCU on RPI2

Fri May 22, 2015 3:50 am

well, you could say that by definition ldrex/strex is insuring that that core has exclusive access to that address...for those accesses or for that period of time. And obviously if either evicts then you have a problem at one of the next layers when they collide.

Both L1 and L2 are going to properly handle exclusive accesses within themselves as that is ARM written logic. Not sure if there is an L2 on the rpi2 and not sure if the cores share it or each have their own (do they have their own L1 each or share?) But to insure you are doing exclusive access beyond L2 each time you need to use the mmu to mark the space as not cacheable and then strex/ldrex in that space. That puts you at the mercy of the chip vendor and not arm as to whether or not they actually implemented the exclusive access, ignored it and return OKAY instead of EXOKAY or ignore it and just return EXOKAY. the rpi1 did return EXOKAY being uniprocessor that is all you really have to do to make most folks code run, one might like it to make sure it was exclusive against gpu or other accesses but at least they didnt have the bug (arguable) of returning OKAY.

This is an interesting topic that I would like to explore. I did break down and buy an rpi2, and need to either read some other posts or docs or whatever, I dont yet know how to spin up the multiple cores with their own code, once educated on that then can play with this exclusive access topic. Or maybe you can just tell us what you find if you get there first.

David

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

Re: turning on SCU on RPI2

Fri May 22, 2015 8:48 am

I have everything working now. I think the L2 in the RPI2 is on-chip and considered inner domain, so the problem I was having is not what I thought it was. By the way, as an FYI, it turns it that exclusive atomics only seem to work from cached memory. Setting a page as uncached means you can never get a lock on a line

As far as spinning up the cores, this is how I am doing it

Code: Select all

// multicore stuff. Temporary until kernel_old gets set to 1
.equ CORE_1_LAUNCH_ADDRESS, 0x4000008C + (0x10 * 1)
.equ CORE_2_LAUNCH_ADDRESS, 0x4000008C + (0x10 * 2)
.equ CORE_3_LAUNCH_ADDRESS, 0x4000008C + (0x10 * 3)

// start up cores 1, 2, 3
mov32 r1, js2osCoreIdleFunc

mov32 r0, CORE_1_LAUNCH_ADDRESS
str r1, [r0]
mov32 r0, CORE_2_LAUNCH_ADDRESS
str r1, [r0]
mov32 r0, CORE_3_LAUNCH_ADDRESS
str r1, [r0]
Each core then does its init. I'm still super early in my project, but the full source is here in case you are interested
https://bitbucket.org/okonomiyonda/jaystation2_public/
with the (occasionally updated) blog at jaystation2.maisonikkoku.com
Yes, the blog is far behind the actual project, unfortunately

dwelch67
Posts: 955
Joined: Sat May 26, 2012 5:32 pm

Re: turning on SCU on RPI2

Fri May 22, 2015 7:34 pm

where did you find the info on how to do that? at that address space are you talking to the gpu, a mailbox or something to have the gpu do it?

dwelch67
Posts: 955
Joined: Sat May 26, 2012 5:32 pm

Re: turning on SCU on RPI2

Mon May 25, 2015 3:52 am

Thanks! is that documented anywhere?

https://github.com/dwelch67/raspberrypi multi00 example is a very simple demonstration of the four cores running.

Looking at arm docs it appears that each core has an L1, then they share L2 (if there is one).

David

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

Re: turning on SCU on RPI2

Mon May 25, 2015 11:24 pm

Correct, each core has its own L1 and all four share an L2. Unlike the RPI1, the L2 is not shared with the GPU. Although its not explicitly stated anywhere, I have the feeling that the L2 is considered inner domain

As for the address starting up the cores, its not documented anywhere that I could find. There are actually a number of undocumented things about this chip, and I wish there was more available info/docs.

I'm attaching the L2 info I am querying. Sorry its an image, but I can't find a good terminal that allows copy/paste
Attachments
rpi2_info.png
rpi2_info.png (57.86 KiB) Viewed 1814 times

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: turning on SCU on RPI2

Tue May 26, 2015 5:52 am

JS2 wrote:I can't find a good terminal that allows copy/paste
If you have access to a *n*x machine or VM, use screen. On Windows, PuTTY should be able to do what you want.

rst
Posts: 404
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: turning on SCU on RPI2

Tue May 26, 2015 11:12 am

dwelch67 wrote:where did you find the info on how to do that? at that address space are you talking to the gpu, a mailbox or something to have the gpu do it?
It's a mailbox. I think the original source for this info was this posting by dom. If you analyze the referenced code you will find the cores 1..3 continously reading these mailboxes. There are different addresses for "set" and "read/clear" the mailboxes. Additional info can be found here.

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

Re: turning on SCU on RPI2

Tue May 26, 2015 12:10 pm

Sorry, totally ignored the important part of your question. Like rst said, its from a combination of the broadcom pdf and a healthy dose of WWLD (what would Linux Do)

dwelch67
Posts: 955
Joined: Sat May 26, 2012 5:32 pm

Re: turning on SCU on RPI2

Tue May 26, 2015 3:26 pm

I had seen that QA7 document, it just said up to programmer... so I figured that either culled from linux or someone hacked it or someone from rpi or bcm shared info.

The arm docs either TRM or ARM show that each core has an L1. And the L2 is common if present, from my own chip knowledge of other arm cores the L2 we have/had was a separate core you bought and glued on, so I assumed the model would be similar. (or the chip folks could make their own if they feel the desire, generally easier to just buy the ip from arm since you bought the core from them too).

apparently something in the mmu changed as my mmu code doesnt work as is (with the 0x20 to 0x3f address change). so I have to dig into that (Before I can try ldrex/strex). Didnt spend too much time over the long weekend on it though...just did the multi core boot thing.

kriss
Posts: 66
Joined: Thu Apr 02, 2015 8:53 pm
Location: france for now ...

Re: turning on SCU on RPI2

Thu Jun 04, 2015 8:51 am

from the small reading of VideoCoreIV-AG100-R.pdf found on vc4asm site the gpu can access l2
also it wrote that it is a 2xcore
i hope to be enable to change the arm emulation by the gpu on init to have more of the 37 arm registers per core usable ...

Return to “Bare metal, Assembly language”