wildcat_paris

Hi
 
Back in February '15 I have started to write an instruction about the setup of a BPi-R1 (Router).
In the threads of the Forum, the information is scattered and it takes so much time for each to get along.
So I thought such a document would help to become not only faster, but to achieve a better result as well, as you can faster spend time with the device and tweak it.
My know how is getting better, but things are still missing.
If you like to help the 'community' with your know how, please leave comments in the document if you find errors or you find something missing.
 
Google Docs 
 
Thank you in advance - for your support
 
Cheers
Tido

"Help yourself and Armbian will help you. ARMen."

"Help yourself and Armbian will help you. ARMen."

quick update (2015/11/27)
 
the Odroid XU4 is running Archlinux ARM as for now with kernel 3.10.92 (ok it is creepy)
 
more ARM generic 4.2/4.3/4.4-rc2 are online, won't test it so far, testing what I can get of the hardware.
 
The XU4 is able to compile thunderbird 38.4.0 with lightning (with ccache) on a SSD, quite powerful.

Hello,
 
Interested in replacing virtualbox as a VM host, "docker" tool seems to be able to run on Debian/Ubuntu/other linux distro/MacOS/Windows (as they claim)
 
 
 
My test:
 
1/
Installing docker on my amd64 4-cores Ubuntu 14.04 (too much tweaking to run "armbian" properly)
see doc here also I have been using "Create a Docker group" and don't forget to run "Hello World" test
 
2/
To create a new container with Ubuntu 14.04 (if you have added docker group to your non-privileged user, if not use "sudo")
 
$ docker run --privileged -i -t ubuntu:14.04 /bin/bash
 
"privileged" is needed for /dev/loop operations, if not the container cannot see the loop device, btw it is less "secure" but not "really" applicable here, I am on my test system.
 
on the host system, the files are stored in "/var/lib/docker", you can move this folder on another HDD/SSD, then you need to (in my example) "cd /var/lib; ln -s /home4/docker docker"
 
3/
once you have the root shell of the VM
 
# mkdir /root/armbian
# cd /root/armbian
 
then feel free to follow the Armbian tool instructions
 
Once all is compiled & package, you can transfer the files with "sftp", "ftp", etc. Or if you want a challenge, grab the files in /var/lib/docker (good luck!)
 
4/
later to come back to the container, list the containers, get the "Container ID" then start the container
$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e12d3a2b9263 ubuntu:14.04 "/bin/bash" About an hour ago Up About an hour grave_ardinghelli d1efa716ad64 hello-world "/hello" 8 hours ago Exited (0) 8 hours ago elegant_meitner $ docker start -i e12d3a2b9263 (to be tested more carefully)
 
edit:
you need the "under work" script attached as the ubuntu:14.04 is *not* really a ubuntu server packaged style!
 
edit2:
[ o.k. ] Fixing release custom applications. [ jessie ] [ o.k. ] Install board specific applications. [ lamobo-r1 ] [ o.k. ] Fingerprinting. [ Armbian 4.6 Lamobo-r1 Debian jessie next Linux 4.2.6 ] [ o.k. ] Creating boot scripts [ lamobo-r1 ] [ o.k. ] Possible after install. [ o.k. ] Writing boot loader [ /dev/loop1 ] [ o.k. ] Shrink image last partition to [ minimum ] [ o.k. ] Create and sign [ Armbian_4.6_Lamobo-r1_Debian_jessie_4.2.6.zip ] [ o.k. ] Runtime [ 81 min ] et voilà !
 
more testing needed

Hello,
 
Interested in replacing virtualbox as a VM host, "docker" tool seems to be able to run on Debian/Ubuntu/other linux distro/MacOS/Windows (as they claim)
 
 
 
My test:
 
1/
Installing docker on my amd64 4-cores Ubuntu 14.04 (too much tweaking to run "armbian" properly)
see doc here also I have been using "Create a Docker group" and don't forget to run "Hello World" test
 
2/
To create a new container with Ubuntu 14.04 (if you have added docker group to your non-privileged user, if not use "sudo")
 
