wildcat_paris

I haven't used the user-mode of sunxi-ss Patch applied to cryptodev sun4i-ss implementaton of md5/sha1 is via ahash algorithms. https://lkml.org/lkml/2015/11/17/408

ytn, good question, I need to read soon or later the details of the crypto tests included in the kernel, I only see the following logs (the one with higher priorities for the kernel) as well as the tests marked as "passed" for sun4i_ss/arm/neon

it is a decent prng, impossible to assess anything about being a csprng

thanks zador.blood.stained for digging launchpad ok but Igor is using same Armbian build tool on x86_64 so that is strange. gr@server1404:~/test_arch_scripts$ wget http://apt.armbian.com/pool/main/l/linux-upstream/linux-headers-next-sunxi_4.5_armhf.deb gr@server1404:~/test_arch_scripts/usr/src/linux-headers-4.2.3-sunxi/scripts/basic$ file fixdep fixdep: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=d7f63b82f3c7346453e5b3fea2fbcc3442132460, not stripped FYI my guest running Ubuntu 14.04 server amd64 (GCC 4.8): gr@server1404:~$ dpkg -l "*gnu*hf" ||/ Name Version Architecture Description +++-=======================================-========================-========================-=================================================================================== ii binutils-arm-linux-gnueabihf 2.24-5ubuntu13cross1.98. amd64 GNU binary utilities, for arm-linux-gnueabihf target ii cpp-4.8-arm-linux-gnueabihf 4.8.2-16ubuntu4cross0.11 amd64 GNU C preprocessor ii cpp-arm-linux-gnueabihf 4:4.8.2-1 amd64 The GNU C preprocessor (cpp) for armhf architecture ii gcc-4.8-arm-linux-gnueabihf 4.8.2-16ubuntu4cross0.11 amd64 GNU C compiler ii gcc-4.8-multilib-arm-linux-gnueabihf 4.8.2-16ubuntu4cross0.11 amd64 GNU C compiler (multilib files) ii gcc-arm-linux-gnueabihf 4:4.8.2-1 amd64 The GNU C compiler for armhf architecture the following patch (comment #16 2011-12-27) makes the "make scripts" with CROSS_COMPILE (for arm instead of x86_64) https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/666267/comments/16 so the "scripts" are needed in x86_64 format when building the kernel (as you wrote) on x86_64 Ubuntu => is there a kernel 4.2.x to 4.3.x problem? (just wondering as a newbie) or a CROSS_COMPILE tool issue as, fixdep "file shows: my Ubuntu 14.04 amd64 => armbian tool fixdep: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24 My lamobo-r1 local "make scripts" fixdep: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32 Igor Ubuntu 14.04 amd64 => armbian tool fixdep: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26 mine => GNU Linux 2.6.24 (from amd64) or 2.6.32 (from ARM) Igor => GNU/Linux 2.6.26 (from amd64) ??? Or any missing cross tool Igor may have on his Ubuntu 14.04 amd64 that is not installed by the scripts ??? just in case I have added "multilib" cross tools then launched a "fresh" copy of Armbian and I get amd64, so nothing related to 4.2/4.3 kernel root@server1404:~/armb/output/debs/test_headers# cd usr/src/linux-headers-4.2.6-sunxi/scripts/basic/ root@server1404:~/armb/output/debs/test_headers/usr/src/linux-headers-4.2.6-sunxi/scripts/basic# file fixdep fixdep: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=3de7788bd491d0c90d5dc137ede013d5ab8b9e27, not stripped

