On Sun, 24 Oct 2021 12:27:39 -0300 Alexandre Oliva <[email protected]> wrote:
> Hello, Denis, apologies for the huge delay in getting back to you. > > On Oct 13, 2021, "Denis 'GNUtoo' Carikli" <[email protected]> > wrote: > > > As far as I know there are only two smartphones (The Openmoko > > Freerunner and the Librem5) where the internal WiFi works without > > requiring distributions to ship nonfree firmwares (this is because > > the nonfree firmwares are integrated in a dedicated memory connected > > directly to the WiFi chip). > > Ooh, I didn't know the freerunner was like that. I've always assumed > it wouldn't work, and left it at that. Given that the display controller, microSD controller and WiFi driver (which is specific to the firmware on that flash chip) were never upstreamed, so we'd have needed to unblob the vendor kernel. Though we didn't have (and still don't have) any FSDG compliant distributions that could support the CPU of that phone (armv4t). And it only had 128M of RAM, so it would be even harder to support it nowadays. That's sad because it also contained a modem that can now run a fully free firmware (osmocomBB). Unfortunately OsmocomBB is not meant for regular use (it would require more work for that). > > The part that I didn't manage to do yet and that looks complicated > > for me is to find a way for Replicant to reuse the deblobing part > > without reusing the firmware blocking part in a way that requires > > the least amount of maintenance. > > It's not so easy, indeed. Though commenting out some of the > reject_firmware and clean_blob entries in deblob-<kver>, and > 'blobname' commands in deblob-check would likely get you the sources > you wish, the blob requests and names would still be caught by the > generic patterns that help us find new blob requests, so you'd either > have to comment those out too, or add 'accept' commands to match and > avoid flagging them. I missed the accept commands. Thanks a lot. [...] > > What I didn't understand well is what deblob-check is supposed to do > > beside finding binary code. > > deblob-check has multiple behaviors depending on the command line > options. > > It scans source files, recognizing known acceptable patterns, flagging > suspicious or known-unacceptable ones. > > It cleans up source files, keeping acceptable patterns and turning > suspicious and unacceptable ones into /*(DEBLOBBED)*/. What I'm interested in here is just to get rid of the blobs shipped by Linux, not blocking the loading of nonfree firmwares[1], and here it's not really clear which is which. Is it somehow in the interest of the linux-libre project to accept patches to differentiate both? Though once I get something good enough, I'll probably also need to find out how to adapt to the future model of linux-libre which will be done without scripts. > > The idea here is to enable people not familiar with linux-libre to > > very easily rebase the Replicant changes on top of more recent > > kernels versions, like we do with Linux, but while still keeping > > deblobed kernels. > > That's a laudable goal, but Linux changes so much from one version to > another that there's no easy way to keep up without getting familiar > with the cleaning-up scripts :-( I fear that I'll have to do that at the end. In contrast, rebases against stock linux-libre are really easy to do, especially now that there are git repositories of linux-libre. Thanks a lot to the people that worked on making it easier to reuse. > I hope this helps. I had planned to add more detailed thoughts on the > general structure of deblob-check, but then you'd would have to wait > longer, and those bits probably wouldn't help you much anyway. Thanks a lot for all the information. I'll get back to working on it as soon as I fix my really bad cold. References: ----------- [1]At the end of the day the real fix would be to reverse engineer the nonfree WiFi firmwares[2] to finally be able to use linux-libre + our paches on top, but we are not in a position to do that right now (we need to at least get Replicant 11 out before starting big projects like that, else the Replicant project would probably be dead). And we are not in a situation to re-discuss the blocking of all nonfree loadable firmwares either (we can't easily organize an in-person event to do that, and that is also something very time consuming to do). So instead I need to release Alpha images for Replicant, and I need to make sure that they are fully free software to avoid further issues. [2]Some people already have expressed some interest in doing that kind of reverse engineering work, and there have even been attempts to do it already which didn't succeed yet due to the lack of time. And there is also some work we might be able to reuse, though we'd need to look into it, especially to make sure it's free software and doesn't contain any nonfree code or data. Denis.
pgpOwSmaAdAAm.pgp
Description: OpenPGP digital signature
_______________________________________________ linux-libre mailing list [email protected] http://www.fsfla.org/cgi-bin/mailman/listinfo/linux-libre
