zador.blood.stained Posted March 1, 2017 Share Posted March 1, 2017 39 minutes ago, deep said: but i dont understand problem with apt-get install linux-headers-$(uname -r) Kernel headers package has different name that you would expect from generic Debian and Ubuntu tutorials - linux-headers-next-sunxi Link to comment Share on other sites More sharing options...
deep Posted March 1, 2017 Share Posted March 1, 2017 ok. clear.thank youОтправлено с моего SM-G920F через Tapatalk Link to comment Share on other sites More sharing options...
deep Posted March 2, 2017 Share Posted March 2, 2017 after apt_get install linux-headers-$(uname -r) make headers_check -ok make headers_install-ok make scripts HOSTCC scripts/selinux/genheaders/genheaders scripts/selinux/genheaders/genheaders.c:13:22: fatal error: classmap.h: No such file or directory #include "classmap.h" ^ compilation terminated. what can i do at this moment? Link to comment Share on other sites More sharing options...
Igor Posted March 2, 2017 Share Posted March 2, 2017 1 hour ago, deep said: what can i do at this moment? This used to work but now headers are broken. Try on some older image and don't upgrade kernel until this is sorted out. Perhaps it's related to this change? Link to comment Share on other sites More sharing options...
zador.blood.stained Posted March 2, 2017 Share Posted March 2, 2017 1 hour ago, Igor said: Perhaps it's related to this change? Yes. Some extra headers from security/*/include/ needs to be packed into the packages. Link to comment Share on other sites More sharing options...
deep Posted March 3, 2017 Share Posted March 3, 2017 hello again! i make scripts in headers directory when i am installing previous version image . that's good may be you can help me with next trouble.i am getting compile error with xusb_ root@cubietruck:/usr/src# cd dahdi* root@cubietruck:/usr/src/dahdi-linux-complete-2.11.1+2.11.1# make all make -C linux all make[1]: Entering directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/linux' make -C drivers/dahdi/firmware firmware-loaders make[2]: Entering directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/linux/drivers/dahdi/firmware' make[2]: Leaving directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/linux/drivers/dahdi/firmware' make -C /lib/modules/4.9.5-sunxi/build SUBDIRS=/usr/src/dahdi-linux-complete-2.11.1+2.11.1/linux/drivers/dahdi DAHDI_INCLUDE=/usr/src/dahdi-linux-complete-2.11.1+2.11.1/linux/include DAHDI_MODULES_EXTRA=" " HOTPLUG_FIRMWARE=yes modules DAHDI_BUILD_ALL=m make[2]: Entering directory '/usr/src/linux-headers-4.9.5-sunxi' /usr/src/dahdi-linux-complete-2.11.1+2.11.1/linux/drivers/dahdi/Kbuild:124: CPU Architecture 'arm' does not support VPMADT032 or HPEC. Skipping. VERSION /usr/src/dahdi-linux-complete-2.11.1+2.11.1/linux/drivers/dahdi/xpp/xpp_version.h Building modules, stage 2. /usr/src/dahdi-linux-complete-2.11.1+2.11.1/linux/drivers/dahdi/Kbuild:124: CPU Architecture 'arm' does not support VPMADT032 or HPEC. Skipping. MODPOST 18 modules make[2]: Leaving directory '/usr/src/linux-headers-4.9.5-sunxi' make[1]: Leaving directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/linux' (cd tools && [ -f config.status ] || ./configure --with-dahdi=../linux) make -C tools all make[1]: Entering directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools' make all-recursive make[2]: Entering directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools' Making all in xpp make[3]: Entering directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp' Making all in perl_modules make[4]: Entering directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/perl_modules' make[4]: Nothing to be done for 'all'. make[4]: Leaving directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/perl_modules' Making all in oct612x make[4]: Entering directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/oct612x' make[4]: Nothing to be done for 'all'. make[4]: Leaving directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/oct612x' Making all in xtalk make[4]: Entering directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk' CCLD xusb_test xusb_test-xusb_test.o: In function `xusb_destructor': /usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_test.c:27: undefined reference to `xusb_destroy' xusb_test-xusb_test.o: In function `run_spec': /usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_test.c:65: undefined reference to `xusb_find_byproduct' /usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_test.c:75: undefined reference to `xusb_claim' /usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_test.c:81: undefined reference to `xusb_showinfo' /usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_test.c:82: undefined reference to `xusb_release' ./.libs/libxtalk.a(libxtalk_la-xusb_common.o): In function `xusb_open_one': /usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_common.c:236: undefined reference to `xusb_find_byproduct' /usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_common.c:248: undefined reference to `xusb_claim' /usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_common.c:254: undefined reference to `xusb_destroy' ./.libs/libxtalk.a(libxtalk_la-xusb_common.o): In function `xusb_destroy_interface': /usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_common.c:181: undefined reference to `xusb_release' ./.libs/libxtalk.a(libxtalk_la-xusb_common.o): In function `xusb_flushread': /usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_common.c:332: undefined reference to `xusb_recv' collect2: error: ld returned 1 exit status Makefile:628: recipe for target 'xusb_test' failed make[4]: *** [xusb_test] Error 1 make[4]: Leaving directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk' Makefile:1018: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp' Makefile:1113: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools' Makefile:662: recipe for target 'all' failed make[1]: *** [all] Error 2 make[1]: Leaving directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools' Makefile:9: recipe for target 'all' failed make: *** [all] Error 2 Link to comment Share on other sites More sharing options...
denni_isl Posted December 21, 2018 Share Posted December 21, 2018 It is almost2019 and this is still preventing one to compile like rtl wifi modules. Get this error when ... sudo make scripts Quote scripts/selinux/genheaders/genheaders.c:13:10: fatal error: classmap.h: No such file or directory #include "classmap.h" ^~~~~~~~~~~~ compilation terminated. Link to comment Share on other sites More sharing options...
Igor Posted December 21, 2018 Share Posted December 21, 2018 48 minutes ago, denni_isl said: It is almost2019 and this is still preventing one to compile like rtl wifi modules. Get this error when ... sudo make scripts And you still don't have rights to complain -> https://www.armbian.com/get-involved/ Linux is a work of XXXX people. Only X works on Armbian. In their time. Link to comment Share on other sites More sharing options...
denni_isl Posted December 21, 2018 Share Posted December 21, 2018 Thank you for the respond. It is actually a good point, and understood. And this https://www.armbian.com/get-involved/#communication and the Armbian documentations are actually the best source I have seen on the net for the everyday hobbyist wanting to get a better understanding of computers and now those days embedded systems. Regarding this issues with being unable to compile drivers for for arm64 boards, I have came to the conclusions that it is actually because aarch64 is just not there yet. And I am not a programmer so I have to remind my self ... hands off. arm64 is like a new kid in the block in the linux world. Android is just another story. Is there any migrating from Android to linux in the arm and arm64 support? Or is the Android source closed from the linux world? Now I am wondering how far arm64 is in it's development. Did see this of non supported software from debian site. https://wiki.debian.org/Arm64PortANFUList and it is quite a lot. Link to comment Share on other sites More sharing options...
martinayotte Posted December 21, 2018 Share Posted December 21, 2018 17 minutes ago, denni_isl said: actually because aarch64 is just not there yet Actually, it is there, and Armbian builds are done in 64bits when SoC is part of that familly... Link to comment Share on other sites More sharing options...
Igor Posted December 21, 2018 Share Posted December 21, 2018 6 minutes ago, denni_isl said: I have came to the conclusions that it is actually because aarch64 is just not there yet. I am not completely sure, without looking deeply into the problem, but such errors could easily pop-out on amd64 system as well. 7 minutes ago, denni_isl said: Android is just another story. Yes, its kernel is worse situation and comes with zero support. It's full of blobs and not standard solutions. Why wasting time with it? Android on OS level doesn't seems to be much of our interest anyway. And. "Nice and intuitive" UI doesn't help you when your system is fragile/unstable due to the poor kernel support. That is an everyday story behind Android on development boards. We only have better tools and less garbage around when dealing with support. Link to comment Share on other sites More sharing options...
denni_isl Posted December 21, 2018 Share Posted December 21, 2018 Both firefly rk3399 and rockpro64 are amazing products, and working like a charm with armbian though still lacking some things. Firefly is more working out of the box when rockpro64 does not yet support for it's components like the audio jack, wifi module and isa(okay in cli) slot. Then it is the usual thing that the hardware that is ahead of the software. But what did take me with a surprise is the lack of comparability with usb wifi dongles now almost as common as coffee . Link to comment Share on other sites More sharing options...
Igor Posted December 21, 2018 Share Posted December 21, 2018 10 minutes ago, denni_isl said: But what did take me with a surprise is the lack of comparability with usb wifi dongles now almost as common as coffee And who should do that? We provide a list of (good) ones - on the download pages - that work out of the box. For each kernel/board. It's planned to do more indeep testings, but day has only 24h. Some of the testings can be found scattered in this topic and elsewhere on the forum. Link to comment Share on other sites More sharing options...
denni_isl Posted December 21, 2018 Share Posted December 21, 2018 8 minutes ago, Igor said: And who should do that? We provide a list of (good) ones - on the download pages - that work out of the box. For each kernel/board. It's planned to do more indeep testings, but day has only 24h. Some of the testings can be found scattered in this topic and elsewhere on the forum. Did not see this threat before. Interesting. If only I had programming experience I would be willing to try to help out with migrating all those rtl--- modules on github to arm64. What i can see is that coordinated effort must be the best way to get the compiling environment right and then being able to adjust those modules. Btw. you at armbian are doing a excellent job. Link to comment Share on other sites More sharing options...
Igor Posted December 21, 2018 Share Posted December 21, 2018 2 minutes ago, denni_isl said: to arm64 They are not working on x86 Ubuntu as well. They usually work on Windows OOB, while Linux support is not existing or not so good. Wireless networking on Linux is not directly related to Armbian. We already went much further than generic Linux distributions. 5 minutes ago, denni_isl said: If only I had programming experience Whatever you do to relieve those who can is already a valuable contribution. In the spirit of "Contribute". Link to comment Share on other sites More sharing options...
denni_isl Posted December 23, 2018 Share Posted December 23, 2018 SUCCESS AT LAST! Installing a Realtech wireless wifi dongle driver on rockpro64. Okay being a stubborn person, is sometimes beneficial. I was at last able to install driver for my speedy Chinese USB dongle with Realtech ship. lsusb gives vendor 0bda and product b812 witch is dependent upon driver rtl8812bu. Now I want to contribute to the community on how. Did fallow the instructions on https://docs.armbian.com/Developer-Guide_Build-Preparation/ compiled a new kernel and U-boot, It did produce 5 *.deb files; linux-source-default-rockchip64_5.67_all.deb, linux-headers-rockchip64_5.67_arm64.deb, linux-u-boot-rockpro64_5.67_arm64.deb, linux-image-rockchip64_5.67_arm64.deb and installed them on the rockpro64 board. It did also include /usr/src/linux-source-4.4.167-rockchip64.tar.xz which I extracted into /usr/src/linux-headers-4.4.167-rockchip64 directory and did make clean (because of previous compile error of lacking files) and then make scripts (and viola it did work!!!). Then it was github next and this driver did look promising https://github.com/cilynx/rtl88x2BU_WiFi_linux_v5.3.1_27678.20180430_COEX20180427-5959 Fallowed the instructions of dkms install there Quote cd rtl88x2BU_WiFi_linux_v5.3.1_27678.20180430_COEX20180427-5959 VER=$(sed -n 's/\PACKAGE_VERSION="\(.*\)"/\1/p' dkms.conf) sudo rsync -rvhP ./ /usr/src/rtl88x2bu-${VER} sudo dkms add -m rtl88x2bu -v ${VER} sudo dkms build -m rtl88x2bu -v ${VER} sudo dkms install -m rtl88x2bu -v ${VER} sudo modprobe 88x2bu And it did work! Almost all the headache was because of the driver needing kernel source not just the headers under /usr/src/linux-headers-$(uname -r) Quote wlx000 IEEE 802.11AC ESSID:"my_connection-5G" Nickname:"<WIFI@REALTEK>" Mode:Managed Frequency:5.22 GHz Access Point: 00:00:00:00:00:00 Bit Rate:867 Mb/s Sensitivity:0/0 Retry:off RTS thr:off Fragment thr:off Encryption key:****-****-****-****-****-****-****-**** Security mode:open Power Management:off Link Quality=100/100 Signal level=-36 dBm Noise level=0 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Link to comment Share on other sites More sharing options...
denni_isl Posted December 23, 2018 Share Posted December 23, 2018 Why are just the kernel headers under /usr/src/ but not the whole kernel source? And another question, does one need to freeze the kernel upgrade in armbian-config to keep compiled drivers? Link to comment Share on other sites More sharing options...
Recommended Posts