GP2X Upper Memory


bobvodka

Still Fresh
Joined
Jan 22, 2006
Messages
7
A while ago I started playing with the uncontrolled upper 32meg of RAM we have access to, mostly so I could feed "real" addresses to the 2D blitter.

Initally my experiaments have been restricted to the lower 16meg of this 32, which afaik is utterly unused, however I'd like to make use of the upper 16meg as well.

I've got a very basic memory manager backend in place (a simple frame allocator, which imo is perfect for games and the resources it'll be managing), however there is one little little problem.

While it appears I can stomp all over memory as much as I like if I stomp on the section which holds the code to controll the hardware video decoding (based at the start of the upper 16meg) then ofcourse hardware decoding no longer works.

So, I was wondering, does anyone know how to work out the size of the code region I shouldnt stomp on (so I can place a 'hole' in my memory controller system) or a way to force the GP2x to reload the decoder into that memory (without forcing a restart?).

A contiguous area of ram would be much prefered to having to work around a hole, but thats do able if I knew how large I had to avoid.
 
you could just copy the upper 16mb to a file prior to trampeling over it and copy it back on exit, how does that sound?
 
yeah, the idea of taking a memory dump from the start of that ram upto the framebuffer did occur to me, but I dunno, I feel a bit 'iffy' about trying todo that, as I'd hope to use this code in stuff released and for others, so requiring your user has X space left on a memory card just seems off to me..

that said, with 1gig SD cards being so cheap these days maybe I should take that route..
 
The code that is placed in the upper 16mb is included in the linux kernel source code as a binary array in the form of a .h file, so you could just include this with your game and restore it when you exit. No need to back anything up.

Or, you could just either miss 2mb of this, or save this 2mb somewhere. I forget the actual size and location but it's on the Wiki and it's less than 2mb.

EDIT: Hmm, I seem to recall it being at 0x03000000, but don't forget the display frame buffers are up there too!
 
Dzz posted on Mar 22 2006 at 09:01 PM said:
Just stomp on the memory.  Who cares?

Well, I consider it a matter of politeness to leave the system in a state where if the user wanted to there could go and watch something afterwards, maybe I'm just old fashioned? *shrugs*

Squidge posted on Mar 22 2006 at 09:06 PM said:
The code that is placed in the upper 16mb is included in the linux kernel source code as a binary array in the form of a .h file, so you could just include this with your game and restore it when you exit. No need to back anything up.

Or, you could just either miss 2mb of this, or save this 2mb somewhere. I forget the actual size and location but it's on the Wiki and it's less than 2mb.

EDIT: Hmm, I seem to recall it being at 0x03000000, but don't forget the display frame buffers are up there too

Ah, thats one option for sure, but given its only 2meg then maybe moving into the lower 32meg would be a better plan, as I would guess the large assets (sound and gfx) are going to all live in that higher memory region, so that means I shouldnt run short lower down.

Yeah, I know about the display framebuffers being up there, I've already stomped over that memory space to no ill effects so I'm not too worried about it. Part of the allocated frame memory will be for the frame buffers as well.

Cheers :)
 
Last edited by a moderator:
If it was 15 megs of memory it's kind of a tossup whether it's more "polite" to require them to reset their machine before using the video decoder or to spend longer than the reboot time dumping and loading 15 megs of data onto an SD card.

If it really is just 2 mb starting at 3000000 then copying it elsewhere and restoring it is definitely more polite.

Note that the only practical way to use the second processor is to put its code at 3000000 so whatever solution is decided upon should be done by all applications using the 940t, so coming up with a robust good answer will be very helpful for lots of us.
 
Dzz posted on Mar 22 2006 at 03:31 PM said:
If it was 15 megs of memory it's kind of a tossup whether it's more "polite" to require them to reset their machine before using the video decoder or to spend longer than the reboot time dumping and loading 15 megs of data onto an SD card.

If it really is just 2 mb starting at 3000000 then copying it elsewhere and restoring it is definitely more polite.

Note that the only practical way to use the second processor is to put its code at 3000000 so whatever solution is decided upon should be done by all applications using the 940t, so coming up with a robust good answer will be very helpful for lots of us.
According to the Wiki, the amount used for firmware at 0x3000000 is only a little more than 300k. Saving 1 meg should be enough then (even if the firmware bloats out a lot).
 
Last edited by a moderator:
From memory,
Code:
0x200 0000 -> 0x2FF FFFF (16MB)  is the buffer for video decoding,
0x300 0000 -> 0x30F FFFF (1MB)   is the 940's code
0x310 0000 -> 0x337 FFFF (2.5MB) is framebuffer 0
0x338 0000 -> 0x35F FFFF (2.5MB) is framebuffer 1
0x360 0000 -> 0x367 FFFF (0.5MB) is the sound buffer
0x368 0000 -> 0x36F FFFF (0.5MB) seems to be unallocated (maybe overflow for sound)
0x370 0000 -> 0x39F FFFF (3MB)   is for 3x 1MB YUV (video layers)
0x3A0 0000 -> 0x3FF FFFF (6MB)   looks to be free
I'm not sure how the 940 is set wrt where the interrupt vectors, mpu table and stack are located.
Edit:
Looking at the 940 docs, the mpu table is in hardware so doesn't take any ram.
The vectors have to be at either 0x0000 0000 or 0xFFFF 0000, so I'd assume they'll be left at the start of memory (0x200 0000). Not sure how many there are but I assume no more than 4K of memory.
 
