Did You Know...?
- Thread starter Squidge
- Start date
Squidge
Certified Guru
Oops, I seemed to have single handedly managed to start a linux flame war :blink: That was certainly not the intention. We all know that the Linux on the GP2X is not exactly brilliant, but of course it can and will get better in future releases, either by GPH or the Open2X project.
Well, perhaps something like:
Would do it?
Well, perhaps something like:
Code:
MOV R0, #0x3F @ 4GB page starting at 0x0
MCR p15, 0, R0,c6,c0, 0 @ set as data memory region 0
MCR p15, 0, R0,c6,c0, 1 @ set as instruction memory region 0
MOV R0, #1 @ area 0 cachable/bufferable
MCR p15, 0, R0,c2,c0, 0 @ Write data cachable bits
MCR p15, 0, R0,c3,c0, 0 @ write bufferable bits
MCR p15, 0, R0,c2,c0, 1 @ write instruction cachable bits
MOV R0, #3 @ full access (read+write)
MCR p15, 0, R0,c5,c0, 0 @ write dataspace access permissions
MCR p15, 0, R0,c5,c0, 1 @ write inst space access permissions
MRC p15, 0, R0,c1,c0, 0 @ control register:
ORR R0, R0, #0x1000 @ icache enable
ORR R0, R0, #4 @ dcache enable
ORR R0, R0, #0xC0000000 @ async clock select + fast bus
ORR R0, R0, #1 @ protection unit enable
MCR p15, 0, R0,c1,c0, 0 @Would do it?
Shikaku
ROFL THE WORD PENIS IS HILARIOUS!
Go assembly!!
Last edited by a moderator:
torpor
hack hack hack, the little machines fight back
squidge: if this is provided as a linux kernel module, will it be helpful? we can build modules for the GP2X linux now, so do you want me to make this into a module for general-purpose use .. would it be useful?
torpor
hack hack hack, the little machines fight back
linux is not pants. linux is underwear. in your case, probably road-tripp'ed underwear with skidmarks.
in my case, linux is a case of being girls panties, on the floor of my bedroom, a couple pairs scattered here and there, and i'm the one in bed with boxers on, nice and snug ..
in my case, linux is a case of being girls panties, on the floor of my bedroom, a couple pairs scattered here and there, and i'm the one in bed with boxers on, nice and snug ..
Squidge
Certified Guru
That code was posted as the commands needed for the 940. It will only work on the 940, as it configures the MPU, whereas the 920 has a much more complicated MMU.
Thinking about it, a kernel module that would configure the upper 32mb properly would cure a lot of things. Also, if that same kernel module accepted some commands via a /dev entry or something like that to allow to easily run code in kernel mode and access interrupts, it could almost kill the need for a HH-mode alltogether, as there would be very little point for it.
Thinking about it, a kernel module that would configure the upper 32mb properly would cure a lot of things. Also, if that same kernel module accepted some commands via a /dev entry or something like that to allow to easily run code in kernel mode and access interrupts, it could almost kill the need for a HH-mode alltogether, as there would be very little point for it.
torpor
hack hack hack, the little machines fight back
gotcha ..
well, its feasible .. we can build modules for the stock GP2X kernel now, so tell me more about what you think this module needs to be able to do and maybe we can have a bit of a crack at it ..
Last edited by a moderator:
Last edited by a moderator:
Squidge
Certified Guru
Yup, I was thinking of either loading the module after doing the usual mmap entries (as mmap modifies the mmu table) or having it accept commands via a /proc or /dev entry.
God Ginrai
Godmaster
Hooray for modules that make it so people don't hate Linux! ;P
I have a feeling a module like that might be a bad idea, as apparently it duplicates functionality already in the kernel... the best fix would be modifying how the kernel sets up the mmu tables. If someone were to make a module now, it might be obsoleted once the kernel gets fixed, and we wouldn't want programs out there that depend on this module, etc.
My original suggestion for a module was assuming that it was just a global configuration flag, and not something that gets set every time an mmap, etc is done, and in that way a shell script could just be used to fix the setting and then run the program (the program wouldn't need modification, and would still run without the module, but slower).
My original suggestion for a module was assuming that it was just a global configuration flag, and not something that gets set every time an mmap, etc is done, and in that way a shell script could just be used to fix the setting and then run the program (the program wouldn't need modification, and would still run without the module, but slower).
God Ginrai
Godmaster
I think it's a GOOD idea to make the module, seeing as we don't know WHEN the Kernal WILL get fixed, so we have SOMETHING that does it for us until then.
vic20-ian
Member
Official knock Linux thread
(That's gp2x linux)
I vote for instant on Mr Spiv style firmware like GP32
At 35 I am getting to old to reboot and waste 20 seconds :lol:
Last edited by a moderator:
Mudi
You're pushing your luck little man
Even if we did have programs depending on the module and then the kernel getting fixed, couldn't a "dummy" module be released after the kernel is fixed that just let's the kernel handle everything?
paeryn
Reclusive maniac
You'd have to be careful with what areas of memory you allow to be cached, you can't allow both processors to cache the same area of memory, and you need some area of memory that both can access without being cached for use by the hardware and inter-processor communication.
Personally I'd leave the 920 as it is with its 32M, and let the 940 cache 16M of its 32M, the remaining 16M left as uncached shared memory. Multi-processor setups are awkward enough to use effectively without complicating matters.
Two independent processors with different memory models sharing the same memory space along with hardware blocks which undoubtably have their own (albeit small) caches - it's already an accident waiting to happen, if we start messing around it won't be long before all hell breaks loose.
Personally I'd leave the 920 as it is with its 32M, and let the 940 cache 16M of its 32M, the remaining 16M left as uncached shared memory. Multi-processor setups are awkward enough to use effectively without complicating matters.
Two independent processors with different memory models sharing the same memory space along with hardware blocks which undoubtably have their own (albeit small) caches - it's already an accident waiting to happen, if we start messing around it won't be long before all hell breaks loose.
Squidge
Certified Guru
The way I see it we have two choices:
1) We can see if the kernel gets fixed. Not likely as the kernel thinks it's only got 32mb to play with, and the setting may stop the movie player from working. Also, people don't like flashing new kernels as they know how easily the device can be bricked.
2) Build a module.
It's not possible to have a seperate program to do this as what we need to do must run in kernel mode. The only way of getting into kernel mode without rebuilding the kernel is a module.
Besides, if the module is done right and the kernel does eventually get changed, then the module will know this and not bother to change anything. It's not a problem to copy an extra file to your sd card.
paeryn: Why can't you allow both processors to cache the same area of memory? That was exactly my intention. Let the 920 cache all 64MB and the 940 cache the upper 32MB. There is already a perfectly good IPC mechanism between the processors which doesn't depend on external memory, and if the need arises, it's easy enough to ask the processor to drain it's write buffer.
Plus, why slow down the applications which don't make use of the multiprocessor support? This is why I said the module should be configurable via a /dev or /proc entry, so an application could state how it liked the memory setup.
1) We can see if the kernel gets fixed. Not likely as the kernel thinks it's only got 32mb to play with, and the setting may stop the movie player from working. Also, people don't like flashing new kernels as they know how easily the device can be bricked.
2) Build a module.
It's not possible to have a seperate program to do this as what we need to do must run in kernel mode. The only way of getting into kernel mode without rebuilding the kernel is a module.
Besides, if the module is done right and the kernel does eventually get changed, then the module will know this and not bother to change anything. It's not a problem to copy an extra file to your sd card.
paeryn: Why can't you allow both processors to cache the same area of memory? That was exactly my intention. Let the 920 cache all 64MB and the 940 cache the upper 32MB. There is already a perfectly good IPC mechanism between the processors which doesn't depend on external memory, and if the need arises, it's easy enough to ask the processor to drain it's write buffer.
Plus, why slow down the applications which don't make use of the multiprocessor support? This is why I said the module should be configurable via a /dev or /proc entry, so an application could state how it liked the memory setup.
Well, an alternative to flashing a new kernel could be using loading a new kernel off the SD instead, via the HH-from-linux loader, if someone's gotten that working. I can just imagine the bootup speed complaints with a setup like that though.
I think you may be right about the movie player, but it'd be hard to know how it would like changes without trying it - it's possible it's already cache and/or buffer safe as it was likely developed with this chip in mind, and it might even run better or at a lower clock speed if buffering/cache can be enabled.
I guess my main worry is programs showing up that don't gracefully handle the absence of a proposed /dev or /proc interface, as it could cause problems later on if it becomes no longer applicable, and there's the lesser issue of the module likely needing to be recompiled for future firmware versions.
In any event, a module is definitely safer than dreaming up an elaborate hack to spy on the mmu tables in kernel memory and manually flipping them from inside the program, and as long as the program can handle the module not being there, I can't really see a problem.
I think you may be right about the movie player, but it'd be hard to know how it would like changes without trying it - it's possible it's already cache and/or buffer safe as it was likely developed with this chip in mind, and it might even run better or at a lower clock speed if buffering/cache can be enabled.
I guess my main worry is programs showing up that don't gracefully handle the absence of a proposed /dev or /proc interface, as it could cause problems later on if it becomes no longer applicable, and there's the lesser issue of the module likely needing to be recompiled for future firmware versions.
In any event, a module is definitely safer than dreaming up an elaborate hack to spy on the mmu tables in kernel memory and manually flipping them from inside the program, and as long as the program can handle the module not being there, I can't really see a problem.
paeryn
Reclusive maniac
There's nothing physically stopping you, but the cache needs to be in sync with memory.
What if if the 920 writes "1" at 0x100 but caches it.
The 940 then writes "2" at 0x100, also caching, but the cache line gets written out.
The 920 now decides to flush, 0x100 now contains "1", but the 940 still thinks it's "2".
Shared memory space should not be cached, if it's not shared, why allow the 920 to potentially cache the 940's memory?
Any program that does use the 940 but relys on the memory model as it stands could really mess things up. The big problem is that you can protect / cache memory to your heart's desire on the 920, but any program running on the 940 potentially has free reign, it's not got Linux looking after it.
Last edited by a moderator:
Yeah but since you are comparing the girl to linux she must be 600 pounds
And those panties could be used as a pup tent, and she is yelling "is it in yet". Because linux is a slow, fat, bloated, PIG.
Last edited by a moderator:
