A Funny Thought On Memory

[judge0]

Anyone remember when GPH was still taking suggestions on the machine?

Anyone recall when they agreed to bump the memory up to 64 MB of RAM?

Here's the funny thought . . .

Seeing how with the linux kernel active we only have 32 MB of RAM to use for apps,
what would we run apps on if they DIDN'T upgrade to 64 MB?????

Just a wierd thought that crossed my mind........ :lol:

 

[aQwaBlaz3]

umm......WHAT? :blink:

 

[judge0]

With 64 MB of RAM installed and running linux, our apps only have 32 MB of RAM to use for themselves.

So, if GPH DIDN'T upgrade to 64 from 32 MB of RAM as initially designed, what would our apps use for RAM?

 

[DJWillis]

16MB for Linux and user-space total and 16MB for the 940T.

That is how the default 32MB kernel MMSP2 is setup (not that it works, I think the video code NEEDS 64MB).

We have 32MB for Linux and user-space (mid 20's left after boot), 16MB for the 940T and 16MB above it that can be addressed with some tweeking.

 

[judge0]

@DJWillis - Thanks for the reply.

The thing I was thinking was that the kernel would use almost all available RAM at 32 MB & leave us with no memory at all :lol:

Wouldn't it be nice if they had opted for the 128 MB the MagicEyes SOC can handle, though?

 

[icurafu]

I imagine we would have a more cut down version of linux, so it would probably take longer to release the first products.

I don't think it would have been very popular if they did that. It was a bad first attepmpt at spec'ing the machine, that was fixed up.

I imagine if it was released, a 64mb followup would have been releasesed soon after.

 

[Squidge]

If they opted for 128MB, Linux would still only have 32MB for technical reasons. Also, I think they increased it to 64MB due to the fact that the mpeg decoding support requires a minimum of 64MB.

 

[Aimless_E]

If they opted for 128MB, Linux would still only have 32MB for technical reasons. Also, I think they increased it to 64MB due to the fact that the mpeg decoding support requires a minimum of 64MB.

​

But why the split on the second and third bank of ram why not a straight fifty/fifty split insead of 32/16/16? What technical reason would they have for that? Im not complaining, I think its rather interesting actualy,just trying to figure out what benifits come from such a setup.

 

[Squidge]

The video decoding stuff is sold as a chunk of binary precompiled to run at a certain address, and that address just happens to be 32MB. That code also requires 17MB of RAM, and since it's on the second processor, can't take advantage of Linux. The rest of the memory is simply unused.

Hence, it is actually 32/32, just as the last 15MB of the second chunk is unused, so some people say it's 32/16/16 (which is technically incorrect).

 

[DJWillis]

Hence, it is actually 32/32, just as the last 15MB of the second chunk is unused, so some people say it's 32/16/16 (which is technically incorrect).

​

Pah!, smartarse

 

[Aimless_E]

So a program that uses the memory range above 32mb ,as the video decoder, would have full access to the rest of the ram? That could be usefull...if only I had my gp2x.

 

[PSyMastR]

So a program that uses the memory range above 32mb ,as the video decoder, would have full access to the rest of the ram? That could be usefull...if only I had my gp2x.

​

If only...

 

[chris_r]

Can someones explain this in simpler terms. I dont understand this at all. Does this mean we cant use anywhere near the whole 64mb ram because linux is using it all?

 

[woogal]

Can someones explain this in simpler terms. I dont understand this at all. Does this mean we cant use anywhere near the whole 64mb ram because linux is using it all?

​

If an app is using linux then the gp2x is effectively only a 32mb machine. Linux itself then takes up a bit of that memory leaving 20 something meg (22? 24? might be one of those two but I can't remember now). So in the simplest terms possible - The largest rom size you can load if an emulator uses linux might be a little larger than 20mb, assuming that the emulator itself is quite small.

 

[judge0]

If they opted for 128MB, Linux would still only have 32MB for technical reasons. Also, I think they increased it to 64MB due to the fact that the mpeg decoding support requires a minimum of 64MB.

​

My point exactlty.
If linux used 32 MB out of 128 that leave us approximately 94 MB after table structures to divide amongst cores etc.

In my eyes that is a nicer amount of ram for programming than 22 MB divided between two cores.

I knew there would be overhead involved with using linux, just not how big a penalty was involved. Possibly using UBoot to load a minimalist launcher, forgo the movie player/music hardware and just program in ARM/Thumb code would be a better option.

 

[woogal]

If they opted for 128MB, Linux would still only have 32MB for technical reasons. Also, I think they increased it to 64MB due to the fact that the mpeg decoding support requires a minimum of 64MB.

​

My point exactlty.
If linux used 32 MB out of 128 that leave us approximately 94 MB after table structures to divide amongst cores etc.

In my eyes that is a nicer amount of ram for programming than 22 MB divided between two cores.

I knew there would be overhead involved with using linux, just not how big a penalty was involved. Possibly using UBoot to load a minimalist launcher, forgo the movie player/music hardware and just program in ARM/Thumb code would be a better option.

​

I don't think you understand. If the gp2x had 128mb, there would still only be around 20mb available to an app running under linux, with linux taking the rest to bring us up to the 32mb limit. Then the next 16mb would be taken up by the second core, and all the rest would be unusable. Linux doesn't use 32mb of the memory, it just sees the gp2x as a 32mb machine.

 

[judge0]

If they opted for 128MB, Linux would still only have 32MB for technical reasons. Also, I think they increased it to 64MB due to the fact that the mpeg decoding support requires a minimum of 64MB.

​

My point exactlty.
If linux used 32 MB out of 128 that leave us approximately 94 MB after table structures to divide amongst cores etc.

In my eyes that is a nicer amount of ram for programming than 22 MB divided between two cores.

I knew there would be overhead involved with using linux, just not how big a penalty was involved. Possibly using UBoot to load a minimalist launcher, forgo the movie player/music hardware and just program in ARM/Thumb code would be a better option.

​

I don't think you understand. If the gp2x had 128mb, there would still only be around 20mb available to an app running under linux, with linux taking the rest to bring us up to the 32mb limit. Then the next 16mb would be taken up by the second core, and all the rest would be unusable. Linux doesn't use 32mb of the memory, it just sees the gp2x as a 32mb machine.

​

If this was unusable, why would MagicEyes market three different versions of their SOC, 32, 64 and 128 MB Ram versions?

 

[Squidge]

If this was unusable, why would MagicEyes market three different versions of their SOC, 32, 64 and 128 MB Ram versions?

​

Because Linux is not the only thing you can run. It also fully supports WinCE, and custom operating systems, which do not have the same limits.

Basically, if instead of loading Linux on bootup we load a small application launcher, then we will have access to the entire 64MB. Also, if we produce a version of Linux without dual-core support (which also means no mpeg decoding support), then we will have a Linux that will happily use 64MB.

 

[chris_r]

Well seeing as we've got the source to the magiceyes kernel (I think. The open2x project has it doesnt it?) couldnt we just recompile the kernel with support for 64mb of ram as opposed to 32mb?

 

[judge0]

If we have the source for any additional hardware( ie D-pad etc) yes.