wildcat_paris

I can only agree. UUID will be very helpful when testing to boot a new image on SDcard while having a working system on eMMC (where you cannot remove the eMMC flash memory -- I only know hardkernel doing removable eMMC)

@jobenvil interesting piece of news. thanks so there is a way to make uboot 2016.05-dirty with hardkernel uboot dtb and blobs let's see if we can get rid of the boot partition ROOT_PATH=/media/root BOOT_PATH=/media/boot because that is the more annoying part uboot 2012.07 only dealing with FAT

@Petr I have little idea but I read overlayfs was available with kernel 3.18 (any backport to 3.10?) https://en.wikipedia.org/wiki/OverlayFS it looks there is CONFIG_OVERLAYFS_FS=m for legacy 3.10 https://github.com/igorpecovnik/lib/blob/master/config/kernel/linux-odroidxu4-default.config so check if you can load the kernel module -- "next" is vanilla kernel (recent) but for XU4 it is still experimental for Armbian just see http://forum.armbian.com/index.php/topic/2005-patching-the-kernel/ currently the default 'next' kernel config has # CONFIG_OVERLAY_FS is not set (try to load the legacy kernel module first please)

@dinokpir I am waiting for my replacement Turris Omnia as a "router" I am using the Lamobo-R1, my ISP provides internet on VLAN 835 so (in my particular situation) it is less likely someone hijacks the whole Lamobo-R1 Anyway, if you know the risks and try hard to lessen the risks, the Lamobo-R1 is usable, a little risky but if you dare to take the risks, ok.

@Gronfir 1/ Honestly I (personal opinion) cannot rely on Hardkernel for providing timely and accurate kernel for Odroid XU4 I have greatly appreciated that during Q2 2016 Samsung Opensource DEV team made some needed updates to vanilla kernel for XU4 and that's the only reliable work I have seen so far (and to test their updates they had to tweak Hardkernel images the best they could). "Jobenvil" is more following "tobetter" works he would express an opinion more accurate (less biased than me, I am annoyed by Hardkernel -- Hardkernel designs nice hardware (Orange Pi maker as well) but Hardkernel fails on software) 2/ in lib/configuration.sh ARMBIAN_MAINLINE_KERNEL_VERSION='4.7' MAINLINE_KERNEL_BRANCH=tag:v$(wget -qO- https://www.kernel.org/finger_banner | awk '{print $NF}' | grep -oE "^${ARMBIAN_MAINLINE_KERNEL_VERS you can find ARMBIAN_MAINLINE_KERNEL_VERSION variable. if it cannot be already overloaded by a configuration file, I may try to provide a small patch to set ARMBIAN_MAINLINE_KERNEL_VERSION='4.4' (or as you may like) (but I am unsure it would be ever accepted in the Armbian tool mainstream)