$ docker run --privileged -i -t ubuntu:14.04 /bin/bash
 
"privileged" is needed for /dev/loop operations, if not the container cannot see the loop device, btw it is less "secure" but not "really" applicable here, I am on my test system.
 
on the host system, the files are stored in "/var/lib/docker", you can move this folder on another HDD/SSD, then you need to (in my example) "cd /var/lib; ln -s /home4/docker docker"
 
3/
once you have the root shell of the VM
 
# mkdir /root/armbian
# cd /root/armbian
 
then feel free to follow the Armbian tool instructions
 
Once all is compiled & package, you can transfer the files with "sftp", "ftp", etc. Or if you want a challenge, grab the files in /var/lib/docker (good luck!)
 
4/
later to come back to the container, list the containers, get the "Container ID" then start the container
$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e12d3a2b9263 ubuntu:14.04 "/bin/bash" About an hour ago Up About an hour grave_ardinghelli d1efa716ad64 hello-world "/hello" 8 hours ago Exited (0) 8 hours ago elegant_meitner $ docker start -i e12d3a2b9263 (to be tested more carefully)
 
edit:
you need the "under work" script attached as the ubuntu:14.04 is *not* really a ubuntu server packaged style!
 
edit2:
[ o.k. ] Fixing release custom applications. [ jessie ] [ o.k. ] Install board specific applications. [ lamobo-r1 ] [ o.k. ] Fingerprinting. [ Armbian 4.6 Lamobo-r1 Debian jessie next Linux 4.2.6 ] [ o.k. ] Creating boot scripts [ lamobo-r1 ] [ o.k. ] Possible after install. [ o.k. ] Writing boot loader [ /dev/loop1 ] [ o.k. ] Shrink image last partition to [ minimum ] [ o.k. ] Create and sign [ Armbian_4.6_Lamobo-r1_Debian_jessie_4.2.6.zip ] [ o.k. ] Runtime [ 81 min ] et voilà !
 
more testing needed

Ah, one thing I forgot to mention: The older the disks the more they often consume (applies especially to peak current needed at disk spin-up). And you might also end up with the LCC problem (LCC --> load cycle count): many 'green' 2.5" HDDs suffer from this problem when running with linux: the drive's firmware parks the drive's heads every few seconds in a landing zone just to let the kernel unramp them a few seconds later.
 
Be prepared to install both smartmontools and hdparm and watch/adjust the relevant parameters (preventing increasing LCC counters and sane spin-down timeouts). If your disk doesn't support automatic spindown, it's time to give hdd-spindown.sh a try: https://github.com/lynix?tab=repositories
 
With Armbian it's easy to put the rootfs on a connected SATA disk. But unless it's an SSD I normaly refuse to do so and stay with the rootfs on SD-card with Igor's default settings (check /etc/fstab for details) and put only 'application data' on disk. With this setup I manage high spindown times since the disk only runs when really needed.

Absolutely second that. This is the most time saving approach. Unless the devices mentioned here are ready I would always prefer that solution after spending so many hours with the rubbish R1.

Hey. 
 
Take a look on threads where we discuss about R1 troubles to see why the most obvious solution might not be the right one. Than if you want to have a good wireless coverage no onboard solution is perfect. Perhaps the best / most stable one is Cubietruck / BananaPRO. But since you are going to use this in a bar, you need to have in mind the limitation of wireless users. All clients (i think max is 5) need to share 56Mbit network speed which will be very bad in peek hours.
 
Bottom line. Perhaps a decent dual band gigabit wireless router + any A20 based banana / cubie / olimex will be much better / realistic solution. 

Here is my "secret" workaround
 
1. Rebuild inside chroot and repack.
https://github.com/igorpecovnik/lib/blob/second/boards.sh#L224
 
2. Before packing this patch is also needed - I do it within buildeb process:
https://github.com/igorpecovnik/lib/blob/second/patch/misc/headers-debian-byteshift.patch
 
I also needed few moments to recall how I solved this issue. 
 
