GP2X Access To Hardware.

[MadDog]

Re: My 3d engine.

I've got a 'c' version of my software renderer on the PC going, running on two seperate threads to simulate the two CPU's of the gp2x. I'm doing this for two reasons, speed of development and easy testing of API ideas.

Now, i'm still in my prof of concept stage. (been delayed as i've started a new job, but now have more time on my hands) The first part is done, now i'm ready to move to the next stage. Getting down and dirty with the hardware. I've read the docs and have had previous experiance coding this low. But i've got little Linux experiance so when I tried to mess with the HW regs as expected linux told me off and shut the app down.

After searching the best I came up with was something about a needing a 'driver' that will kill of the OS and give me the system in an 'virgin' state. IE the MMU turned off and no TLB. From there i'll be able to config the mem and move to my prototype stage of the project.

The idea is to have a system with one chunk of memory + reserved 'protected' bits used by my virtual GPU. ( the 940 chip ) A few peaple have ditched the chip for its low cache but I think its top. As its got no MMU you don't get the cache miss cost when a TLB misses the cache. Also rendering tends to be data in data out process. So the small cache size to me does not seem an issue. ( but then I could be wrong )

 

[Vimacs]

you want rob's sdk2x, it isnt realy ready jet through (no fs).
http://www.cobbleware.com/files/sdk2x_191205d.tar.gz should be the latest version.
His "trampoline" should be exactly what you want.

 

[Dzz]

The idea is to have a system with one chunk of memory + reserved 'protected' bits used by my virtual GPU. ( the 940 chip )

If you can describe your needs in a bit more detail, we might be able to figure out how to get this to work in the usual environment. For example, which registers do you want to access, and what specific goals are you trying to achieve by doing so?

Or, if you're a man of action instead of words, check out the thing that Vimacs referred to!

 

[Squidge]

A few peaple have ditched the chip for its low cache but I think its top. As its got no MMU you don't get the cache miss cost when a TLB misses the cache.

Actually you get the cache miss penalty on every memory access unless you enable the cache by turning on the MPU (which is a kind of cut down MMU), and which in that case you just get the normal cache miss cost.

Same goes with the 920, without the MMU enabled, memory access can be very slow, as the caches are usually disabled too.

However, lots of hardware can be accessed from under Linux, so my advice would be to stick with that as it's a far more friendlier atmosphere than killing everything and going for a blank slate. You just have to be a little more friendlier to Linux, and it'll be able to help you along. I'm assuming for example that your trying to access hardware registers directly? Try mapping them into your process space first with mmap if this is the case.

 

[MadDog]

you want rob's sdk2x, it isnt realy ready jet through (no fs).
http://www.cobbleware.com/files/sdk2x_191205d.tar.gz should be the latest version.
His "trampoline" should be exactly what you want.

Thanks i'll take a look tomorrow, might be something in there I could use, a bit drunk at the mo, just got back from a friends wine evening.

 

[MadDog]

A few peaple have ditched the chip for its low cache but I think its top. As its got no MMU you don't get the cache miss cost when a TLB misses the cache.

Actually you get the cache miss penalty on every memory access unless you enable the cache by turning on the MPU (which is a kind of cut down MMU), and which in that case you just get the normal cache miss cost.

Same goes with the 920, without the MMU enabled, memory access can be very slow, as the caches are usually disabled too.

However, lots of hardware can be accessed from under Linux, so my advice would be to stick with that as it's a far more friendlier atmosphere than killing everything and going for a blank slate. You just have to be a little more friendlier to Linux, and it'll be able to help you along. I'm assuming for example that your trying to access hardware registers directly? Try mapping them into your process space first with mmap if this is the case.

From what I understand of the 940 docs, the data for the memory protection unit is on chip. So yes, if you don't turn it on then no cache, goes without saying. But when its all setup then the memory access does not requre a read of a TLB. From memory the 920 can hold 64 entrys on chip, the rest in system ram. So if your jumping around in ram, as you do with linked lists, then there is a chance that your miss the 'cached' TLB entrys and have go to main ram for it. This is my understanding of how it works, but i've only read the docs a bit, can not say I really know it till i've used it. But its very simular to the MMU's on other processors. All the above is of cause effected by what page sizes Linux is using. The bigger the pages the better for TLB hits, but means wasted memory. (for the low level allocator, not the heap allocator).

This is an issue the next gen consoles have. ( 360 and PS3 ) They have so much memory that using thier default 4k page sizes quickly mean that you start thrashing the TLB cache. (500 cycle wait on main ram for both systems!) But then this is NDA type info.

 

[Squidge]

Heh, yeah... If you just map the main memory into 64 1mb sections (instead of 4KB pages) you should be able to have a pretty efficient system, but of course Linux doesn't work then...

The 940 has a MPU instead of a MMU, and thus can't use virtual memory, and thus no TLB...

 

[synkro]

This is an issue the next gen consoles have. ( 360 and PS3 ) They have so much memory that using thier default 4k page sizes quickly mean that you start thrashing the TLB cache. (500 cycle wait on main ram for both systems!) But then this is NDA type info.

I don't get the TLB issue. A cache miss is the thing that should concern you the most. No matter if they have a TLB for hit-under-miss or a TLB for virtual addressing. The ARM cache is 64-way Round Robin wich is pretty much the best thing you can get on a low power embedded CPU. As long try to walk through mem in small strides you have no problems. And w/o virtual addressing accessing mem in a cache friendly manner is easy.

Even though it is off topic I doubt TLB thrashing an issue on the PS3. The CELL is no cache but a local store archiecture. The issue there is to double buffer data in mem an reduce stall time of the SPU's as only 3 can access the the ring mem bus at once.

 

[MadDog]

This is an issue the next gen consoles have. ( 360 and PS3 ) They have so much memory that using thier default 4k page sizes quickly mean that you start thrashing the TLB cache. (500 cycle wait on main ram for both systems!) But then this is NDA type info.

I don't get the TLB issue. A cache miss is the thing that should concern you the most. No matter if they have a TLB for hit-under-miss or a TLB for virtual addressing. The ARM cache is 64-way Round Robin wich is pretty much the best thing you can get on a low power embedded CPU. As long try to walk through mem in small strides you have no problems. And w/o virtual addressing accessing mem in a cache friendly manner is easy.

Even though it is off topic I doubt TLB thrashing an issue on the PS3. The CELL is no cache but a local store archiecture. The issue there is to double buffer data in mem an reduce stall time of the SPU's as only 3 can access the the ring mem bus at once.

Yer, your right, but I was talking about access to the main ram and not the embedded ram.
Intresting nuget, PS3 now only has six SPU's for the developers to use, there are eight on chip. One is used for DRM and the other is spare to increase the yield. ( Yet, bit of topic, but I don't care, its all very cool! )

Heh, yeah... If you just map the main memory into 64 1mb sections (instead of 4KB pages) you should be able to have a pretty efficient system, but of course Linux doesn't work then...

The 940 has a MPU instead of a MMU, and thus can't use virtual memory, and thus no TLB...

This could be where my plan will fall down. Dumping Linux is making a lot of work for my self as i'll have to supply all the required services. But thats why the gp2x is so cool, we're not blocked from doing what we want. Its up to us to see if its the right way.

( Got to keep one eye on the next demo comp )