@Tido I guess soon something will emerge for Armbian (and/or Lamobo-R1) sake Probably not Team Green Arrow nor Team Flash nor Team Hunter neither Team Kara Maybe Team Armbian testing (Team Mikhail or Team Igor) but there is already Team Kaiser for testing (that is me modifying TK's posts, very efficient to make Thomas a little nervous to keep him working efficiently http://forum.armbian.com/index.php/topic/2062-test-team-testers/?view=getnewpost

I would help for Lamobo-R1 Odroid XU4

thinking of http://forum.armbian.com/index.php/topic/2043-lamobo-r1-520-swconfig-problem-with-last-520-armbian-update/?p=15773 We may ask the forum users and create a list of testers for each board (or family of boards) => we could create a sub forum Armbian/Tech/Dev/Armbian build framework/Testing/ - to call for testers when needed (testers would register a pined thread managed by Igor/Mikhail/Thomas/others) - to report testing on the forum using a title like [5.20/Lamobo-R1] "Status" (OK/KO/minor issues) - create bug reports in appropriate forum each registered testers creates its minimum set of test (like testing the switch config of Lamobo-R1) and create a thread as a reference (just an idea)

@dobriloff the Bananian switch.h has the same xypron/swconfig switch.h but looking at the diff of the 2 files (openwrt-mirror vs. Bananian), I am surprised the compilation can even work, there are many more enum-ed attributes. I am thinking of a conspiracy of Bananian over Lamobo-R1 users

@Rui please can you check? http://guillaume.romagny.free.fr/swconfig_0.1.0_armhf.deb (or https://github.com/xypron/swconfig)

@Mikhail while this one (generating swconfig*15.04*.deb) seems to be broken https://github.com/jekader/swconfig this one (also doing debian packaging "debuild -uc -us" and closer to openwrt) works ok https://github.com/xypron/swconfig edit: before using debuild -uc -us ./autogen.sh has to be launched (if not there is no binary)

@Mikhail if it can help the "old" swconfig has (with readelf) 0x00000001 (NEEDED) Shared library: [libdl.so.2] 0x00000001 (NEEDED) Shared library: [libc.so.6] the new one test1 0x00000001 (NEEDED) Shared library: [libnl-3.so.200] 0x00000001 (NEEDED) Shared library: [libnl-genl-3.so.200] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x00000001 (NEEDED) Shared library: [ld-linux-armhf.so.3] test2 0x00000001 (NEEDED) Shared library: [libnl-3.so.200] 0x00000001 (NEEDED) Shared library: [libnl-genl-3.so.200] 0x00000001 (NEEDED) Shared library: [libc.so.6] so as I am using Ubuntu 14.04 and the binary "looks like" for Ubuntu 15.04 Maybe there is a library issue. edit: I have the libnl-3 [gr@bpi:~] $ dpkg -l "libnl*" Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=============================-===================-===================-=============================================================== ii libnl-3-200:armhf 3.2.21-1ubuntu3 armhf library for dealing with netlink sockets ii libnl-3-dev 3.2.21-1ubuntu3 armhf development library and headers for libnl-3 un libnl-dev <none> <none> (no description available) ii libnl-genl-3-200:armhf 3.2.21-1ubuntu3 armhf library for dealing with netlink sockets - generic netlink ii libnl-genl-3-dev 3.2.21-1ubuntu3 armhf development library and headers for libnl-genl-3 ii libnl-route-3-200:armhf 3.2.21-1ubuntu3 armhf library for dealing with netlink sockets - route interface ii libnl1:armhf 1.1-8ubuntu1 armhf library for dealing with netlink sockets un libnl2-dev <none> <none> (no description available) un libnl3-dev <none> <none> (no description available) looking more closely I have libnl 3.2.21 it seems I would need libnl (network library) 3.2.24 maybe it is not related.

@Rui Cool, so we have a workaround solution for others Lamobo-R1 Armbian users

@zador.blood.stain it may look the binary has not been linked properly edit: the following doesn't mean anything (sorry) edit2: I am using Ubuntu 14.04.05 the deb files sounds like it is Ubuntu 15.04 edit3: I looked at objdump -D -M intel /sbin/swconfig but it is ASM and I don't read ASM fluently

ok, I uploaded my working binary, not a clean way but should be working http://guillaume.romagny.free.fr/swconfig.zip

@Rui check if you still have the old binary in /usr/local/bin/ whereis swconfig test it then overwrite the /sbin/swconfig so Zador has spare time to fix this problem

not sure about the "((null))" and the binary size is very short

@zador.blood.stain thanks, I thought I had a problem 2 days ago when I compiled the kernel (I copy/paste the swconfig binary from older debs) so I need to delete the old /usr/local/bin/swconfig edit: not yet thanks

You are welcome, thanks you for testing on your side, if you have more feedback, feel free until the Armbian DEV have time to deal with the kernel install issue (files put in /boot folder of root partition, not in /boot partition) and put infrastructure for UUID => use dpkg and move the files at the proper place (and have a backup first, you can "dd" your SD card into a file on a HDD/SSD) note: excepted for legacy stuff, dual partition boot is quite obsolete because vanilla version of uboot manage ext4 properly, so I guess not a top priority.

ok, it looks better but now you are using Vanilla kernel (4.x) I guess because of the dtb name (xu4 instead of xu3) fill the sdcard in another computer edit /etc/fstab and pick /dev/mmcblk1pX gr@gr /media/p2/etc $ cat fstab /dev/mmcblk1p2 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 /dev/mmcblk1p1 /boot vfat defaults 0 2 because the UUID feature is not a top priority (so far) edit: UUID is a nice workaround (and likely a standard now) anyway, if we could be using recent uboot, the kernel would handle properly the mmc0/1. the switch SD/eMMC on the XU4 should "define" the proper mmcblk0 (boot device) so we wouldn't have this problem. We can blame Hardkernel/Odroid for this. Even Samsung Opensource DEV have to DIY when they test their work on XU4

you are using a legacy 3.X kernel, so I guess the bootcmd is ok, it only needs the zImage and odroid xu3 dtb file I am out of options because I only tested on vanilla kernels && SD cards The only test I could propose you: create the whole image with Armbian and burn the SD card (to avoid the issue of installing the new kernel packages and dual partition issue). ** side note (I guess it is only for vanilla kernel -- uboot 2012.07 doesn't handle things nicely) the boot.ini I had to change: root=/dev/mmcblk1p2 (0=>1) uboot is confusing SD & eMMC (the workaround for vanilla kernel would be to use UUID in /etc/fstab and not /dev/mmcblk) #setenv bootrootfs "console=tty1 console=ttySAC2,115200n8 loglevel=1 root=/dev/mmcblk0p2 rootwait ro fsck.repair=yes" setenv bootrootfs "console=tty1 console=ttySAC2,115200n8 loglevel=1 root=/dev/mmcblk1p2 rootwait ro fsck.repair=yes" => So now I think: do you have the (expensive) Odroid 1.8V serial console plug? so you may see more piece of info

ok, I see here is an example -rwxr-xr-x 1 root root 6944 juin 30 00:59 boot.bmp -rwxr-xr-x 1 root root 8719 juin 30 00:55 boot.ini -rwxr-xr-x 1 root root 112004 juil. 17 00:46 config-4.6.4-odroidxu4 drwxr-xr-x 2 root root 2048 juil. 17 00:45 dtb drwxr-xr-x 2 root root 4096 juil. 17 00:39 dtb-4.6.4-odroidxu4 -rwxr-xr-x 1 root root 3164228 juil. 17 00:46 initrd.img-4.6.4-odroidxu4 -rwxr-xr-x 1 root root 1819916 juil. 17 00:46 System.map-4.6.4-odroidxu4 -rwxr-xr-x 1 root root 3164292 juil. 17 00:46 uInitrd -rwxr-xr-x 1 root root 4453704 juil. 17 00:46 vmlinuz-4.6.4-odroidxu4 -rwxr-xr-x 1 root root 4453704 juil. 17 00:47 zImage just duplicate the dtb-xxxxxxxx-odroidxu4 folder into dtb and cp vmlinuz-xxxxxxxx-odroidxu4 zImage (instead of a link, as you write, no link with FAT system) edit: just check the size of the files vmlinuz-4.6.4-odroidxu4 & zImage should match probably then you are done. Tell us, please edit: as a quick check look at boot.ini in my example setenv bootcmd "fatload mmc 0:1 0x40008000 zImage; fatload mmc 0:1 0x42000000 uInitrd; fatload mmc 0:1 0x44000000 dtb/exynos5422-odroidxu4.dtb; bootz 0x40008000 0x42000000 0x44000000" I need the following files: zImage & uInitrd & dtb/exynos5422-odroidxu4.dtb

b-tree concept is great but overload a b-tree and the performance will degrade (if not, increase the depth of the btree may help). ccache per SoC is an alternative to avoid bloating the ccache btree. It is probably durable over several "full" creation of images for all the boards. Well, the config is simple, it is only a matter of changing/exporting CCACHE_DIR with CCACHE_DIR=$DEST/ccache/per_$BRANCH_$LINUXFAMILY

FYI, for the next hour, Samsung EVO 32 GB (I hope genuine ones) are at 9 USD http://www.gearbest.com/memory-cards/pp_28060.html?wid=21 => ends at 18.30 CEST (and no... my forum account has not been hijacked)

zador.blood.stain has 1000 posts here (tuning) probably already written here ordering the mass compilation (not by board) but by SoC to reduce kernel compilation then ccache (pick as you need): - move ccache folder to ramdisk - tune to add one level in ccache b-tree (2=>3) - compress lightly the ccache results (there is an overhead) - or ccache hardlinks (so there is no files moved from ccache to the kernel tree) not compatible with ramdisk or compression maybe deleting ccache folder when ccache is bloated of hashes (there is a tweak: limit the number of files / ccache directory size / change the ratio of ccache replacement) OR creating a ccache folder per SoC (and removing the full directory from ccache hash) so less likely to overbloat the ccache tree (note: ccache per SoC could be an alternative of ordering compilation per SoC) just the goldfish_paris passing by https://github.com/igorpecovnik/lib/pull/466