Hello Igor(?), Armbian Buddies, I have ended being not able to compile a kernel module (and it breaks dkms btw) because files in linux-headers are ELF x86-64 (not ELF ARM) but it is quick & dirty FIXED :-) (Maybe I have messed Armbian tool playing with v4.3 kernel ???) root@bpi:~/kern4.3_4# dpkg -i linux-headers-next-sunxi_4.6_armhf.deb Unpacking linux-headers-next-sunxi (4.6) over (4.6) ... Setting up linux-headers-next-sunxi (4.6) ... root@bpi:~/kern4.3_4# cd /usr/src/linux-headers-4.3.0-sunxi/scripts/basic/ root@bpi:/usr/src/linux-headers-4.3.0-sunxi/scripts/basic# file fixdep fixdep: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=6852442a0a099c53c54516da788bcb41eb855d61, not stripped root@bpi:/usr/src/linux-headers-4.3.0-sunxi/scripts/basic# uname -a Linux bpi 4.3.0-sunxi #34 SMP Thu Nov 12 16:08:33 CET 2015 armv7l armv7l armv7l GNU/Linux from Igor source I thought it would be ok but nope I ended getting this quick solution root@bpi:/usr/src/linux-headers-4.3.0-sunxi# make scripts HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/bin2c [...] root@bpi:/usr/src/linux-headers-4.3.0-sunxi# file scripts/basic/fixdep scripts/basic/fixdep: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=e21986187584d701fa8f4d5d987a9cee808208c8, not stripped and of course root@bpi:/usr/src/test# ls hello-1.c Makefile root@bpi:/usr/src/test# make make -C /lib/modules/4.3.0-sunxi/build M=/usr/src/test modules make[1]: Entering directory `/home2/src/linux-headers-4.3.0-sunxi' CC [M] /usr/src/test/hello-1.o Building modules, stage 2. MODPOST 1 modules CC /usr/src/test/hello-1.mod.o LD [M] /usr/src/test/hello-1.ko make[1]: Leaving directory `/home2/src/linux-headers-4.3.0-sunxi' root@bpi:/usr/src/test# insmod hello-1.ko root@bpi:/usr/src/test# lsmod | grep hello hello_1 799 0 ok, as zador.blood.stained wrote about issue with builddeb => anything related I have a patching issue in "scripts" folder ? root@bpi:/usr/src/linux-headers-4.3.0-sunxi/scripts/package# cat builddeb builddeb builddeb.orig builddeb.rej root@bpi:/usr/src/linux-headers-4.3.0-sunxi/scripts/package# cat builddeb.rej --- scripts/package/builddeb +++ scripts/package/builddeb @@ -110,13 +112,17 @@ BUILD_DEBUG="$(grep -s '^CONFIG_DEBUG_INFO=y' $KCONFIG_CONFIG || true)" # Setup the directory structure -rm -rf "$tmpdir" "$fwdir" "$kernel_headers_dir" "$libc_headers_dir" "$dbg_dir" +rm -rf "$tmpdir" "$fwdir" "$kernel_headers_dir" "$libc_headers_dir" "$dbg_dir" "$dtb_dir" mkdir -m 755 -p "$tmpdir/DEBIAN" mkdir -p "$tmpdir/lib" "$tmpdir/boot" "$tmpdir/usr/share/doc/$packagename" mkdir -m 755 -p "$fwdir/DEBIAN" mkdir -p "$fwdir/lib/firmware/$version/" "$fwdir/usr/share/doc/$fwpackagename" mkdir -m 755 -p "$libc_headers_dir/DEBIAN" mkdir -p "$libc_headers_dir/usr/share/doc/$libc_headers_packagename" + +mkdir -m 755 -p "$dtb_dir/DEBIAN" +mkdir -p "$dtb_dir/boot/dtb" "$dtb_dir/usr/share/doc/$dtb_packagename" + mkdir -m 755 -p "$kernel_headers_dir/DEBIAN" mkdir -p "$kernel_headers_dir/usr/share/doc/$kernel_headers_packagename" mkdir -p "$kernel_headers_dir/lib/modules/$version/" thanks! Guillaume PS: fyi, lamobo-r1 : sunxi-ss (kernel tests) & prng ok, AC97=> KO not recognized maybe DTB needs a fix

my bad, I haven't followed precisely the pieces of advice from http://www.armbian.com/using-armbian-tools/

fyi, just ordered xu4 (+ related mini NAS box) for my Xmas joy or Xmas headache read tkaiser about odroid c1+ and found xu4 charming (at least some v4.2 support). => so I would be happy to test when needed. Sounds better to stay safe home in Paris this days so rpi2, labomo-r1 & xu4 are life saving expenses :-)

Hi zador.blood.stained, YES that's why I wanted to have an option (DEBUGKBUILD or whatever keyword "Team Igor" would find nice) to be able to read compilation errors when patching or testing weird config. As stated to Igor, "you cannot imagine the weird things your armbian users can do with this tool"

