On 2016-05-06, peter green wrote: > On 06/05/16 20:59, Phil Endecott wrote: >> It interests me to speculate as to why, at both a technical and an >> organisational level, these people are doing their own things, rather >> than making "real" Debian work on this board. Are any of the >> people involved in this even reading this list? >> > To get "plain Debian" working on a board with a new SoC requires a LOT > of effort upstreaming patches (since the Debian maintainers > understandablly don't want to put random vendor crap in their packages > and try to support it locally). There are also boards where there is some mainline support in u-boot and linux, but the appropriate features have not yet been enabled in the Debian packages. Much of what I've done is testing what kernel options are needed and requesting they be enabled in the linux packages. Occasionally, I attempt to backport minimal patches from linux-next to whatever linux version is currently in unstable. On a great $TIME_UNIT, I report bugs upstream, or nudge the right people, and someone eventually, miraculously fixes them! But that takes time, patience, testing, and often more time, and more testing, and more patience, and more time still, usually. > Even when it does work there are often functional limitations due to > code that is either non-free or is free but needs major reworking > before upstream will take it. Indeed. Numerous boards will work with mainline kernel and even mainline u-boot, but require non-free "firmware" (raspberry pi, odroid-xu4) to even boot. In the "Debian will remain 100% free" section of the Debian social contract (https://www.debian.org/social_contract): "We will never make the system require the use of a non-free component." Many boards simply won't boot without non-free components. This basically means we can't create fully working debian-installer images for those boards, unless someone reverse-engineers a free alternative firmware. The definition of "work" is another issue. I've largely been testing serial console machines for building software as part of the reproducible-builds project, so mostly verify serial console, all CPUs are detected, memory is correctly detected, ethernet, sata, mmc/emmc and usb support. Other features get limited, if any, testing from me. Obviously, that doesn't support all use-cases that people might expect most of these boards to work with, given that many have HDMI, audio and other ports. > Whereas to get a mostly Debian system with a few custom bits (kernel, > bootloader, possiblly custom versions of a few libraries) going is much > easier. Convenience of the moment wins almost every time. live well, vagrant
Attachment:
signature.asc
Description: PGP signature