Le dimanche 29 septembre 2013 à 21:06 +0300, Paul Sokolovsky a écrit : > This probably gets more and more offtopic, but can you elaborate what > would be reasons for that? I obviously don't disagree, but I think that > the main reason for that is that community - at the whole, then GNU/FSF > endorsing subset, then finally those who often practice "freedom" > rhetoric - don't want free drivers *that* much. People want new Visual > Basic in the shape of JavaScript, to make it thrash and crash even on > their toaster, that's why projects like http://nodejs.org/ thrive, and > projects like OpenFWWF and > http://git.bues.ch/gitweb?p=b43-ucode.git;a=summary die.
That's probably true, but I don't think we need a critical mass of users nor a lot of demand to keep these projects alive. All it takes is a few motivated technical people with the right skills and access to the right documentation to make it possible. I think we lack both aspects: there aren't so many highly skilled developers with interest in reversing firmwares for chips and the documentation to achieve that is not available from the chips manufacturers. We could also count on the chip manufacturers to release free firmwares, but that is not realistic. Maybe having a lot of users interested in having free firmwares could make a change, it seems that manufacturers have started to take Linux in account when releasing drivers for their chips (what I mean is that free drivers, written by the manufacturer, for Linux exist, especially for WiFi). Now if we had lots of users demanding free firmwares, it could lead them to take this in consideration as well, like it did for Qualcomm and ath9k_htc. But I call that a miracle that it actually happened recently, kudos to the FSF and the people over at ThinkPenguin. > Going beyond vulgar objectivism of "community gets what it deserves", > IMHO the main detriment to (community) development of open firmwares if > lack of widely hackable and easily retargettable C compiler, to handle > all the custom and obscure CPU cores vendors put into peripheral > devices. I am very surprised to hear this. First because I always heard that gcc works for an outstanding number of processors and also because I heard professionals mention that gcc code is very neat, possible to understand and portable. Maybe this is a wrong view, but I wouldn't go as far as saying that gcc is in decline. > > On the other hand, ath9k_htc has a fully free firmware, released by > > Qualcomm, so it's the only WiFi chip that could permit having a free > > wifi firmware on an embedded device (read: phone, tablet, SBC). > > Seeing 700Mb tarball, I skipped it first time. Now that you insisted > that it's *fully* free software, I spooled it to wget and the very same > moment it dawned on me why the size: it's just what I wrote above - > that "firmware" must have the whole toolchain attached to be actually > usable (rebuildable)! Indeed, it has. No wonder vendors don't rush into > making such releases - it's great chore to put that altogether to be > actually reusable by third parties. Kudos to Qualcomm for putting it all > together, I wonder if that can indeed be a breakthru for free WiFi > implementations. Up to date code is btw not on FSF side, but at > https://github.com/qca/open-ath9k-htc-firmware/ If you clone the git repo, it's not 700MB. As far as I can remember, it actually downloads the *upstream* gcc and friends and builds it for the chip's instruction set. I see nothing wrong there, this is the usual procedure. When working on ARM devices, you need an ARM cross-compiler as well, and I remember building those when playing with the GTA02. -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution Website: http://www.replicant.us Wiki/Tracker: http://redmine.replicant.us _______________________________________________ Replicant mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/replicant
