GP2X Using Second Processor.
- Thread starter k0in
- Start date
Squidge
Certified Guru
1) code needs to loaded into physical memory aligned on a 16MB boundary (not a virtual address returned by malloc and friends). Under Linux, this address should also be 32mb or above.
2) Hold the second processor in reset whilst you give it your execution address, and then release the reset (see the MMSP2 pdf for how to do this)
3) Second processor runs your code whilst you do other stuff with the primary processor.
Note: Second processor can not run Linux code or access any Linux libraries or operating system calls. The code should either be PIC (Position independant) or located at address 0x0. The easiest way to do this is by taking a GP32 dev kit and hacking up the linker script/etc.
EDIT: Stupid mistake.
2) Hold the second processor in reset whilst you give it your execution address, and then release the reset (see the MMSP2 pdf for how to do this)
3) Second processor runs your code whilst you do other stuff with the primary processor.
Note: Second processor can not run Linux code or access any Linux libraries or operating system calls. The code should either be PIC (Position independant) or located at address 0x0. The easiest way to do this is by taking a GP32 dev kit and hacking up the linker script/etc.
EDIT: Stupid mistake.
The docs on the MagicEye's processor tells you how to set the base address of memory for the second processor and also tells you how to reset the second processor.
Basically you follow these steps:
1) configure the second processor's base address, the default is the beginning of the second 32MB of RAM.
2) pull on the second processor's reset line to keep it in the reset state while you load an executable into the right place in it's RAM.
3) release the second processor from reset and it will run your executable.
Squidge, do you have to link the executable so that it is located at 0x00000000 since that is what the base address looks like to the second CPU? Is there a vector table that you have to locate after?
Anyway, once you get the second processor executing some code, you can use the dual ported, interrupt registers to facilitate communcation between the processors.
Last edited by a moderator:
Doesn't the second CPU map the base address in the first CPU's memory map (e.g. 0x02000000) to it's 0x00000000 location?
So from the first CPU's perspective the address is 0x02000000, but to the second CPU, that is 0x00000000?
Last edited by a moderator:
Robster
Dodgy hardware mod maker
Minimoose: you're correct.
The 940T core's address map is shifted by the 940BANK value, or in other words, the 940BANK value is added to the 940T's address to convert it to the 920T's memory space. So if 940BANK is 2, then "0x00000000" as seen by the 940T will be 0x02000000 in the 920T's memory space.
All of the special function registers (mostly starting at 0xC0000000) will be at 0xBE000000 for the 940T. The RAM below 0x02000000 can still be accessed by the 940T, it appears right at the top of its memory space - so the 920T's reset location of 0x00000000 will be at 0xFE000000 as seen by the 940T.
The 940T core's address map is shifted by the 940BANK value, or in other words, the 940BANK value is added to the 940T's address to convert it to the 920T's memory space. So if 940BANK is 2, then "0x00000000" as seen by the 940T will be 0x02000000 in the 920T's memory space.
All of the special function registers (mostly starting at 0xC0000000) will be at 0xBE000000 for the 940T. The RAM below 0x02000000 can still be accessed by the 940T, it appears right at the top of its memory space - so the 920T's reset location of 0x00000000 will be at 0xFE000000 as seen by the 940T.
Squidge
Certified Guru
of course your right, and me is stoopid 
Silly thing to get wrong.
Not sure if this is right (Rob?) but I treat the 940 as a standard arm, so address 0x0 is the vector table (instructions for reset, irc, fiq, swi, undefined, etc). I've not used interrupts on the second processor yet, and I can't be arsed to try it now...
Silly thing to get wrong. Not sure if this is right (Rob?) but I treat the 940 as a standard arm, so address 0x0 is the vector table (instructions for reset, irc, fiq, swi, undefined, etc). I've not used interrupts on the second processor yet, and I can't be arsed to try it now...
Robster
Dodgy hardware mod maker
I didn't see any mistakes, I was just adding some (hopefully) useful information... ah well, I'm confused (as usual).
Anyway, yes the 940T does have a standard vector table at its 0x00000000. I have no idea how interrupts are handled between the cores - for example, if there's a sound DMA interrupt, how does the programmer control which core handles the interrupt? I guess all that will become clear in time...
Anyway, yes the 940T does have a standard vector table at its 0x00000000. I have no idea how interrupts are handled between the cores - for example, if there's a sound DMA interrupt, how does the programmer control which core handles the interrupt? I guess all that will become clear in time...
Hrm...good question. My first instinct is that all of the interrupts are probably routed to the 920, but I guess it all depends on the interrupt source. It is totally possible that you can set a flag in a DMA command packet that says "interrupt the 940 instead of the 920". I hope that is the case because I plan on using the 940 for all I/O and sound so I'm going to need to do DMA from there.
(I got my email from gp32z on friday and it was scanned as "out for delivery" by USPS this morning. It should be there when I get home tonight. I'll finally get to write some code.
)
Last edited by a moderator:
Hrm...good question. My first instinct is that all of the interrupts are probably routed to the 920, but I guess it all depends on the interrupt source. It is totally possible that you can set a flag in a DMA command packet that says "interrupt the 940 instead of the 920". I hope that is the case because I plan on using the 940 for all I/O and sound so I'm going to need to do DMA from there.
(I got my email from gp32z on friday and it was scanned as "out for delivery" by USPS this morning. It should be there when I get home tonight. I'll finally get to write some code.
Actually there is no way to 'flag' interrupts from various hardware sources to 940t.. at least none is documented, except that 920-940 interface. I wouldn't be surprised that 920 has to take care of interrupts coming from hardware and then trigger 940 via the 920-940 interface. Anyway, this is something to find out soon as my next thing to do exception handlers for the gp2x HH project.
Last edited by a moderator:
Hrm...good question. My first instinct is that all of the interrupts are probably routed to the 920, but I guess it all depends on the interrupt source. It is totally possible that you can set a flag in a DMA command packet that says "interrupt the 940 instead of the 920". I hope that is the case because I plan on using the 940 for all I/O and sound so I'm going to need to do DMA from there.
(I got my email from gp32z on friday and it was scanned as "out for delivery" by USPS this morning. It should be there when I get home tonight. I'll finally get to write some code.
Actually there is no way to 'flag' interrupts from various hardware sources to 940t.. at least none is documented, except that 920-940 interface. I wouldn't be surprised that 920 has to take care of interrupts coming from hardware and then trigger 940 via the 920-940 interface. Anyway, this is something to find out soon as my next thing to do exception handlers for the gp2x HH project.
Reading through chapter 8 in the data book suggests that either processor can handle interrupts. They always refer to the CPU as "the ARM920T/ARM940T". I assume you just have to decide to only handle interrupts with one processor rather than the other. Which begs the question, what happens to the other processor while the one is handling an interrupt?
I think the plan should be to just handle all the interrupt controller configuration and interrupt handling one the 920 and not worry about this.
Last edited by a moderator:
