Go to advanced search

by JS2
Mon Mar 06, 2017 8:06 pm
Forum: Bare metal, Assembly language
Topic: Working with an MMU
Replies: 7
Views: 2793

Re: Working with an MMU

it only gets more difficult with the rpi2 and close to impossible with the rpi3 Is it? My RPI2 code ran almost as-is on the RPI3. The only difference was that the SMP bit was no longer in the ACTLR (whose meaning totally changed even in AArch32) Fixed it with this ; step 3: ACTLR SMP bit ; Signals ...
by JS2
Fri Feb 10, 2017 12:06 am
Forum: Bare metal, Assembly language
Topic: GL Shader State not behaving as expected
Replies: 4
Views: 1104

Re: GL Shader State not behaving as expected

First things first. Your iteration times are so fast compared to mine that I'm kinda jealous. As much as I'd love to use the loader you are using, JayStation2 is more a learning project than anything practical, so I am trying to do as much myself as possible. That means not using other people's stuf...
by JS2
Wed Feb 08, 2017 2:29 pm
Forum: Bare metal, Assembly language
Topic: GL Shader State not behaving as expected
Replies: 4
Views: 1104

Re: GL Shader State not behaving as expected

More than a little. You completely nailed it, I had to read and write each vertex attribute once in the shaders. I feel kind of stupid, because I remembered that *something* had to be read exactly once, and thought it was only for varyings. You, sir, will get some serious thanks in my next blog post...
by JS2
Wed Feb 08, 2017 1:53 am
Forum: Bare metal, Assembly language
Topic: GL Shader State not behaving as expected
Replies: 4
Views: 1104

GL Shader State not behaving as expected

I had vertex shaders working at one point, but seem to have broken them. This makes me feel like they were ever only working by coincidence. I was hoping you guys could sanity check my assumptions Details: I am trying to render a triangle. It works in NV mode but not in GL. Each time I run, I either...
by JS2
Fri Feb 03, 2017 2:47 am
Forum: Bare metal, Assembly language
Topic: Baremetal videocore graphics (GL Shader State)
Replies: 3
Views: 1424

Re: Baremetal videocore graphics (GL Shader State)

curious what the problem in the manual was. I too am doing bare metal graphics and am currently debugging something that sounds suspiciously similar to what you may have been seeing in GL mode
by JS2
Sat Jun 27, 2015 12:08 pm
Forum: Bare metal, Assembly language
Topic: Bare Metal "Hello Framebuffer World"
Replies: 5
Views: 1867

Re: Bare Metal "Hello Framebuffer World"

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. T...
by JS2
Tue Jun 23, 2015 1:05 am
Forum: Bare metal, Assembly language
Topic: Trying Bare Metal on Raspberry Pi 2
Replies: 98
Views: 33018

Re: Trying Bare Metal on Raspberry Pi 2

So its repeated use of same data and instructions. Does that answer Well yes and no. Technically "the same data" could involve multiple threads false sharing cache lines, or the same sparsely located lines knocking existing lines out of cache. However, it seems you fixed the issue which is great. I...
by JS2
Mon Jun 22, 2015 2:17 am
Forum: Bare metal, Assembly language
Topic: Trying Bare Metal on Raspberry Pi 2
Replies: 98
Views: 33018

Re: Trying Bare Metal on Raspberry Pi 2

Can't tell much without seeing the code, but I'm curious 0) how are you measuring performance? 1) what kind of stuff are you doing? Are you more heavy on ALU or memops? 2) how is your L2 set up? Writeback, write through, etc? 3) are you using cache-friendly access patterns? 4) are you talking i$ or ...
by JS2
Tue May 26, 2015 12:10 pm
Forum: Bare metal, Assembly language
Topic: turning on SCU on RPI2
Replies: 10
Views: 1969

Re: turning on SCU on RPI2

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)
by JS2
Mon May 25, 2015 11:24 pm
Forum: Bare metal, Assembly language
Topic: turning on SCU on RPI2
Replies: 10
Views: 1969

Re: turning on SCU on RPI2

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 fi...
by JS2
Fri May 22, 2015 8:48 am
Forum: Bare metal, Assembly language
Topic: turning on SCU on RPI2
Replies: 10
Views: 1969

Re: turning on SCU on RPI2

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 g...
by JS2
Fri May 22, 2015 5:04 am
Forum: Bare metal, Assembly language
Topic: Trying Bare Metal on Raspberry Pi 2
Replies: 98
Views: 33018

Re: Trying Bare Metal on Raspberry Pi 2

Nothing like the embarrassment of asking for help to motivate you to find your own bug. My per-core page table setup was correct, but I had a bug in my atomic spinlock due to a bad mercurial merge. PC wasn't being restored at the end of my lock function, so we were falling off the edge and continuin...
by JS2
Thu May 21, 2015 4:24 am
Forum: Bare metal, Assembly language
Topic: Trying Bare Metal on Raspberry Pi 2
Replies: 98
Views: 33018

Re: Trying Bare Metal on Raspberry Pi 2

I'm not sure so far if the Snoop Control Unit is on by default so that the memory is coherent between the cores without intervention. Anyone make any progress with this? I am seeing behavior that could be the result of coherency problems with different cores sharing the same atomic, and I'm not see...
by JS2
Fri May 15, 2015 12:25 am
Forum: Bare metal, Assembly language
Topic: turning on SCU on RPI2
Replies: 10
Views: 1969

turning on SCU on RPI2

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 exc...

Go to advanced search