Any Update On 2nd Cpu?

[g4m3r]

So the 2nd CPU is useless?

 

[mattyrb]

So in a nutshell the GP2x and the GP32 aren't so different power wise.... bar the extra ram, extra few mhz, sd slot, usbs and extra buttons...wait a mo that is quite alot LoL but nothing to really push the GP2x that far out ahead of its old pal the gp32

​

dotn forget the Tv-Out

​

oh yes that Tv-Out....which hasn't been shown working yet lol

Not pointless for movie watching on the go and home brew games....but lets be honest here, how many home brew games really do push things to the limits graphically from scratch....very few

 

[craigix]

So the 2nd CPU is useless?

​

I think that if you can't understand how it works then you should just say nothing.

Instead just wait and see what is released which uses it, and how it is used, then you will understand what it can be used for.

 

[Flexinoodle]

Well saying the second CPU is useless is kinda silly really, It can be used it is just who will use it that counts, It may be useless to some coders but then they may not need to use it. If however somebody does use it and uses it well, How can that be useless.
Personally i'm excited to see what types of things can be done with it and i'm pretty sure that sort of info will come but it may take more than a couple of weeks

 

[Mr. Anderson]

So the 2nd CPU is useless?

​

It is used for Video encoding allready, you call that useless? Don't be impatient, Squidge allready showed that the second core CAN be used by EVERYONE who can understand how it works and has the skill to programm stuff using both cpu's at once...

The GP2x is not even out, officially, and yet the software library of the system gets bigger and bigger every day!

 

[jmetal88]

Whats the point of the 2nd cpu then? Most ports will run at full speed anyway, in my eyes i only see it usefull for PSX or GBA (the PSX seems a bit unreasonable since gp2x doesnt seem to be powerfull enough) , even then doesnt the person have to do all the code from scratch?

Anyway to get to the point... Now that I understand it and  my expectatons are lowered

​

PSX @ playable speed, is a nice dream...
But GBA playable (or full speed) is possible, by using the second core. You mean, only rewrite all stuff, from scratch ? Did you ever wrote an emulator ? From scratch ?
99.9999% of all coders here, would never start sutch a project. TOO BIG.
The GBA emulator we are talking about was a proof of concept. It was possible to run some basic Homebrew GBA programms on the emulator, but not eaven one commercial one was running. So first you must add more GBA features, and then rewrite some parts, to use the second core. I think using a working GBA emulator, and then rewrite some parts, would come to a faster result...

​

Umm.... It ran the UK version of "Who Wants to be a Millionaire?" quite well. I had a lot of fun on my trip to London playing that. I couldn't get anything else to run, though......

 

[Robster]

Quite funny really - Mr Mirko has spouted so much misinformation in this thread, and then Squidge shows how wrong he is, and now there's no response. Mr Mirko, no offence, but you have been dead wrong about some things in this thread, and because you have a fairly high profile in the community, people are going to believe you. I would like to see you come along here and admit, publically, that you made some errors.

Here's what I know about the 940T core in the MMSP2 chip:

1) It is an independent processor, with all of the capabilities of a normal ARM 940T CPU

2) As with all ARM940T processors, it does not have an MMU, but it does have a PU (Protection Unit, which is kinda-sorta like a cut-down MMU)

3) There is nothing about the 940T core that is specialised for video processing. The MMSP2 chip has some video processing hardware built into it. That video processing hardware can be controlled equally well by either processor.

4) The 940T core is used by GPH's implementation of Linux to control video processing. That is because GPH decided to make it that way, the MMSP2 chip does not require it.

5) Using the 940T core in Linux for other tasks apart from video processing is a bit difficult, but as Squidge has shown, it is possible. In HH mode (or direct hardware, or whatever) it is trivially easy to use the 940T core.

6) Linux on the GP2X is a great thing, because it means ports of SDL apps can be made very quickly and easily (as we are seeing at the moment). As the system matures, we will see more HH applications and these will use all of the hardware (including the 940T core) more effectively to give even better results than we are seeing at the moment.

