zador.blood.stained

I added extra info message to patching function, this should help a bit
[ o.k. ] Started patching process for [ u-boot u-boot-next 2015.10 ] [ o.k. ] Looking for user patches in [ userpatches/u-boot/u-boot-next ]

@wildcat_paris,
Did you make and install board-specific package (linux-trusty-root-next-lamobo-r1_5.00_armhf.deb or something similar)?
I ran 
./compile.sh BRANCH=next BOARD='lamobo-r1' KERNEL_ONLY=yes PROGRESS_DISPLAY=plain RELEASE=trusty  [ o.k. ] Building deb package. [ linux-trusty-root-next-lamobo-r1_5.00_armhf.deb ] #dpkg-deb -c linux-trusty-root-next-lamobo-r1_5.00_armhf.deb | grep '/usr/local/bin' drwxr-xr-x root/root 0 2015-12-14 16:06 ./usr/local/bin/ -rwxr-xr-x root/staff 15531 2014-06-03 13:17 ./usr/local/bin/temper -rwxr-xr-x root/root 25528 2015-12-14 16:06 ./usr/local/bin/meminfo -rwxr-xr-x root/root 27244 2015-12-14 16:06 ./usr/local/bin/nand-part -rwxr-xr-x root/root 46614 2015-12-14 16:06 ./usr/local/bin/sunxi-fexc -rwxr-xr-x root/root 34868 2015-04-02 19:37 ./usr/local/bin/swconfig -rwxr-xr-x root/root 16943 2015-12-14 16:06 ./usr/local/bin/brcm_patchram_plus Files are present in board support package, but as far as I see this package is not installed to image, maybe Igor didn't finish this part yet.

Just a note, name Odroid XU4 sounded familiar to me, and I remembered that I saw some notes about it in comments in an article I linked here.
Since it's in Russian, TL;DR translation:
Pros (compared to cubietruck and RPi2):
Small form factor Better performance (subjective) USB3.0 GBit network faster than on cubie Barrel plug DC in (compared to RPi I guess) Cons:
2.0mm GPIO headers with plastic "walls" surrounding them GPIO TTL voltage 1.8v, hard to find compatible periphery Very loud stock cooler, but speed can be lowered in software/by script With stock cooler throttling starts after 2-3 minutes with 2 cores loaded by cpuburn, temperature readings - 97°C With non-stock coolers (one with heat pipes and another without) throttling after 6-8 minutes with 4 cores Feels like SoC "body" plastic material has poor thermal conductivity (note from me - and/or internal temperature sensor readings are not accurate) "Normal" for these devices software/kernel support problems After all experiments and putting stock cooler back board died after ~1 hour, shorted power somewhere

Yes, thanks. I already have this on my todo list for unmounting loop devices after debootstrap process.

I already did something like that, prepare_host function duplicates directory structure from lib/patch to userpatches

Then it must be packaging error, not compiling. I didn't touch it (yet) and so didn't test it. Maybe will check later.

I think it's more right to declare relationship between kernel packages so they cannot be installed at the same time.
If I understand this right, it should be something like this in the kernel package control file:
Provides: linux-image Conflicts: linux-image Replaces: linux-image Right now it doesn't have "Conflicts" and "Replaces" fields.
➜ ~ % apt-cache show linux-image-next-sunxi Package: linux-image-next-sunxi Status: install ok installed Priority: optional Section: kernel Installed-Size: 14180 Maintainer: Igor Pecovnik <****l.com> Architecture: armhf Source: linux-4.3.0-sunxi Version: 4.6 Provides: linux-image, linux-image-2.6, linux-modules-4.3.0-sunxi Suggests: linux-firmware-image-next-sunxi Description: Linux kernel, version 4.3.0-sunxi This package contains the Linux kernel, modules and corresponding other files, version: 4.3.0-sunxi. Description-md5: 117a3231b09bf7ccdf0ae5d4ec6b8c5f Homepage: http://www.kernel.org/ Edit:
This is only the beginning  I mean, beginning of improvement, not of introducing tons of bugs, I hope 

My logic with oldconfig/olddefconfig is:
if KERNEL_CONFIGURE is true, then process is designed to be interactive and it will ask about new options before bringing menu configuration dialog;
otherwise process is not interactive, and it won't ask users about some new kernel options if they don't want to mess with kernel configuration at all, safe defaults will be assumed for new options.
 
If you don't like this, you can change it to always be oldconfig, it's not 100% needed.
 
Make *config right now doesn't use dialog as far as I see.
 
I'll try to implement this next.

Implemented something similar: https://github.com/zador-blood-stained/lib/commit/8e1551e9faef962d4abca603fe6d8f88d377075b, Igor can merge this if he likes it.
Options are not documented in compile.sh for now and are not dependent on each other. Affect only kernel & u-boot compilation for now.
USE_DIALOG is enabled by default,
USE_DIALOG_LOGGING is disabled by default; writes to output/debug/compilation.log if enabled (also deletes this file before new compilation).