Hi Igor, Hi Buddies, with the new changes of *.sh files because of "2>&1" you cannot figure out the compilation errors -- or if any staling questions like patching file tools/include/tools/be_byteshift.h patching file tools/include/tools/le_byteshift.h dpkg-deb: building package `linux-firmware-image-next-sunxi' in `../linux-firmware-image-next-sunxi_4.6_armhf.deb'. gzip: ./debian/dtbtmp/usr/share/doc/linux-dtb-next-sunxi/changelog.Debian.gz already exists; do you wish to overwrite (y or n)? so I have tried and would suggest the following changes in common.sh (or anything better for bash conditional piping) #make $CTHREADS ARCH=arm CROSS_COMPILE="$CCACHE arm-linux-gnueabihf-" zImage modules 2>&1 | dialog --backtitle "$backtitle" --progressbox "Compiling kernel $CCACHE ..." 20 80 MKE="make $CTHREADS ARCH=arm CROSS_COMPILE=\"$CCACHE arm-linux-gnueabihf-\" zImage modules" [[ $DEBUGKBUILD = "" ]] && MKE="${MKE} 2>&1 | dialog --backtitle \"$backtitle\" --progressbox \"Compiling kernel $CCACHE ...\" 20 80" eval $MKE #make $CTHREADS ARCH=arm CROSS_COMPILE="$CCACHE arm-linux-gnueabihf-" dtbs 2>&1 | dialog --backtitle "$backtitle" --progressbox "Compiling DTB $CCACHE ..." 20 80 MKE="make $CTHREADS ARCH=arm CROSS_COMPILE=\"$CCACHE arm-linux-gnueabihf-\" dtbs" [[ $DEBUGKBUILD = "" ]] && MKE="${MKE} 2>&1 | dialog --backtitle \"$backtitle\" --progressbox \"Compiling DTB $CCACHE ...\" 20 80" eval $MKE #make -j1 $KERNEL_PACKING KDEB_PKGVERSION=$REVISION LOCALVERSION="-"$LINUXFAMILY KBUILD_DEBARCH=armhf ARCH=arm DEBFULLNAME="$MAINTAINER" \ #DEBEMAIL="$MAINTAINERMAIL" CROSS_COMPILE="$CCACHE arm-linux-gnueabihf-" 2>&1 | dialog --backtitle "$backtitle" --progressbox "Packing kernel $CCACHE ..." 20 80 MKE="\ make -j1 $KERNEL_PACKING KDEB_PKGVERSION=$REVISION LOCALVERSION=\"-\"$LINUXFAMILY KBUILD_DEBARCH=armhf ARCH=arm DEBFULLNAME=\"$MAINTAINER\" \ DEBEMAIL=\"$MAINTAINERMAIL\" CROSS_COMPILE=\"$CCACHE arm-linux-gnueabihf-\"\ " [[ $DEBUGKBUILD = "" ]] && MKE="${MKE} 2>&1 | dialog --backtitle \"$backtitle\" --progressbox \"Packing kernel $CCACHE ...\" 20 80" eval $MKE including in compile.sh DEBUGKBUILD="yes" # if "yes" then remove dialog for debug else "" for nice dialog style Cheers, Mr Poor 12.34 €

another set of tests, "not bad" btw

@tgirod really unsure (there is an automatic set-up on the first boot of a fresh Armbian install, all is set-up on 2nd boot) because I have started applying the "dpkg-reconfigure" section from http://www.armbian.com/documentation/ then creating my non-root user @Igor, the page really needs to be split (or one page with quick "menu entries") proposal: * Quick FAQ for beginners? * After install Armbian set-up? * How to unbrick the system? * How to install to NAND, SATA & USB? * How to build Armbian?

@Fransua All of my issues dissapeared when applying instructions from https://github.com/igorpecovnik/lib/blob/second/documentation/geek-faq.md @Igor ok, the instructions can be found in http://www.armbian.com/documentation/ Would it be nicer to link "geek-faq.md" as a "README for using Armbian tools", please? thanks (too many pieces of info kills the interesting piece of info!)

Partial dieharder testing see attachment

just a quick "diehard" on a 100 MB search "Allwinners" in the table dieharder running currently for 10 hours and pending looks ok (125 GB of /dev/hwrng and running)

ok testing A20 prng BW is 4MB/s will give results from dieharder later FYI remade a patch for 4.3.0 kernel with last bug fix + http://sunxi.montjoie.ovh/patch for the "prng" including a "huge" .config file for 4.3.0

testing ccache... very impressive speed! with my VM (4 cores/4GB) kernel 4.2.5 compilation + debs: *without ccache: 40-45 minutes *with ccache: 10 minutes

ytn, thanks for the patch, you have spared me some time ss seems to work in /proc/crypto Linux version 4.3.0-sunxi (root@server1404) (gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) ) #8 SMP Sat Nov 7 16:55:14 CET 2015 name : ecb(des3_ede) driver : ecb-des3-sun4i-ss module : sun4i_ss selftest : passed internal : no driver : cbc-des3-sun4i-ss driver : ecb-des-sun4i-ss driver : cbc-des-sun4i-ss driver : ecb-aes-sun4i-ss driver : cbc-aes-sun4i-ss driver : sha1-sun4i-ss driver : md5-sun4i-ss I am unsure about "just" a ./compile.sh mainline as one need to be careful with patch management & kernel config in Igor's Armbian tools

hi ytn, in configuration.sh just replace "stable" by "mainline" and also comment non relevant patches in patching.sh kernel 4.3.0 compiles ok, working also, but new features as sunxi-ss are not working I get [ 5.097091] sun4i-ss 1c15000.crypto-engine: no reset control found [ 5.098655] sun4i-ss 1c15000.crypto-engine: Die ID 0 [ 5.098672] sun4i-ss 1c15000.crypto-engine: Fail to register md5 [ 5.098947] sun4i-ss: probe of 1c15000.crypto-engine failed with error -22 otherwise the patch to test the sunxi prng doesn't work. Other new features seem to have no effect.

