4 ms·
Nobody's mentioned it yet, so... One reason this is so difficult is that the VPU runs an entire standalone OS of its own. AIUI, the VPU is in control of the co
by lproven 4y ago
Nobody's mentioned it yet, so... One reason this is so difficult is that the VPU runs an entire standalone OS of its own.
AIUI, the VPU is in control of the computer, and the Arm is an accessory device. Only once the VPU has loaded its OS and it's running will the Arm be initialised, the kernel image loaded into RAM by the VPU, and then the Arm pointed at it. The OS continues to run and control the computer even once the Arm is running.
The VPU runs a proprietary RTOS called ThreadX, which is now owned by Microsoft.
https://en.wikipedia.org/wiki/ThreadX https://en.wikipedia.org/wiki/ThreadX
- cleverca22 4y agothe rpi-open-firmware codebase is going the route of doing as little as possible on the VPU, and giving the arm control fairly early i found that a bit limiting, with the lack of threads/drivers/modularity thats why i ported little-kernel, to get the same level of features threadx likely offered, and then be able to expand the feature-set far more with the lk-overlay codebase, you can drive the 2d and 3d cores from the VPU you can output ntsc or vga video you can turn on the arm core and boot linux and you can map /dev/fb0 on the video output and there are various cpu-independent features in LK like tga image decoding