Fixed dtb compilation (removed extra space in 0013-lamobo_r1_dts.patch at the beginning of the line).
Mainline kernel compilation is working.
[ o.k. ] Kernel building done [ @host ] [ o.k. ] File name [ linux-image-next-sunxi_5.00_armhf.deb ] [ o.k. ] Runtime [ 4 min ] BTW, you can add my repo as another remote and merge commits or even branches from it, this way it will be easier for me to merge your changes back into my working copy (and it may be faster and easier for you).
 
Edit: some config names are broken after configuration update:
[ o.k. ] Compiling kernel [ @host ] cp: cannot stat ‘/home/zador/armbian/lib/config/linux-sun7i-default.config’: No such file or directory

Hm. I tested it briefly on cubietruck sun7i kernel, it got all patches from /lib and it skipped fbtft patch when I created empty file userpatches/kernel/sun7i-default/fbtft_for_older.patch
I'm waiting for your solution to passing correct LINUXFAMILY to patching function to do proper tests.
What exactly did you test?
 
Edit: Just checked. Works like intended for me
➜ ~ % cd armbian/userpatches/kernel/sun7i-default ➜ sun7i-default % _ cp ~/armbian/lib/patch/kernel/small_lcd_drivers.patch test-patch.patch ➜ sun7i-default % ~ ➜ ~ % armbian ➜ armbian % ./compile.sh BOARD=cubietruck KERNEL_ONLY=yes BRANCH=default .... .... [ o.k. ] ... test-patch.patch sun7i-default 3.4.104 [ succeeded ]

https://github.com/zador-blood-stained/lib   Changelog:   Edit: made some fixes
 
Testing patching process: for mainline stable kernel "$LINUXFAMILY-$BRANCH" parses to "sun7i-next" or "sun4i-next" instead of "sunxi-next". Is this a bug or a feature? 
 
Edit 2: pushed advanced_patching changes. Mainline patches are still broken due to wrong $LINUXFAMILY

That's unfortunate 
So do you mean that you'll start rewriting all again tomorrow or you will take a break for few days?

FYI, just noticed article (in Russian) describing ramlog implementation for systemd based distributions, extracted from RPi 2 image found on some german web site: http://habrahabr.ru/post/272279/
 
Small note from myself - it can be packed as debian package with pre/postinstall scripts to set it up, or just copied to fresh Armbian images, in which case it's better to stick main script in /usr/local/bin instead of /usr/bin
 
Edit: it doesn't have fallback startup script for sysvinit, but it's easy to create one.
Edit 2: I think it has copy-paste error in cron script name, it should be /usr/bin/ramlog instead of /usr/bin/crontab