ok thxs tkaiser. ok I read about 256MB avail but 512MB has already started limited production, so good stuff with hardware NAT my main labomo issue (despite bridging & upnp) is BW is cpu limited (too many IRQs) so my 500Mbits/s internet is limited to 360 Mbits/s : DMA broken in 4.2.5 kernel? [ 5.556794] sun7i-dwmac 1c50000.ethernet: no reset control found [ 5.556823] Ring mode enabled [ 5.556832] No HW DMA feature register supported [ 5.556839] Normal descriptors [ 5.556845] TX Checksum insertion supported I hope they may consider MT7623A (details) for their next board ARM SoC instead of MIPS arch. Mipsbian would give our Armbian angel Igor too many headaches

@Igor testing beta Armbian 4.6 kernel 4.2.5-sunxi => link is here: FIXED or NON-ISSUE thanks! gr@bpi:~$ ll /lib/modules/4.2.5-sunxi/ total 1272 drwxr-xr-x 3 root root 4096 Nov 1 21:34 ./ drwxr-xr-x 4 root root 4096 Nov 1 21:32 ../ lrwxrwxrwx 1 root root 34 Nov 1 21:07 build -> /usr/src/linux-headers-4.2.5-sunxi/ drwxr-xr-x 9 root root 4096 Nov 1 21:34 kernel/ -rw-r--r-- 1 root root 363960 Nov 1 21:07 modules.alias -rw-r--r-- 1 root root 371810 Nov 1 21:07 modules.alias.bin -rw-r--r-- 1 root root 15005 Nov 1 21:07 modules.builtin -rw-r--r-- 1 root root 17938 Nov 1 21:07 modules.builtin.bin -rw-r--r-- 1 root root 84867 Nov 1 21:07 modules.dep -rw-r--r-- 1 root root 132053 Nov 1 21:07 modules.dep.bin -rw-r--r-- 1 root root 128 Nov 1 21:07 modules.devname -rw-r--r-- 1 root root 41209 Nov 1 21:07 modules.order -rw-r--r-- 1 root root 55 Nov 1 21:07 modules.softdep -rw-r--r-- 1 root root 104578 Nov 1 21:07 modules.symbols -rw-r--r-- 1 root root 133118 Nov 1 21:07 modules.symbols.bin

@badrianiulian I wouldn't bother much regarding the spec https://wikidevi.com/wiki/Ralink_RT5572 better using a wifi usb key "ready to play" as AP @tkaiser Thanks for your interesting web research WiTi board has not enough RAM for me Omnia is promising as a router (they are related to CZ.NIC CZ DNS authority) but not polyvalent enough for my personal needs

Rui, configuring hostapd.conf with HT40 + other options will make you have 300Mbits/s but don't waste your time any longer. I have stopped fighting with the onboard wifi (drivers, new pair of 9dBi antennas, etc.) I have switched back to my Wifi USB key Dlink 160-B1 @2.4GHz which is perfect for my needs "Problem solved" for me

unsure what you are looking for... if using vlan with lamobo, you need a trick to make vlan appear as tcpdump is not "meant for" vlan sudo tcpdump -i eth0 -Uw - | tcpdump -v -en -r - vlan sudo tcpdump -i eth0 -Uw - | tcpdump -v -en -r - vlan 102 ref. http://virtualtechnotes.com/linux-administration/linux-networking/tcpdump-filter-802-1q-tagged-traffic http://serverfault.com/questions/544651/vlan-tags-not-shown-in-packet-capture-linux-via-tcpdump (same issue on linux amd64 or arm)

Strange! you mention "Linux udoo 4.2.3-udoo" the iptables modules are enabled in vanilla but not in the legacy kernel for udoo legacy: https://github.com/igorpecovnik/lib/blob/second/config/linux-udoo-neo.config vanilla: https://github.com/igorpecovnik/lib/blob/second/config/linux-udoo-next.config waiting for a better piece of advice in the meantime... what do you have in the folders ls -l /lib/modules/4.2.3-sunxi/kernel/net/netfilter/ ls -l /lib/modules/4.2.3-sunxi/kernel/net/ipv4/netfilter/

I have switched back to the armbian kernel and wifi driver I have just tested a copper heatsink on the lamobo USB chipset (also added one copper pad on the switch chipset) it seems the wifi signal is far more stable (within a 5 dB margin) and noticed so far a 5-10 dB lesser noise than previously note: My Dlink 160 (B1) as AP is still 10dB better. So far: - the heatsink is probably improving thermal condition - it is so large compared to the chipset... maybe a minor shielding effect