Author Topic: VPU access  (Read 2616 times)

pepone (OP)

  • *
  • Posts: 16
VPU access
« on: September 23, 2013, 10:15:11 am »
Hello
It may be a stupid question, but I can't find any answer to it, so..

When I read the JZ4770 datasheet, I can see that the VPU is actually a Xburst MIPS core, much like the main cpu but at half the speed if I understand correctly.

Is there any possibilities to access this core and use it as a second cpu? I can't find any documentation about it.


pcercuei

  • ***
  • Posts: 1432
    • My devblog
Re: VPU access
« Reply #1 on: September 23, 2013, 11:17:27 am »
There is a bit of documentation yes, we've been working on it a bit but we have yet to get it to work. But while the VPU is indeed just another Xburst, it has a tiny amount of RAM attached to it (<64kB, something like 48kB IIRC) so it would be useful only for very specific tasks like cryptography or signal processing.

wumpus

  • *
  • Posts: 12
    • Visucore
Re: VPU access
« Reply #2 on: September 23, 2013, 03:48:13 pm »
I played with this a bit last week, but wasn't able to get it to work reliably. There is some code (mostly Android, see https://github.com/IngenicSemiconductor/XBOMX) but it won't work as-is.

I managed to run some MIPS code on the second core but it seems that (but maybe it's simply my unit at fault) there is some bus problem, causing writes to be ignored and the device to randomly hang. Maybe I'm doing something wrong.

If you're really interested in this feel free to drop me a mail, I can send you my proof of concept code and the kernel changes I needed, but it's not for the weak hearted :)
« Last Edit: September 23, 2013, 03:50:28 pm by wumpus »

pepone (OP)

  • *
  • Posts: 16
Re: VPU access
« Reply #3 on: September 23, 2013, 04:34:50 pm »
Interesting. I've asked that because the gp2x also had a second core for video purpose, with very little cache. it could access 32MB of memory but with the same bus than the main core, so it was not optimal. Even with those limitation, it give a nice boost to some project (picodrive emulated some stuff on it IIRC, gngeo all the sound emulation core: z80+ym2610)

Even if there is not much ram (I've read 48kbit too I think), I guess there is some mechanism to transfer data from the main memory to the scratch pad, maybe a DMA? if it's fast enough it could be useful.


wumpus

  • *
  • Posts: 12
    • Visucore
Re: VPU access
« Reply #4 on: September 23, 2013, 04:59:47 pm »
Yes, it has DMA support. Both for the command stream and for 2D images (as it's meant to assist with video decoding) but can also be used general purpose. It has three DMA engines for that. How it works exactly I don't know, the above XBOMX link has various codec sources and may be helpful there (along with kernel sources it's the only openly available "documentation" for the VPU block).

wumpus

  • *
  • Posts: 12
    • Visucore
Re: VPU access
« Reply #5 on: September 24, 2013, 08:57:12 am »
I got it to work!
Current UBIBoot sets the AHB1/VPU bus to 333Mhz, which is much larger than the other clocks (except the CPU clock) this somehow caused the instability. I am not sure what's the maximum acceptable value but setting the clock to 166Mhz fixes it.

I pushed my proof of concept with required patch instructions (you currently need custom UBIBoot and kernel) to https://github.com/laanwj/gcw0_vpu_poc

This proof of concept makes the AUX core change a value in shared memory and lets the main core poll for completion. It'd be nice to use interrupts, or DMA, but this is the first step, someone else can pick this up if interested.

Have fun. If you have questions feel free to ask me here or join #etnaviv on freenode IRC.

BTW: total internal RAM for the VPU appears to be TCSM1 (48kB fast ram coupled to AUX core for communication) + SRAM (28kB fast ram coupled to AUX core for DMA transfer) and TCSM0 (16kB fast ram coupled to MAIN core for communication) so 92kB in total.
« Last Edit: September 24, 2013, 11:51:51 am by wumpus »

pepone (OP)

  • *
  • Posts: 16
Re: VPU access
« Reply #6 on: September 24, 2013, 12:57:11 pm »
nice!
good work, I'll study it when I got some times.

wumpus

  • *
  • Posts: 12
    • Visucore
Re: VPU access
« Reply #7 on: September 24, 2013, 04:38:31 pm »
We can even write directly to the framebuffer from the VPU :) This is pretty fun. It'd be possible to run a small game entirely on the VPU, well at least if you send through input to it somehow.

https://github.com/laanwj/gcw0_vpu_poc/blob/master/src/tests/poc_fb.c
https://github.com/laanwj/gcw0_vpu_poc/blob/master/src/firmware/test2_p1.c
« Last Edit: September 24, 2013, 04:40:28 pm by wumpus »

wumpus

  • *
  • Posts: 12
    • Visucore
Re: VPU access
« Reply #8 on: September 27, 2013, 07:56:45 am »
Latest push adds proof-of-concepts for using irq notification from AUX to MAIN core (for example to signify completion) as well as using dma engine GP2 to tile a pattern to the framebuffer.

Yeah yeah I've gone deep enough in this rabbithole, I know, back to etnaviv now :)

mth

  • *
  • Posts: 298
Re: VPU access
« Reply #9 on: October 05, 2013, 04:49:08 am »
For anyone interested in playing with this, the 2013-10-04 OD update contains a fix to the boot loader to set the VPU clock to a frequency that actually works. You still need to build your own kernel from the jz-3.11-vpu branch though.

 

Post a new topic