7) Mr Mirko's drawing of the memory arrangement for the two cores was wrong, and it was a hopeless oversimplification. Here's a better drawing, and even then it is misleading because it is too simplified:

                                ----------    -----------
                               | 64MB     |  |On-chip    |
                               | SDRAM    |  |Peripherals|
                                ----------    -----------
                                        |      |
 -----------                            |      |                           ----------
| 16kB Inst.|    ------     -----     ------------     -----     ------   | 4kB Inst.|
| Cache     |---|      |   |     |   | Memory     |   |     |   |      |--| Cache    |
  -----------    | 920T |---| MMU |---| Controller |---| PU  |---| 940T |   ----------
  -----------    | Core |   |     |   |            |   |     |   | Core |   ----------
| 16kB Data |---|      |    -----     ------------     -----    |      |--| 4kb Data |
| Cache     |    ------                 |                        ------   | Cache    |
 -----------                             |                                ----------
                                   ------------
                                  | Static RAM |
                                  | Bus        |
                                   ------------

Each core contacts the Memory Controller to get data from the RAM. If they both access the RAM at the same time, then one will have to wait (for a very short time) for its data. However, each core has its own independent cache which will mean that the cores do not need to always fetch data or instructions from the RAM. Also, if a core accesses the on-chip peripherals (ie. the memory locations which control the on-chip hardware), then it does not prevent the other core from accessing RAM. There is yet another data path, called the "Static RAM bus", which is independent of the others. The only thing connected to this currently is the USB controller.

There are a bunch of people who've got together on IRC (#gp2xdev on EFnet), including me, Squidge, mr_spiv, DJWillis, and others who are making an SDK to enable people to program direct hardware relatively easily. Programming direct hardware on the GP2X, including the 940T core, will be no harder than writing code for the GP32. And even though only a small percentage of programmers will choose to use this ability, some very interesting things are going to happen! Look for public releases of sdk2x (which is our SDK) in the very near future, or come on #gp2xdev to join in the fun

 

[Robster]

Oh, one more thing: both CPU cores run from the same base clock, e.g. 400MHz. However the cores have independent dividers from this base clock, and so they can run at different frequencies! It is perfectly possible to run the 920T at 200MHz while the 940T runs at 100MHz, the Memory Controller takes care of the timing differences.

 

[nubie]

Go Robster!!

I have been trying to get this across to everyone.

You put it so succinctly, thank you, this should be stickied.


Sticky this!!

 

[Hanz™]

Wow I didn't see this thread, this was heated!
[walks away slowly]

Edit: Give mirko a break Robster - it appears he actually hasn't been on gp32x since when he last posted ages ago. So he "probably" isn't ignoring you both.

 

[bmilleker]

Im glad everything is cleared up, and that the dual core situation sounds way better than it sounded at the beginning of this thread.

 

[slygamer]

You put it so succinctly, thank you, this should be stickied.

​

It's been wikied at least.

 

[mattyrb]

Finally.....I was waiting for someone to flippen show this guy the second cpu was usefull for something more than divx

 

[mr.mirko]

Quite funny really - Mr Mirko has spouted so much misinformation in this thread, and then Squidge shows how wrong he is, and now there's no response. Mr Mirko, no offence, but you have been dead wrong about some things in this thread, and because you have a fairly high profile in the community, people are going to believe you. I would like to see you come along here and admit, publically, that you made some errors.

Here's what I know about the 940T core in the MMSP2 chip:

1) It is an independent processor, with all of the capabilities of a normal ARM 940T CPU

2) As with all ARM940T processors, it does not have an MMU, but it does have a PU (Protection Unit, which is kinda-sorta like a cut-down MMU)

3) There is nothing about the 940T core that is specialised for video processing. The MMSP2 chip has some video processing hardware built into it. That video processing hardware can be controlled equally well by either processor.