Really extrange, because i use 0x3000000-0x3ffffff without problems.
If i use 0x2000000-0x2ffffff my program gets locked... :(
 
theoddbot posted on Mar 23 2006 at 01:31 AM said:
Paeryn: If the 940t base register is set to 0x300 0000, what use are the video decoding buffers below this. Are they repeated at some other memory location?
I assumed since 0x200 0000 is 32MB...
Just checked - you're right, it's set to 3. I'll run some more tests and see if I can get clean access to that spare 16MB.
It may be that it is accessable, just because the 940 is set to treat 0x300 0000 as base, the hardware (dma, display, blitter, etc) isn't affected. It may well be used by the video hw to store video data for decoding.
 
Last edited by a moderator:
Franxis posted on Mar 23 2006 at 11:11 AM said:
Really extrange, because i use 0x3000000-0x3ffffff without problems.
If i use 0x2000000-0x2ffffff my program gets locked... :(
From memory, I think I'm using the 16MB from 0x02000000 to 0x02FFFFFF without any problems so far.
 
Last edited by a moderator:
I just re-compiled SDL to use 0x200 0000 as its base address instead of 0x310 1000, absolutely no problems.
It definately is being used by the video hw... I've just had my test app running at the same time as playing video. With the framebuffer at 0x200 0000 there's a lot of data being copied onto it while the video plays.
Oh - and it locked up after about 10 seconds ;-)
 
slygamer posted on Mar 23 2006 at 04:03 AM said:
Franxis posted on Mar 23 2006 at 11:11 AM said:
Really extrange, because i use 0x3000000-0x3ffffff without problems.
If i use 0x2000000-0x2ffffff my program gets locked... :(
From memory, I think I'm using the 16MB from 0x02000000 to 0x02FFFFFF without any problems so far.
Same here. If I use 0x3000000-0x3ffffff, I got some odd error, but no problem with 0x02000000 to 0x02FFFFFF.
 
Last edited by a moderator:
The 940 can access the full 64MB of RAM regardless of the starting address. The interrupt table starts at the beginning of the code memory (eg. 0x03000000) and is 32-bytes in length. The MPU table is all in hardware, so takes up no RAM.

Also, 0x03D00000 ~ 0x03FFFFFF is reserved for internal buffers of MPEG H/W decoder.
 
pepone posted on Mar 23 2006 at 06:35 AM said:
slygamer posted on Mar 23 2006 at 04:03 AM said:
Franxis posted on Mar 23 2006 at 11:11 AM said:
Really extrange, because i use 0x3000000-0x3ffffff without problems.
If i use 0x2000000-0x2ffffff my program gets locked... :(
From memory, I think I'm using the 16MB from 0x02000000 to 0x02FFFFFF without any problems so far.
Same here. If I use 0x3000000-0x3ffffff, I got some odd error, but no problem with 0x02000000 to 0x02FFFFFF.

Aaaarrrgh, then it is not te same, it is the opposite than me :blink:

I use 0x3000000-0x3ffffff and you use 0x2000000-0x2ffffff

Really extrange :eek:
 
Last edited by a moderator:
just a quick copy and paste from arm-asm book

2.1 Memory and addressing chapter

http://www.peter-cockerell.net/aalp/html/frames.html

When an ARM-based system uses MEMC, its memory map is divided into three main areas. The bottom half - 32M bytes - is called logical RAM, and is the memory that most programs 'see' when they are executing. The next 16M bytes is allocated to physical RAM. This area is only visible to system programs which use the CPU in a special mode called supervisor mode. Finally, the top 16M bytes is occupied by ROM and I/O devices
 
evol posted on Mar 25 2006 at 12:59 AM said:
just a quick copy and paste from arm-asm book

2.1 Memory and addressing chapter

http://www.peter-cockerell.net/aalp/html/frames.html

When an ARM-based system uses MEMC, its memory map is divided into three main areas. The bottom half - 32M bytes - is called logical RAM, and is the memory that most programs 'see' when they are executing. The next 16M bytes is allocated to physical RAM. This area is only visible to system programs which use the CPU in a special mode called supervisor mode. Finally, the top 16M bytes is occupied by ROM and I/O devices
That's a bit out-dated, probably dates back to ARMv2 or earlier. The GP2X's processors are based on ARMv4. The 920 has a full MMU, the 940 only has an MPU. They both use full 32-bit addressing which was introduced in ARMv3.
 
Last edited by a moderator:
Back
Top