Look at GPIO numbering scheme in mainline kernel here: https://linux-sunxi.org/GPIO
It is tied to SoC pin bank (port) numbers, so GPIO 1 would be pin PA01, and this pin (for A10/A20 CPUs) is probably used by network driver, so no wonder kernel crashed here.
You will need to calculate GPIO numbers for pins manually by their names (i.e. PG0 -> GPIO 192 if I'm not mistaken).

I checked mine 4.3 headers, and fixdep arch is also x86_64. I extracted fixdep from Igor's 4.2.3 kernel packages, and its arch is ARM.
 
From what I read about fixdep, it is used by make and its arch should match host arch, so when we compile kernel on x86_64 Ubuntu, fixdep should have x86_64 arch too. I can only guess that packaging process is wrong and compiled binaries from scripts folder should not be packed into deb files.
Related bug report: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/666267

AFAIK, bluetooth and Wi-Fi support on cubietruck (and other boards that use ap6210 module) requires firmware and if there are no FOSS drivers for this module (or they have limited functionality), @GNUser, I'm assuming you will personally answer every question about Wi-Fi or bluetooth not working after kernel upgrade? 
Right now, if I understand things correctly, firmware is provided as standalone package (linux-firmware-image-....deb) and you are free to not install it or remove it from your system.
If you can find and even test FOSS drivers for wireless modules that you can find on boards supported by this community (i.e. ap6210) and this driver supports HT40 and channels 12&13, this actually will be great.

I think I found the reason for gzip override prompt: this commit changed builddeb script https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/scripts/package/builddeb?id=8d740a37b92f3d4a0435fe263b32efc7f61c5efb
and this change conflicts with packaging-next.patch in Igor's repo, so $dtb_dir is not cleaned anymore.

Okay. Kernel 4.3 + allwinner-audio-4.x patch + 6 patches related to sun4i-codec + enabling CONFIG_DMA_SUN4I (and of course enabling CONFIG_SND_SUN4I_CODEC) in kernel config + understanding new weird mixer controls = onboard sound works.
➜ ~ % dmesg | grep sun4i-codec [ 8.566444] sun4i-codec 1c22c00.codec: Codec <-> 1c22c00.codec mapping ok ➜ ~ % aplay -l **** List of PLAYBACK Hardware Devices **** card 0: sun4icodec [sun4i-codec], device 0: CDC PCM Codec-0 [] Subdevices: 0/1 Subdevice #0: subdevice #0 Edit: for reference, proper mixer config looks like this right now:

 
Edit 2: Patches for sun4i-codec [file removed]

Okay. Kernel 4.3 + allwinner-audio-4.x patch + 6 patches related to sun4i-codec + enabling CONFIG_DMA_SUN4I (and of course enabling CONFIG_SND_SUN4I_CODEC) in kernel config + understanding new weird mixer controls = onboard sound works.
➜ ~ % dmesg | grep sun4i-codec [ 8.566444] sun4i-codec 1c22c00.codec: Codec <-> 1c22c00.codec mapping ok ➜ ~ % aplay -l **** List of PLAYBACK Hardware Devices **** card 0: sun4icodec [sun4i-codec], device 0: CDC PCM Codec-0 [] Subdevices: 0/1 Subdevice #0: subdevice #0 Edit: for reference, proper mixer config looks like this right now:

 
Edit 2: Patches for sun4i-codec [file removed]

Rebuilding kernel several times in a row, made some changes, that would be nice to have in build script by default, and also some thoughts on custom kernel patches.
 
1.Option to not overwrite kernel config before compilation.
Example: setting KERNEL_KEEP_CONFIG="yes" in build.sh
Changes (common.sh):
# use proven config if [ "$KERNEL_KEEP_CONFIG" != "yes" ]; then cp $SRC/lib/config/$LINUXCONFIG.config $SOURCES/$LINUXSOURCE/.config; fi 2. Option to use ccache for kernel compilation (at least). ccache can be set by creating symlinks for cross-compiling tools, but having an option in build script is more useful and easier IMHO.
Example: setting USE_CCACHE="yes" in build.sh
Changes (in common.sh):
if [ "$USE_CCACHE" = "yes" ] then make $CTHREADS ARCH=arm CROSS_COMPILE="ccache arm-linux-gnueabihf-" all zImage 2>&1 | dialog --backtitle "$backtitle" --progressbox "Compiling kernel ..." 20 70 else make $CTHREADS ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- all zImage 2>&1 | dialog --backtitle "$backtitle" --progressbox "Compiling kernel ..." 20 70 fi Also here stderr of compilation process is redirected to stdout so compiler warnings do not tear dialog window (2>&1).
Compiling kernel with ccache right now, will report if it breaks anything.
Looks like it doesn't like invoking make deb-pkg after compilation and tries to compile everything again, will test later other than this 4.3 related bug compilation works.
 
3. Automatically pick up and apply kernel patches from custom directory.
Something like this:
# in kernel souces root dir for patch in $SRC/patches/$KERNEL_TYPE/*.patch do patch -p1 < $patch done KERNEL_TYPE can be "next" or "legacy" to separate patches for different kernel branches. This can be extended to using device specific directories if necessary.

Current CAN patch (version 8) consists of 4 parts (driver itself, kernel configs, DT config) and can be found in follow-ups to this message: http://www.spinics.net/lists/netdev/msg343137.html
You'll need all 4 parts, and DT config also needs CAN section in device-specific sun7i-a20-cubieboard2.dts file, as by default in dtsi file CAN controller is disabled.
By the way, mainline kernel just updated from 4.2.5 to 4.3, so right now build process most likely will fail due to outdated kernel config.

I think that in sun7i-a20-cubieboard2.dts you need to change
leds { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <&led_pins_cubieboard2>; blue { label = "cubieboard2:blue:usr"; gpios = <&pio 7 21 GPIO_ACTIVE_HIGH>; }; green { label = "cubieboard2:green:usr"; gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>; }; }; to
leds { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <&led_pins_cubieboard2>; blue { label = "cubieboard2:blue:usr"; gpios = <&pio 4 11 GPIO_ACTIVE_HIGH>; }; green { label = "cubieboard2:green:usr"; gpios = <&pio 4 10 GPIO_ACTIVE_HIGH>; }; }; and
led_pins_cubieboard2: led_pins@0 { allwinner,pins = "PH20", "PH21"; allwinner,function = "gpio_out"; allwinner,drive = <SUN4I_PINCTRL_10_MA>; allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; }; to
led_pins_cubieboard2: led_pins@0 { allwinner,pins = "PE10", "PE11"; allwinner,function = "gpio_out"; allwinner,drive = <SUN4I_PINCTRL_10_MA>; allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; }; You'll need to recompile kernel (or at least device tree part) with build script to get new sun7i-a20-cubieboard2.dtb file.
Alternatively you can try to decompile, change and recompile dtb file with dtc from device-tree-compiler package, but I'm not sure if it will work.

Mainline kernel comes with new gpio driver with standart linux gpio interface, it doesn't need any DT configuration. You need to "export" pin number for it to appear in sysfs tree (I'm assuming you want sysfs access)
Read section "Accessing the GPIO pins through sysfs with mainline kernel" here: https://linux-sunxi.org/GPIO

FYI, I checked, using dtc from device-tree-compiler on device itself is an easier way to make such small changes in Device Tree config.
http://forum.armbian.com/index.php/topic/382-armbian-on-pcduino3/#entry2444
Decompiled dts looks a bit different compared to original, but it's easy to find LED related sections and values.