4) The 940T core is used by GPH's implementation of Linux to control video processing. That is because GPH decided to make it that way, the MMSP2 chip does not require it.

5) Using the 940T core in Linux for other tasks apart from video processing is a bit difficult, but as Squidge has shown, it is possible. In HH mode (or direct hardware, or whatever) it is trivially easy to use the 940T core.

6) Linux on the GP2X is a great thing, because it means ports of SDL apps can be made very quickly and easily (as we are seeing at the moment). As the system matures, we will see more HH applications and these will use all of the hardware (including the 940T core) more effectively to give even better results than we are seeing at the moment.

7) Mr Mirko's drawing of the memory arrangement for the two cores was wrong, and it was a hopeless oversimplification. Here's a better drawing, and even then it is misleading because it is too simplified:

                                ----------    -----------
                               | 64MB     |  |On-chip    |
                               | SDRAM    |  |Peripherals|
                                ----------    -----------
                                        |      |
 -----------                            |      |                           ----------
| 16kB Inst.|    ------     -----     ------------     -----     ------   | 4kB Inst.|
| Cache     |---|      |   |     |   | Memory     |   |     |   |      |--| Cache    |
  -----------    | 920T |---| MMU |---| Controller |---| PU  |---| 940T |   ----------
  -----------    | Core |   |     |   |            |   |     |   | Core |   ----------
| 16kB Data |---|      |    -----     ------------     -----    |      |--| 4kb Data |
| Cache     |    ------                 |                        ------   | Cache    |
 -----------                             |                                ----------
                                   ------------
                                  | Static RAM |
                                  | Bus        |
                                   ------------

Each core contacts the Memory Controller to get data from the RAM. If they both access the RAM at the same time, then one will have to wait (for a very short time) for its data. However, each core has its own independent cache which will mean that the cores do not need to always fetch data or instructions from the RAM. Also, if a core accesses the on-chip peripherals (ie. the memory locations which control the on-chip hardware), then it does not prevent the other core from accessing RAM. There is yet another data path, called the "Static RAM bus", which is independent of the others. The only thing connected to this currently is the USB controller.

There are a bunch of people who've got together on IRC (#gp2xdev on EFnet), including me, Squidge, mr_spiv, DJWillis, and others who are making an SDK to enable people to program direct hardware relatively easily. Programming direct hardware on the GP2X, including the 940T core, will be no harder than writing code for the GP32. And even though only a small percentage of programmers will choose to use this ability, some very interesting things are going to happen! Look for public releases of sdk2x (which is our SDK) in the very near future, or come on #gp2xdev to join in the fun

​

Okay, i think i should answer to this.

to
1. I never said something against this...
2. The same thing, i posted here, no MMU, and the PU is useless, couse Linux can not use it.
3. I posted above, that you can run any code on it, and GPH is using it as an divx decoder.
4. same as 3.
5. I was all the time talking about Linux, and @ Linux it is not possible to run your second core. You must handselect, what to run on the second core, the OS does(and can not) not handle it, like on normal SMP machines. Also, my simple picture, is not wrong. Linux is using the first 32MB of ram, the other 32MB of RAM are used for the second core. (exactly my picture). Your picture is showing, how the hardware is build up, and how it is usable without an OS in the background. But the GPH Linux implementation, the memory is segmented in 32/32MB.
6. I never said other things...
7. It was not wrong, it showed, how the GPH Linux is using the dual cores. And if you want to use dualcore, you are stick to the 32/32mb segmetation too. ( You cant extend the Linux mem to e.g. 64MB)

Your diagramm is nice, (and i know the datasheet) , but for the noncoders it says nothing.

Okay, some things i did not know, was that you can independant clock the two cores.
But i think, if you want to use it, the best performance would be using the same clock for both cores.

