GP2X Why Only 32mb Of Ram Under Linux?

[Titousensei]

Can somebody please explain the technical reasons why we only see 32MB under linux?

- What is the other 32B for?
- Is it used by the 2nd CPU?
- Is it mapped in /dev/mem but inaccessble by malloc in linux userspace?
- Is it possible to use part of it as a ramdisk?

Thanks.

 

[reallynotnick]

I am no dev. but I pretty sure it splits it 32mb for linux, 16mb for the first proccesor and then there is 16mb left over that you can use with the 2nd processor.

Don't take my word for it though.

 

[mittens]

First of all,

GP2X has 64M internal RAM, you can take it as a RAM memory of your PC
and it has 64M another NAND memory as a storage, like your hard disk driver.

After boot-up, the linux system is loaded on the NAND memory (again, your HDD)
and the remain size of NAND memory is under 32M.

So, you can still use 64M RAM, but only under 32M of insternal storage space.

Hell, but nobody want to screw their storage with some crappy files when they have 1Gb SD card.

 

[Titousensei]

I guess I should I explained myself better. I'm not talking about the nand memory here. There's a 64MB chip of RAM in the GP2X. Under linux we only have 32MB available: dmesg prints this:

Memory: 32MB = 32MB total
Memory: 30208KB available (1088K code, 751K data, 280K init)
...
Freeing init memory: 280K

This is consitant with what the free command prints:

             total         used         free       shared      buffers
  Mem:       30488        17460        13028            0          196
 Swap:           0            0            0
Total:      30488        17460        13028

30208KB+280KB=30488KB -> 29.5MB

17MB used, 12.5MB free.

How do we access the 2nd page of 32MB?

AFAIK, linux runs on the 1st CPU only. I've read somewhere that the 2nd CPU is only used when playing video for now, and that you need to map his code to some higher address.

- Is the 2nd CPU using the entire 2nd page of 32MB and the 1st CPU uses the entire 1st page of 32MB?
- Is the 32MB limit of addressable user space RAM a software limit imposed by Linux or a hardware limit?

This is a developer's forum, so please only post facts and educated guesses.

Thanks.

 

[Vimacs]

http://www.gp32x.de/board/index.php?showtopic=22532&hl=

 

[Titousensei]

http://www.gp32x.de/board/index.php?showtopic=22532&hl=

​

I've seen this topic. It's related to my question because it's about the possibility of using the upper 32MB to transfer data to the 2nd processor.

What I'm asking is actualy the opposite: what part of the upper 32MB is NOT reserved by the 2nd CPU and how to we map it to something useful in userspace?

 

[Vimacs]

its writen there... the upper 16mb are totaly unused.

 

[Titousensei]

its writen there... the upper 16mb are totaly unused.

​

Well, kind-of. Here's what it says:

You can, but the second processor's code and data is stored in the lower 16mb of the upper 32mb, so if you overwrite that, you'll crash the processor. (Actually, there's 1mb of code, and 16mb of data).

Is it the lower 16MB, or 1+16=17MB? Where does this information come from? I'm browsing through the pdfs I have and it's basically said that both processors can access the entire 32bits memory space. I didn't find anything yet about having the lower 32MB protected by linux and the upper for the 2nd CPU. Actually, I haven't found anything about memory access conflicts. If you have more references can you please share?

Thanks

 

[Squidge]

Lower 32MB is for Linux
Upper 32MB is split up as follows:

0x03000000 - 0x03FFFFFF (Physical address) = Video decoding as follows:

0x03000000 Video decoding firmware (currently 342812 bytes, but may change in size with various firmware releases)
0x03101000 Primary frame buffer (153600 bytes)
0x03381000 Secondary frame buffer (153600 bytes)
0x03D00000 ~ 0x03FFFFFF is reserved for internal buffers of MPEG H/W decoder.

Rest is unused as far as we know - not been tested though.

You can access the upper memory, and trample over the reserved addresses by using mmap() system call to place this memory into your virtual address space. You can use multiple calls if you want to further split the memory. It's recommended that you place the second processor into reset however if you decide to trample over the reserved addresses.

Note that, although unlikely, the above values may change on newer firmware.

 

[slygamer]

Lower 32MB is for Linux
Upper 32MB is split up as follows:

0x03000000 - 0x03FFFFFF (Physical address) = Video decoding as follows:

0x03000000 Video decoding firmware (currently 342812 bytes, but may change in size with various firmware releases)
0x03101000 Primary frame buffer
0x03??????? I forget where the secondary frame buffer is.
0x03D00000 ~ 0x03FFFFFF is reserved for internal buffers of MPEG H/W decoder.

Rest is unused as far as we know - not been tested though.

You can access the upper memory, and trample over the reserved addresses by using mmap() system call to place this memory into your virtual address space. You can use multiple calls if you want to further split the memory. It's recommended that you place the second processor into reset however if you decide to trample over the reserved addresses.

​

This information is great to know. I'm posting it to the wiki so it doesn't get lost.

 

[Squidge]

Updated upper 32MB memory map (see above).

 

[Titousensei]

Updated upper 32MB memory map (see above).

​

Thanks Squidge, that's great information.