Since kernel 4.3 has some changes within packaging process this workaround might stop working ... 

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

Currently I have done it in this way...
clear echo "chroot "$DEST"/cache/sdcard /bin/bash" read -p "Press any key..." closing_image in main.sh.
 
But, if I close the image. Are the changes stored for a "new" session.
I think, I will loose the changes, if I run the script again ?!

Ok mate, but keep in mind the source of this problem can be in: corrupted system image, weak power adapter for your Lime2 board (there are lot of power adapters dropping voltage under load below "safe" values and only few good ones on the market), microSD or SD card has been removed after transferring system image too early (these card are slow and it still takes time to write all data even system say 100% written) or card reader is plugged in internal or external hub which is underpowered and causes data corruption during transfers.

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.

OK, thank you for this! I have to pull back those 99%  if we look from this perspective. None of those is cleaned to such degree at least not by me or not by my knowing.
 
Why do we need blobs? I was speaking generally - for all boards. I added for Cubox wifi, Intel mPci that I use and some popular Realteks which come on USB.
 
First question is - what do we loose by moving to cleaned / libre kernel?
 
My primary goal within Armbian is to maintain a base system / kernel and that already become a hard job. I support and like the idea of blob free kernel but am currently supporting 6 different kernels. I would need a help to change this.

Hello,
 
My name is GNUser and as the name implies, I use GNU system
For privacy and security reasons (though also some philosophical ones) I decided to run only free software on my machines. For example my laptop has Trisquel installed which is a FSF approved distro. I also use Debian a lot, with the main repository only available (other repositories might contain or suggest non-free software).
 
My question is this: the images of armbian available here, I understand they are built on top of debian, but which kernel are they using? The kernel that Debian usually provides (for x86/64) is a debblobed kernel, with no proprietary pieces. Is that the case with these images?
Also, in terms of drivers, firmware and repositories, do these include any non-free stuff?
 
I understand a lot of people probably don't care about free vs open source, and I am fine with that. I believe we can work together anyway, and I am jsut asking so I know which pieces of software I would have to replace (if possible at all).
 
 
Thanks!

The kernel(s) which we are using are blob free but within distribution there are blobs for wireless chips. Feel free to remove the firmware package to be fully on the GNU side I can mention that we are also using a blob for NAND loading on some boards but this will be solved once.
 
Most used kernel in Armbian are:
github.com/linux-sunxi/linux-sunxi (slowly going out) www.kernel.org (now and future) Is this more or is this less open source than Debian stock kernel? 
 
Generally I can declare this as an 99% GNU project.

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.

@wildcat_paris
 
Yes, it's better this way.
 
geekfaq removed http://www.armbian.com/documentation/
geekfaq added http://www.armbian.com/using-armbian-tools/

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]

Hi Wilcat,
 
Thanks for the response. The sunxi-ss has a bug... that's primarily the reason I wanted to test 4.3.
 
I emailed the driver developer about that error. He has submitted a patch to fix that problem... here's a link to the patch request:
 
https://lkml.org/lkml/2015/11/5/91
​

Added 1. and 2. (need to fix few other things than commit). Tnx.
 
 
It's possible that deb-pkg is broken. This used to work fine?
 
I will also research this topic further ...
 
ADD #1: 

We need to compile deb-pkg the same way and it's fine
CROSS_COMPILE="ccache arm-linux-gnueabihf-"
 
ADD #2
 
Kernel 4.2.5 compilation + debs. Xeon E3 1231v3 @3.8Ghz, enough RAM & Crucial BX100
 
Compilation speed: 1 min 40s with ccache and 6 min 20s without

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.

Yes, this is not important.
 
But. I made some important fix yesterday so please update because I broke u-boot writing few days ago.

@Bino
This patch implementation is o.k. at the current script setup.
if [[ $BOARD == cubieboard2 ]] ; then However I have no idea if those patches are operational. If you succeed we can add them to default building.
 
@Zador
 
I just fixed broken patches and update configuration. 4.3 can be built and older 4.x kernels also works.