Also, i want to explain (again), why the second core, is useless in my opinion. And i never wrote any miss information, and Squdge does not show me wrong. His example is an example, THAT the second core, runs under Linux, not more, not less. And i never said, that it would not run.
Okay, my last explanation, then this thread is dead for me.
The second core is useless, couse the OS ( Linux ) can not use it. The dualcore is not SMP cabable. This means, i can not use a simple fork, to run code on the second core.
You can only use the second core, and speed up things, if you rewrite the code, reload your second core programm to the >32MB segment ( and out of the Linux segment ). This is how GPH is using the second core.
ALSO, now, that we know, that the OS can not handle the second core, you must rewrite your code, to use the second core. And this is not a simple task. Using existing Emulator source is cool, but if you want to use the second core, you must rewrite some parts, and add syncronizing between dataexchange, and some semaphore technic.

Dont get me wrong, the gp2x was sold as Linux OS gaming machine, with dualcore support, and THIS is wrong. The second core is not supported by the OS (SMP).

Please do not say to me, that i spread missinformations.
Also squidge does not fill out my simple example, how to use the second core. Couse it is not useable this way. It is a lot more complicated...

 

[Huxley]

mr.mirko, I know English probably isn't your first language but you must realise that your insisting that the second core is 'useless' is sensationalist at best. Please try to re-phrase this if you don't want to cause a commotion.

You know full well that the second core is anything but useless - it's simply a bit trickier to use. Yes, the average C coder won't be able to make much use of it, but do they need to? Most of the advanced emulators that NEED the second processor are being handled by experienced coders such as Squidge, Reesy etc who will be able to get the best out of the two processors given time.

Most people including myself respect your opinion and believe you're not trying to purposefully spread misinformation, but you do need to be careful with your words or people will misunderstand you.

 

[mr.mirko]

mr.mirko, I know English probably isn't your first language but you must realise that your insisting that the second core is 'useless' is sensationalist at best. Please try to re-phrase this if you don't want to cause a commotion.

You know full well that the second core is anything but useless - it's simply a bit trickier to use. Yes, the average C coder won't be able to make much use of it, but do they need to? Most of the advanced emulators that NEED the second processor are being handled by experienced coders such as Squidge, Reesy etc who will be able to get the best out of the two processors given time.

Most people including myself respect your opinion and believe you're not trying to purposefully spread misinformation, but you do need to be careful with your words or people will misunderstand you.

​

Okay, i checked the def of the word "useless", and it is used for things, who are broken, or can not get to work. I think i used the wrong word.
Couse we all know, that the second core, is working.

 

[g4m3r]

So the 2nd CPU is useless?

​

I think that if you can't understand how it works then you should just say nothing.

Instead just wait and see what is released which uses it, and how it is used, then you will understand what it can be used for.

​

Sorry, I'm a noob to this stuff. :unsure:

 

[Oscaruzzo]

Linux is using the first 32MB of ram, the other 32MB of RAM are used for the second core.

No.

Also squidge does not fill out my simple example, how to use the second core. Couse it is not useable this way. It is a lot more complicated...

​

Did you read the code he posted? I see this:

	arm940code[0x4000] = 26;	// first operand
	arm940code[0x4001] = 42;	// second operand
	arm940code[0x4002] = 1;  // command code
	arm940code[0x4003] = 0;  // result 
	
	while (arm940code[0x4002] != 0) /* do nothing */;

	printf ("%d + %d = %d !\n", arm940code[0x4000], arm940code[0x4001], arm940code[0x4003]);

which is just what you asked for.

Now, while I agree that a SMP machine is something completely different, this is far from being "useless". It will require a lot of coding, but there's people who can actually do more than "./configure && make".

 

[Emu&Co]

Check this:

rlyeh[zZ] got it working
rlyeh[zZ]
...
EvilDrago rlyeh: Working what?s
rlyeh[zZ] 2nd core in linux in my minimal lib
...
rlyeh[zZ]
EvilDrago rlyeg: Weeha, that's cool!
Reesy nice, well done

Coped from dev Chat 18:40 GMT+1

 

[nickspoon]

Mr. mirko's posts have too many commas in them.

OK, admittedly that is how you do commas in German, but reading it is a pain.