GP2X /dev/mem Size

[andrew_j_w]

Hi,

How much memory does the /dev/mem device give you access to? Is it just the bottom 32MB that is accessible to Linux, or can you use it to access the top 32MB as well?

I wondering how to copy data so it can be used by the second processor. Is it as simple as mmap'ing /dev/mem, or do I need to do something much trickier?

I would check myself but I've been bashing my head against a brick wall trying to get an arm toolchain to build successfully.

Cheers,
Andrew

 

[Robster]

The /dev/mem device gives access to *all* memory. That is, the 64MB of RAM (including the Linux kernel itself! Have fun overwriting the kernel and watch your GP2X crash in 1001 exciting ways!), the CPU special function registers (mostly at 0xC0000000 upwards), etc.

As for using that ability to drive the second processor, I'm afraid I have no idea, but these things will become clear as we get more experience with the device

 

[andrew_j_w]

Excellent, that's what I was hoping for.

I'm well aware that I'll crash my GP2x in a multitude of fancy ways, but I think if I stick to 0x2000000-0x4000000 I should be fairly safe...

Cheers,
Andrew

 

[Vimacs]

stay in the upper 16mb and evrything will be fine
if you want the upper 32mb you have to keep the 2nd core in reset state. (according to squidge)

 

[andrew_j_w]

I was under the impression that the second core began in the reset state. Do you not have to do something to specifically enable it?

Surely the lower 16mb is not totally reserved for 920t code? I was expecting that whatever was left after the code and static data was loaded would usable for a heap.

I could well be wrong, I'm definitely pushing the limits of my knowledge with this sort of programming

Andrew

 

[Vimacs]

the lower 32mb are just normal ram to linux.

 

[andrew_j_w]

Sorry, I meant the lower 16MB of the upper 32MB... if that makes sense! You said if I stay in the upper 16MB I'll be fine, but I don't see why I can't access the whole of the upper 32MB...

Andrew

 

[aapje89]

The /dev/mem device gives access to *all* memory. That is, the 64MB of RAM (including the Linux kernel itself! Have fun overwriting the kernel and watch your GP2X crash in 1001 exciting ways!), the CPU special function registers (mostly at 0xC0000000 upwards), etc.

​

is that possible, lol

 

[Squidge]

Sorry, I meant the lower 16MB of the upper 32MB... if that makes sense! You said if I stay in the upper 16MB I'll be fine, but I don't see why I can't access the whole of the upper 32MB...

Andrew

​

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).

So, if you wish to access all of upper 32MB, you need to hold the second processor in reset, so it doesn't crash when you overwrite all it's code memory

Best idea would probably be to leave the code memory alone, hold the second processor in reset, trample over all it's data memory, and then when your program is done, just blank the data memory to 0xFF(*) and release the reset.

If you don't hold it in reset, it'll use up battery power for no reason. If you don't leave the code memory alone, and/or release the reset at the end, the movie player will not function until the next power cycle.

* 0xFF may well be wrong, feel free to try other values.

For some reason, the second processor starts running when the linux kernel is loaded, rather than just when the movie player is launched. Hopefully, this will be fixed in a future version of the firmware (as it's a waste of battery power to have it running when not necessary)

 

[andrew_j_w]

For some reason, the second processor starts running when the linux kernel is loaded, rather than just when the movie player is launched. Hopefully, this will be fixed in a future version of the firmware (as it's a waste of battery power to have it running when not necessary)

​

Ah, I see. I expected the second processor to be completely unused until the movie player was actually run. That is bizarre, I hope it is fixed soon.

Thanks for the help!

Andrew

 

[rhk]

Ah, I see. I expected the second processor to be completely unused until the movie player was actually run. That is bizarre, I hope it is fixed soon.

Since they released the source, I've been poking through it.

It looks like the second cpu core is initialized by a kernel module. Is also looks like the kernel module could be unloaded and reloaded. The init function in the module loads 380k of data into the address space used by the second core. The unload function closes the hardware, which would (hopefully) put it into reset. I haven't dug in far enough to confirm that.

 

[rhk]

Turns out the code is written to support being a module, but is not compiled as a module. It might be necessary to create a second kernel module which can be be used to uninitialize the in-kernel support when it loads, and then re-initialize it when it unloads.