free PDA running JMP
- Anmelden oder Registrieren um Kommentare zu schreiben
I'm not sure of any freedom problems, to be honest- the version the Chip uses is forked from the main U-Boot repository, and doesn't include USB boot functionality, but that's not a violation of freedom.
I'm responding to comment #46 down here because things were starting to get a little too scrunched to read. (It would be great if the indent width of comment replies were halved so that it would take twice as long for this to happen.)
After making deblob-check executable, running ./deblob-check CHIP-linux.tar.gz gives CHIP-linux/firmware/WHENCE within /firmware/WHENCE is a text file containing incomplete license information. I'm not sure exactly what the output should look like since I can't find sample usage anywhere, but I would have expected to get a list of source code files that contain blobs.
CHIP-linux.tar.gz
EDIT: Looking through the files manually it appears that almost everything in /firmware/ has to go. It's all .HEX, .ihex, or .H16 files with no actual source code.
>It would be great if the indent width of comment replies were halved so that it would take twice as long for this to happen
Seconded.
>I'm not sure exactly what the output should look like since I can't find sample usage anywhere, but I would have expected to get a list of source code files that contain blobs.
I'm not sure, but I think that's what the script is trying to give based on any license declarations it finds in the files. The WHENCE file it lists, for example, doesn't contain a full license declaration and so is marked as non-free; the HEX, ihex, and H16 files you mention seem to (in most cases) contain GPLv2 declarations at the bottom. I don't know if these are actually legal, but they're there.
It appears that this script won't be much help. Hopefully the other scripts in the set are slightly more effective.
>Looking through the files manually it appears that almost everything in /firmware/ has to go. It's all .HEX, .ihex, or .H16 files with no actual source code.
It appears so. Have you tried the deblob-main script? Apparently that should deblob tarballs, although the performance of deblob-check suggests manual cleansing might be needed.
You're right. I should have been running deblob-main. After compressing the kernel to "linux-4.4.tar.bz2", changing line 52 of deblob-4.4 to read "kver=4.4 extra=13", and running $ ./deblob-main 4.4 13 I get Uncompressing linux-4.4.tar.bz2 into linux-4.4.tar Indeed, drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc does not contain this file. It appears to contain gf110.fuc4 instead. Maybe this is a difference between the vanilla 4.4.13 kernel and NTC's, in which case I guess I could alter deblob-4.4 manually to address errors like this.
Extracting linux-4.4.tar into linux-4.4
Copying linux-4.4 to linux-libre-4.4-gnu13
Deblobbing within linux-libre-4.4-gnu13, saving output to linux-libre-4.4-gnu13.log
ERROR: drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/gf119.fuc4 does not exist, something is wrong
Use --force to ignore
deblob-4.4 failed, aborting
cleaning up...
I tried running $ ./deblob-main --force 4.4 13 to see what it would do ignoring missing files. I got a lot of messages resembling ATH6KL - Atheros ath6kl support which is encouraging, but eventually got
drivers/net/wireless/ath/ath6kl/init.c: disabled non-Free firmware-loading machinery
drivers/net/wireless/ath/ath6kl/init.c: removed blobs
drivers/net/wireless/ath/ath6kl/core.h: removed blobsATH10K NL80211_TESTMODE - nl80211 testmode command I'm not sure what to make of this error or how to fix it, but the script is partially working so that's progress.
drivers/net/wireless/ath/ath10k/testmode.c: disabled non-Free firmware-loading machinery
ERROR: drivers/net/wireless/ath/ath10k/testmode.c did not change, something is wrong
deblob-4.4 failed, aborting
cleaning up...
The last version of deblob-* to contain drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/gf110.fuc4 is deblob-4.2, so out of curiosity I tried including that in the directory instead and running $ ./deblob 4.2 Sure enough, the script was able find all files it was looking for and complete without errors.
NTC says this kernel is based on linux-4.4 and even made an announcement about upgrading from 4.3, so I don't understand why apparently none of the non-free firmware is newer than that in 4.2.
Regardless, the script apparently succeeded in deblobbing everything hardcoded into deblob-4.2. I guess the question is whether or not there are additional blobs that it was not looking for. From deblob-4.2,
# This script, suited for the kernel version named below, in kver,
# attempts to remove only non-Free Software bits, without removing
# Free Software that happens to be in the same file.
# Drivers that currently require non-Free firmware are retained, but
# firmware included in GPLed sources is replaced with /*(DEBLOBBED)*/
# if the deblob-check script, that knows how to do this, is present.
Since deblob-check was present, does that mean it should have deblobbed all GPLed sources whether or not they were specifically hardcoded into deblob-4.2? Does that also imply that any non-GPL sources were left alone even if they contained blobs?
EDIT: I'm attaching the log.
| Anhang | Größe |
|---|---|
| linux-libre-4.2-gnu.txt | 78.24 KB |
Sorry for the late reply!
I'm not entirely sure as to how the scripts work, honestly. I've had a look through them, and there's a long list of files in the deblob-4.2 file: that would seem to suggest that the blob locations are hard-coded, but it's not proof. I've asked at the GNU Linux-Libre mailing list, so hopefully somebody there will be able to help (presuming the message ever makes it through...).
I might have figured it out. The reason deblob-check was only printing one filename is that it exits once it finds a blob. By commenting out the exit line I was able to get it to keep looking and list all files with blobs.
As expected, running deblob-check on the original kernel results in finding a lot of blobs. I then tried running it on the new kernel generated by deblob-main. It found six files with blobs: /arch/x86/crypto/crc32c-pcl-intel-asm_64.S and then ran for another eight hours without finding anything else. It didn't exit, presumably because I had commented out the exit line, but I'm pretty sure it was done. I'll try running it again with verbose output to make sure that it has definitely checked all of the files.
/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
/arch/arm/boot/dts/sun5i-r8-chip.dts
/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
I think that the sun*i-* files might be false positives. The offending code in each seems to be nand-randomizer-seeds = /bits/ 16 < followed by a bunch of hex values. This seems legitimate to me.
The other file, crc32c-pcl-intel-asm_64.S (attached) might be okay too. The long hex values are "precomputed constants" which seems fine to me but I'll look into it a little more to be sure.
| Anhang | Größe |
|---|---|
| crct10dif-pcl-asm_64.S.txt | 15.58 KB |
This is promising! I'm pretty sure you're right that the dts files are false positives, and the precomputed constants seem to have good reason to be there too. Hopefully that means the kernel shouldn't be too much more work... which would just leave the other two programs you listed initially. I'll see if there's any license information floating around for those two.
There doesn't seem to be a lot on the other two programs, but it seems like all should be clear. Chip-mconfigs look like it should be removable; it's only an openbox/tint2 theme manager tool, which I don't think matters for XFCE. As for xserver-xorg-video-armsoc, no source or license is obviously available. However, it's developed by Free Electrons, who seem like a free software development company, so there doesn't seem to be any issue here. I'll contract them just to ensure the source is available.
I did a bit of digging and through checking out Ubuntus and Debians websites I stumbled upon this link https://github.com/endlessm/xf86-video-armsoc which appears to be what the xserver-xorg-video-armsoc package as well as a few others are built from. This is licensed under one of the MIT licenses and is Free Software if I'm not mistaken. However, please check for yourself - I could well be wrong.
- PenGNUin
I finally got the script to run all the way through without running out of memory by splitting up the tar archive and using the awk script instead of the python one. The awk script flagged the same sun*i files but actually did not have a problem with crypto/crc32c-pcl-intel-asm_64.S, further leading me to believe it was a false positive when the python script flagged it. It did not find any other blobs in the rest of the files. Since I'm pretty sure the sun*i files are false positives, I'm going to go ahead and try to compile it now.
Thanks for looking into those two other files. xserver-xorg-video-armsoc looks okay, and CHIP-mconfigs can as you say be removed.
Tell us how it goes!
Compiling on the PocketCHIP using the config file for the existing kernel
/boot/config-4.4.13-ntc-mlc
creates deb files of form
linux-*-4.2.0-rc1-gnu_4.2.0-rc1-gnu-*_armel.deb
When I try to install 'linux-image-4.2.0-rc1-gnu_4.2.0-rc1-gnu-1_armel.deb' I get
package architecture (armel) does not match system (armhf)
Since I'm compiling on the PocketCHIP using the same configuration as the existing kernel, I'm not sure how I'm ending up with the wrong architecture. When I do the same thing on my laptop I get linux-*i386.deb, as expected.
In the (y/n/?) questions that came up during the build I did not see any that mention armel or armhf, and I don't see how the problem could be in the .config file.
I can't find any information on how to force armhf apart from cross-compiling, which seems like it should be unnecessary since I'm compiling on the same machine on which I want to install.
Does anyone have any ideas as to why this is happening?
- Anmelden oder Registrieren um Kommentare zu schreiben