Sign in to follow this  
  • entries
    455
  • comments
    639
  • views
    422480

GP2x Memory Management Pt1

Sign in to follow this  
_the_phantom_

84 views

So, I got to 1000 post on a forum, got a 4th star next to my name and learnt how to bootstrap the 940T core of the GP2x.. what did you do with your day?

After looking at a few pdfs and some code by someone else, things finally clicked into place with regards to how you make use of the 940T core.

The process is pretty easy;
- place it in a reset state
- disable the interrupts
- copy across the program code into the memory it will execute
- enable its clock
- set to operational

The trick is in the last step. When a processor comes out of reset they default to fetching their first instruction from a known location, which in this case is adress 0 (zero). However, while the ARM processor might want to execute from that location there is a slight problem, in that the default kernel already exists there, so we cant load our custom code into that location, doh!

However, the GP2x's core chip has a register which controls both the operational state AND allows you to add a value to the upper 8bits of the addresses the 940T core sends out, which means that you can select which bank of memory is uses as its effective zero address.

The example code I have sets this value to 0x03, or the 4th block of 16, from 48meg to 64meg. So, to make this work we need to load our code at physical address 0x0300 0000, then when the processor comes out of reset state it will start executing our code.

Now, in the memory maps I've seen, that address is already used by some code, namely the hardware decoder controlling code, and it turns out the software cant reload that code once its been over written (start DivX, watch, exit, run dual core test, exit, restart DivX and it hangs).

Techncially speaking, it would be possible to save it out that code and place it back in once done, but I dont overly like that solution as the code size can change. For testing reasons however this isnt a problem as I'm restarting loads anyways [grin]

So, more progress has been had, I'm not pretty confident I can make my own code go.

This ofcourse leads us to the memory management issue, I've decided I'm going to introduce 2 more frames of memory to cover the upper section, this probably wont get a huge amount of use, the lower section would be for the 2nd core (code, communications buffer between it and the main core) and the upper section for frame buffers. This means that I can load and unload sounds and textures without worrying about stomping on the CPU code and should simplify things internally as well.

Eventually I'm going to have to dump this mini-lib I've been using however, while its nice the fact that I'm starting to take over so much memory management on my own and departing from its way of doing things is starting to make it a must. It was always going to happen, so maybe now is better than later.

So, some sucess today, tomorrow I should really work on an assignment so I might have to back burner this for a few days or until I get bored writing the report [grin]

Next tasks;
- add two extra frames to memory manager
- work out what we want the 940T todo
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now