How much of the Dragonboard 410c’s functionality depends on closed-source assets?
I’d love to run a plain-vanilla Debian-type setup on the board, but I’d like to know what I would give up in the process.
Thanks!
Hi Bill,
Below thread gives a good answer to your question.
http://www.96boards.org/forums/topic/bootloader/
Everything on these boards depend on closed source firmware, in one way or another.
There are however no closed source kernel modules or userspace binaries in the Linux/Debian system itself. The necessary firmware that needs to be loaded into peripherals are all available for download (or included in the Linaro builds).
Compared to the AOSP builds, which require some binary blobs, you’re loosing e.g. camera and Hexagon SDK support, as these are not yet reimplemented for the Debian builds.
Regards,
Bjorn
Ok, that latter answer is what I was looking for. I already knew a bunch about the various bootloaders. 
You say that they aren’t “reimplemented” yet, suggesting that the code is available somewhere but it just hasn’t been packaged up. Is that accurate?
Is there a table somewhere that lists what works using only public source code, and what doesn’t?
I’ve worked with Qualcomm for many years, and know that they’re very stingy about giving away code to make any of their hardware do anything useful apart from them. I’m hoping that they’ve turned a new leaf…
b.g.
The “locked-down” bootloaders aren’t all that big a deal in the big picture, honestly. Their DDR is VERY fussy, for example, and I’d prefer to leave that magic to them anyway…
The following firmware are being used in the current Linux releases (Debian, OE):
- GPU firmware
- WLAN/BT firmware
- Venus firmware (for hw codecs)
In a soon-to-be-done release, we are adding GPS which needs a firmware that runs on the DSP.
As bamse said above, this are firmware blob that runs on co-processors , so outside of the main ARM cores. There is no proprietary components (even in the user space) in our Linux releases (even in the upcoming release with GPS). These firmware are released on Qualcomm Dev Network site with a specific EULA.
For the Hexagon SDK , that will require proprietary user space components, and at least for now, there is no plan to have an non proprietary solution for our releases.
For camera, we are planning to release a v4l2 based driver set to support YUV sensors, the driver will include enough support for CSI and ‘control path’ to use YUV CSI sensors. The initial release will not support scaling/cropping and will support 1 sensor only, but we are working on adding support for multiple sensors and scaling/cropping. For ‘raw’ sensors, that requires proprietary user space ‘sauce’ that we are not planning (at least for now) to include in our release.
For the other firmware (GPU, WLAN, Video), there are corresponding open source drivers that ‘use’ the appropriate coprocessors. the drivers for GPU and WLAN are mostly in mainline by now, the v4l2 driver for Video will be sent on mailing list soon.
Also, I don’t mind the firmware blobs so long as they can be carried forward into newer kernels/runtimes, etc.
Looking forward to seeing QCOM’s stuff get easier to use and re-use!
Excellent reply, by the way.
