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

https://www.youtube.com/watch?v=l7lIewA9fm4 is an example of a VPU accelerated mandelbrot, without the arm core even being turned on

for (int i=0; i<16; i++) { int temp = a[i] * b[i]; if (store) c[i] = temp; if (accumulate) accumulator[i] += temp; }

basically, the VPU can run this entire line of code in just 2 clock cycles, and this isnt even the 3d core, which is entirely seperate and more complex

others like the 2d core default to the same mode, but can be re-configured to allow the arm to control it

there may be more peripherals that behave the same way, and require code on the VPU to help out

and like others said, changing the arm freq, from the arm core, could be dangerous, it may just lock up, because it turned its own clock off

but the actual register writes to drive the ISP are still in the blob, and libcamera is just telling the blob how to tweak every knob in the hardware

it makes no sense why they have opened it up so much, yet still insist on keeping that last bit a secret

using the vc4-stage1, vc4-stage2, and rpi2-test projects together, you can do the entire boot chain (dram init and loading linux) using open source code

other projects act as demo's or tests on how to run custom code at various stages, but not actually boot linux on the arm core many of those demos work on the the entire pi model range

pi3 support is only broken due to arm side problems, which could be fixed by just using a different bootloader

and the https://github.com/librerpi/rpi-open-firmware codebase can already boot linux headlessly on both pi2 and pi3, it uses a different arm bootloader

> a China knockoff version of R-Pi camera board

> It's happened to the company I work with, they were marketing a cheap copy of our consumer electronics device under our brand name and even our customer service phone #.

the DRM in the camera, is to ensure only an authentic camera can function work the firmware based drivers, where all the support is offered

any un-supported camera must be driven from linux, and doesnt get full support from RPF, it must instead be supported by the community

or you can do baremetal VPU and skip the firmware entirely 500mhz dual-core VPU 128kb of L2 cache for both code and data if you want dram, you need the ram drivers (only present for the VC4 line, pi0-pi3) you could optionally rely on 1 closed stage to bring ram up, and do baremetal VPU from the start(4).elf to avoid the dram init sequence

and if you build upon rpi-open-firmware, you could get all 6 cores baremetal, running custom code

my theory is that its only there to protect the non-rpi customers, now that the hmac-sha1 layer has been cracked