GP32 Upper Memory Workaround ?


evol

Member
Joined
Feb 12, 2006
Messages
382
as we all know the kernel cant allocate the full 64mb of availible memory on the gp2x

i was wondering if we couldnt create a ramdisk of the upper memory and mount it as swap as the *nix kernels is fairly good att utilise swaps

in that way the memory atleast would be put to good use

and i know that the mounted swap would be slower than accesed lower 32mb but it would be a rocket fast swap file/partition

the benefit would be that the kernel could drop unused mem into swap when full

and the drawback is that its only a substitute for fully acessed memory

(atleast until sourcecode becomes open but this thread will not dig in to that part !!!)

so i would like to hear practical/technical NO/YES arguments for this aproach


cheers
 
evol posted on Feb 14 2006 at 08:01 AM said:
as we all know the kernel cant allocate the full 64mb of availible memory on the gp2x

i was wondering if we couldnt create a ramdisk of the upper memory and mount it as swap as the *nix kernels is fairly good att utilise swaps

in that way the memory atleast would be put to good use

and i know that the mounted swap would be slower than accesed lower 32mb but it would be a rocket fast swap file/partition

the benefit would be that the kernel could drop unused mem into swap when full

and the drawback is that its only a substitute for fully acessed memory

(atleast until sourcecode becomes open but this thread will not dig in to that part !!!)

so i would like to hear practical/technical NO/YES arguments for this aproach


cheers
The kernel doesn't know anything about the upper 32MB of RAM, so how is it going to use it as swap?

This is a bad idea because apps currently use the upper 32MB for video memory. If the kernel is using it for swap, these apps will happily overwrite it. Hardware accelerated SDL does this.

The sooner we ditch Linux and our apps can use the full 64MB as a flat memory model, the sooner these insane ideas about making the GP2X into a fully-fledged Linux PC can be dropped.
 
Last edited by a moderator:
slygamer posted on Feb 14 2006 at 01:57 AM said:
evol posted on Feb 14 2006 at 08:01 AM said:
as we all know the kernel cant allocate the full 64mb of availible memory on the gp2x

i was wondering if we couldnt create a ramdisk of the upper memory and mount it as swap as the *nix kernels is fairly good att utilise swaps

in that way the memory atleast would be put to good use

and i know that the mounted swap would be slower than accesed lower 32mb but it would be a rocket fast swap file/partition

the benefit would be that the kernel could drop unused mem into swap when full

and the drawback is that its only a substitute for fully acessed memory

(atleast until sourcecode becomes open but this thread will not dig in to that part !!!)

so i would like to hear practical/technical NO/YES arguments for this aproach


cheers
The kernel doesn't know anything about the upper 32MB of RAM, so how is it going to use it as swap?

This is a bad idea because apps currently use the upper 32MB for video memory. If the kernel is using it for swap, these apps will happily overwrite it. Hardware accelerated SDL does this.

The sooner we ditch Linux and our apps can use the full 64MB as a flat memory model, the sooner these insane ideas about making the GP2X into a fully-fledged Linux PC can be dropped.

No... that's not insane... The GPH didn't provide us with decent Linux for the gp2x, that is for sure. But why do are you assuming Linux for gp2x is an insane idea?

Linux kernel itself isn't resource hungry and services can be cutted off. The current limit of 32MB is due some not too bright decision but it is not a Linux fault.

For now the gp2x's firmware is using the bash for an example and it eats some of resources. Can be removed but at other hand sometimes it can be really usefull. So all depends on who want what. I can understand that from user standpoint Linux might be a hassle. Yet it allowed quickly port of Python (one of examples of benefits) so I could start coding some stuff on gp2x immediately. Thanks to bash and i/o redirecting I can have some sort of data output for testing purposes.

I remember long time ago that I have a PC with worse specs than gp2x (32MB, overall slower cpu). This machine was runnin the W9x and it was used for all kinds of tasks including gaming. Should we then say the windows was an insane idea for Pentium90MHz?
 
Last edited by a moderator:
Linux itself is not the insane idea. It's the constant stream of extras that people want to bolt onto it to make it a fully fledged media centre, do everything, piece of kit that are insane.

It's a handheld device that runs apps off a SD card. Nothing more. The idea of using the upper 32MB for a swap partition is crazy. Apps will overwrite it when loading images for use with the hardware blitter, plus we have the media player decoder code sitting in the middle of it, plus the frame buffers.
 
slygamer posted on Feb 14 2006 at 12:57 AM said:
evol posted on Feb 14 2006 at 08:01 AM said:
as we all know the kernel cant allocate the full 64mb of availible memory on the gp2x

i was wondering if we couldnt create a ramdisk of the upper memory and mount it as swap as the *nix kernels is fairly good att utilise swaps

in that way the memory atleast would be put to good use

and i know that the mounted swap would be slower than accesed lower 32mb but it would be a rocket fast swap file/partition

the benefit would be that the kernel could drop unused mem into swap when full

and the drawback is that its only a substitute for fully acessed memory

(atleast until sourcecode becomes open but this thread will not dig in to that part !!!)

so i would like to hear practical/technical NO/YES arguments for this aproach


cheers
The kernel doesn't know anything about the upper 32MB of RAM, so how is it going to use it as swap?

This is a bad idea because apps currently use the upper 32MB for video memory. If the kernel is using it for swap, these apps will happily overwrite it. Hardware accelerated SDL does this.

The sooner we ditch Linux and our apps can use the full 64MB as a flat memory model, the sooner these insane ideas about making the GP2X into a fully-fledged Linux PC can be dropped.

the ramdisk im thinking of will be created with standalone app so the kernel will see it once created not before

and for apps overwriting the ramdisk i dont think they can access reserved memory (mmap)

ditching the linuxkernel will surely mean that we would have to reinvent the
kernel again alot of devs thinks that linux is an resource hog and that getting rid of it would help alot but the kernel is fast and efficient at what its aimed for and the version provided is not a fully functional incarnation

and for the bunch who are screaming HH now or else im just going to say just go for it and let the most proefficient way of handling the gp2x win

but you got a strong point if the framebuffer sits in upper mem that it would be counterproductive

but insane ?? thats strong words

im not aiming for *nix desktop nore is anybody else (i would have bought the Zaurus for that)

and im just looking at alternatives untill the sourcecode arrives when it does we can alter it to get use of all the ram but hey why not discuss

alternatives and gatter information
 
Last edited by a moderator:
Ok then, if your swap module reserves some of the upper 32MB, you may find yourself not being able to run some applications because you may be using the memory they want for their hardware-accelerated images. Too bad.

The reason I want to ditch Linux is so we have flat access to all physical memory. If the Linux kernel is modified to use all 64MB, say goodbye to easy access to hardware accelerated blitting because the hardware blitter requires physical memory addresses, not the virtual addresses that the kernel gives you. Getting physical addresses from virtual addresses is nto a supported notion in Linux. It can be done, as Squidge has stated previously, but it is a hack at best.
 
slygamer posted on Feb 14 2006 at 12:14 PM said:
Ok then, if your swap module reserves some of the upper 32MB, you may find yourself not being able to run some applications because you may be using the memory they want for their hardware-accelerated images. Too bad.

The reason I want to ditch Linux is so we have flat access to all physical memory. If the Linux kernel is modified to use all 64MB, say goodbye to easy access to hardware accelerated blitting because the hardware blitter requires physical memory addresses, not the virtual addresses that the kernel gives you. Getting physical addresses from virtual addresses is nto a supported notion in Linux. It can be done, as Squidge has stated previously, but it is a hack at best.

hmm im seing what youre getting at but the framebuffer doesnt need 32mb and the mplayer libs dont have to be loaded without mplayer

another aproach would be to reserve more mem for the kernel by modifying /etc/mainc so it would reserve more mem for the kernel but leaving enough mem for the framebuffer to use

my question is how much mem would be best to leave unallocated

32/16/8/4 mb ?

http://www.xml.com/ldd/chapter/book/ch07.html
 
Last edited by a moderator:
But if you have flat access to ALL the memory won't you have to make sure you don't use the very same addresses that GPH has already setup Linux to avoid? If the hardware blitter (and friends) access the ram directly then how do you stop them from accessing it in HH mode?

And as for linux being "hard" for the "end user" I think it just boils down to how the interface works and how we design our games/aps. Linux itself can't be held responsable for programmer inability to set and adhere to standards.

Not picking on anyone :) I have the same problems with my programs
 
evol posted on Feb 14 2006 at 03:20 PM said:
my question is how much mem would be best to leave unallocated

32/16/8/4 mb ?

http://www.xml.com/ldd/chapter/book/ch07.html

Ideally there should be just one pool of 64MB. Then a kernel and aplications would reserve memory as needed. The hardware should not eat so much as it's now. The framebuffer is only 150KB on the gp2x.
 
Last edited by a moderator:
evol posted on Feb 14 2006 at 02:20 PM said:
hmm im seing what youre getting at but the framebuffer doesnt need 32mb and the mplayer libs dont have to be loaded without mplayer

They do in the current version. The mplayer libs are loaded into memory when the linux kernel starts up. So you would have to rebuild mplayer from source to stop it from doing that.


evol posted on Feb 14 2006 at 02:20 PM said:
another aproach would be to reserve more mem for the kernel by modifying /etc/mainc so it would reserve more mem for the kernel but leaving enough mem for the framebuffer to use

my question is how much mem would be best to leave unallocated

32/16/8/4 mb ?

The problem is this:

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

So the most you can have for Linux is 48MB. However, people have already built Linux kernels with the limit raised from 32MB to 48MB. At 32MB they are perfectly reliable. At 48MB, they are very unstable. So therefore, there is something in the 32MB -> 47MB range using that chunk of memory and we don't know what it is. Putting a ram disk there (or anything else for that matter) will no doubt cause the same effects.
 
Last edited by a moderator:
[/quote]

The problem is this:

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

So the most you can have for Linux is 48MB. However, people have already built Linux kernels with the limit raised from 32MB to 48MB. At 32MB they are perfectly reliable. At 48MB, they are very unstable. So therefore, there is something in the 32MB -> 47MB range using that chunk of memory and we don't know what it is. Putting a ram disk there (or anything else for that matter) will no doubt cause the same effects.
[/quote]

wouldnt the maximum size be 40mb ?

8mb after physical address are for out-of-bounds memory accesses

as defined in /linux-mmsp2/include/asm-arm/arch-mmsp2/vmalloc.h

or are im just reading it like a drunkman
 
Last edited by a moderator:
No it's just saying that they dont start allocating virtual memory until 8mb after the physical memory to catch any out-of-bounds access in the kernel code. ie. any code that accesses this region is broken.
 
Back
Top