Category: English


As I dicussed in previous article, I would like to run a BSP (Allwinner/sunxi) kernel to enable video acceleration on my BananaPi. Since the code from the LeMaker website is rather old and messy, it won’t compile with a recent compiler. Therefore I will get an image containing this kernel. The ArchLinuxARM image provided by lemaker is rather old (2014) and uses an ancient 3.4 kernel. I hope my system will even boot on such an artefact.

The Mainline U-boot seems to have support for BSP kernels, so just extracting the kernel and its modules should be enough. Therefore I will mount the image through kpartx. This tool allows to mount disk images with partitions. Running the tool creates partitions I can mount for the image.

[root@8570w bananapi]# kpartx ArchLinux_For_BananaPi_v1412.img 
loop0p1 : 0 102400 /dev/loop0 2048
loop0p2 : 0 7063552 /dev/loop0 104448
loop deleted : /dev/loop0
[root@8570w bananapi]# kpartx -a ArchLinux_For_BananaPi_v1412.img
[root@8570w bananapi]# mount /dev/mapper/loop0p1  mnt
[root@8570w bananapi]# ls mnt
script.bin  uEnv.txt  uImage
[root@8570w bananapi]# mkdir BSP_kernel
[root@8570w bananapi]# cp mnt/* BSP_kernel/

Here is another thing where we see the BSP kernel is rather old, as it still uses the uImage format, rather then the zImage kernels use nowadays. Furthermore, we notice a script.bin file. This is a binary created from a FEX file. It’s used to configure the SoC, things like PIN muxing and video resolution, and fixing the MAC address.

[root@8570w bananapi]# umount mnt
[root@8570w bananapi]# mount /dev/mapper/loop0p2  mnt
[root@8570w bananapi]# umount mnt
[root@8570w bananapi]# mount /dev/mapper/loop0p2  mnt
[root@8570w bananapi]# cp -r mnt/lib/modules BSP_kernel/

So, we have got the files we’re looking for, transferring them to the Banana Pi

[andre@8570w bananapi]$ scp -r BSP_kernel/ banana: 

And placing them

[root@banana BSP_kernel]# cp -r modules/* /lib/modules
[root@banana BSP_kernel]# cp * /boot     
cp: omitting directory 'modules'

The U-boot configuration by ArchLinuxARM first tries to load a mainline kernel (zImage) and if not present, it will try to load a BSP kernel (uImage), so by renaming the zImage, we should boot the old kernel.

[root@banana BSP_kernel]# mv /boot/zImage /boot/zImage_bak

However, it seems the bootloader isn;t entirely compatible with the old kernel after all:

Found U-Boot script /boot/boot.scr
833 bytes read in 101 ms (7.8 KiB/s)
## Executing script at 43100000
** File not found /boot/zImage **
4822936 bytes read in 380 ms (12.1 MiB/s)
50972 bytes read in 123 ms (404.3 KiB/s)
## Booting kernel from Legacy Image at 48000000 ...
   Image Name:   Linux-3.4.103
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4822872 Bytes = 4.6 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK

Starting kernel ...

<6>Booting Linux on physical CPU 0
<6>Initializing cgroup subsys cpuset
<6>Initializing cgroup subsys cpu
<5>Linux version 3.4.103 (bananapi@lemaker) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #1 SMP PREEMPT Thu Dec 18 13:07:12 CST 2014
CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache

Error: unrecognized/unsupported machine ID (r1 = 0x100010bb).


Error: unrecognized/unsupported machine ID (r1 = 0x100010bb).

Available machine support:

ID (hex)        NAME
Available machine support:

ID (hex)        NAME
000010bb        sun7i
000010bb        sun7i
0000102a        sun5i
0000102a        sun5i
00001008        sun4i
00001008        sun4i

Please check your kernel config and/or bootloader.

It seems the bootloader has set one bit the kernel doesn’t recognise. I could recompile U-boot with the option “Workaround for booting old kernels” under “ARM Architecture”. Now the kernel boots. Oh…. the BSP kernel, which by default flashes a LED when running. Rather annoying. However, the bootprocess gets stuck. I think this is because a 3.4 kernel is too old for systemd to work. Ancient kernels…. le sigh.

I’m going to burn the ancient image. I suppose it won’t be upgradable. But we’ll be sure whether it’s a kernel/systemd mismatch.

Logging in over serial fails, we can log in over ssh
it seems both
serial-getty@ttyS0.service
getty@ttyS0.service

are running, conflicting

[root@lemaker etc]# systemctl stop serial-getty@ttyS0.service 
[root@lemaker etc]# systemctl disable serial-getty@ttyS0.service 
[root@lemaker etc]# systemctl stop getty@ttyS0.service 
[root@lemaker etc]# systemctl start getty@ttyS0.service 

Since we’re running an AllWinner BSP image, we need to fix the fex file to have a static MAC.

[root@lemaker boot]# pacman -S sunxi-tools
[root@lemaker boot]# bin2fex script.bin script.fex

add

[dynamic]
MAC = "8a413f5bf892"

and run

[root@lemaker boot]# fex2bin script.fex script.bin

And while the mainline uboot enables the composite out by default, and even outputs the bootloader. From earlier experience with AllWinner/sunxi BSP kernels I know output is only enabled at some point during boot.

I have been debugging this for hours, turned out, the image from lemaker doesn’t mount the /boot partition, and in the /boot directory, the same files as I would expect on the boot partition where present. So I have been changing files that haven’t been loaded at all. To enable console, after mounting the boot parition!!!!! open uEnv.txt and make the disp. arguments look like disp.screen0_output_mode=pal disp.screen0_output_type=2

After all of this… I think I’ll finish up this article and go to the video acceleration and kodi, which was the original topic when I started writing, to another article. I will discuss one more thing and that will be systemd. The old image could be upgraded without problems

As the Banana Pi has mainline support in both U-boot and the Linux kernel, it should be fairly simple to make it run. ArchLinuxARM does not have u-boot for the Banana Pi compiled, but compiling it myself should be trivial. I am using the gcc cross compiler binaries provided by ArchLinuxARM. ( https://archlinuxarm.org/wiki/Distcc_Cross-Compiling )

The process to compile U-boot is explained at the sunxi website. When using the cross compiler from the ArchLinuxARM website, be sure to add it to the path. Furthermore, CROSS_COMPILE=arm-unknown-linux-gnueabihf- should be used. This is the thing that differs from most guides, which use a different cross compiler. After compiling, use the guide for the CubieBoard 2, and replace the u-boot-sunxi-with-spl.bin file with the file we compiled ourselves.

But it is still not working! The bootloader cannot find the kernel and is attempting netboot. When investivating I’ve found the following:

=> ext4ls mmc 0:1 /boot
<DIR>          0 .
<DIR>       4096 ..
=> ext4ls mmc 0:1 /etc
<DIR>       4096 .
<DIR>       4096 ..
            4096 zImage
<DIR>       4096 dtbs
               0 boot.scr

The bootloader has trouble reading the ext4 file system. When looking at the SD card from my laptop, everything looks fine

[root@8570w bananapi]# ls mnt/boot
boot.scr  dtbs	zImage

So… what is wrong? It seems there are file system features enabled that are not supported by U-boot, and that U-boot is not checking feature flags to detect this. When I realised this was the probable problem, I was able to verify this conclusion by a quick search. Therefore, the guide for the CubieBoard 2 should have one additional thing altered.

mkfs.ext4 -O ^metadata_csum,^64bit /dev/mmcblk0p2

With these alterations, running a mainline u-boot and kernel works fine. Nevertheless, the mainline kernel has no video acceleration support yet. As I was thinking to replace my Raspberry Pi (first generation Mobel B, the 256 MB RAM model) by the BananaPi, I might try running an AllWinner/sunxi kernel. But getting those compiled…. is yet another struggle. That’s why I prefer mainline support. If the code is in the main repository, the code is clean, and it will compile fine, but the code released by AllWinner is basically a mess. I suppose it’s easier to extract a kernel from an image then compiling it myself.

I must say, the quality of the composite output on the Banana Pi looks better then the output generated by the Raspberry Pi. I’ve only been looking at the console and an X session (with only xterm running)

I’ve been fine-tuning the configuration of my servers. Some notes from my experiences. One of my VPS’es runs a kernel compiled by the server company. This kernel has disabled IPv6 support. (Why are there still server companies that don’t offer IPv6 in the year 2016? I mean *click*) Anyways… running a kernel without IPv6 makes many daemons throw warnings. I am in particular looking at my mail configuration:

postfix[565]: warning: inet_protocols: disabling IPv6 name/address support: Address family not supported by protocol

To make all these warning gone (they pollute the logs) edit the /etc/postfix/main.cf

inet_protocols = all

with

inet_protocols = ipv4

When I want to use greylisting on my server, using postgrey. Well… postgrey… will fail when it’s unable to bind to an IPv6 socket. And looking for a configuration file to configure the listning socket??? Where the hell is it. It seems, on a Ubuntu server, we’ll have to look in /etc/default/postgrey. This file specifies the startup parameters when postgrey is started using postgrey service start.

The default value is:

POSTGREY_OPTS="--inet=10023"

This will try to bind a socket to both IPv4 and IPv6 localhost. In order to make it only bind to IPv4 localhost, change it into

POSTGREY_OPTS="--inet=127.0.0.1:10023"

When looking at various tutorials on configuring postfix, it’s quite easy to configure a catch all for a certain domain. So any username at the said domain gets forwarded so a said maibox. However, I haven’t been able to find any article describing to do the reverse, catch a said username on any domain.

The reason for this is to catch abuse@, postmaster@, webmaster@ etc. any domain on my servers. When going through the postfix documentation another time I realised it support regular expressions. Using regular expressions this can be fixed

put a file /etc/postfix/regexp-aliases

^webmaster@/i  destination@email.address
^postmaster@/i destination@email.address
^abuse@/i      destination@email.address

Then open /etc/postfix/main.cf and add

regexp:/etc/postfix/regexp-aliases

to virtual_alias_maps = .

Edit 05-03-2016: added the /i to the example. Email user names are supposed to be case insensitive.

For quite some time, I haven’t been able to use wireless communication on my HP EliteBook 8530w. All wireless communications (wifi, wwan, bluetooth) are listed as Hard Blocked by rfkill.

It appears, a kernel bug was introduces with Linux 3.13. This bug is in the hp-wmi kernel module, which controls the hardware buttons, including the wireless switch

My current kernel is 4.3.3, so,we obtain the source file for the hp-wmi for this kernel : https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/plain/drivers/platform/x86/hp-wmi.c?id=refs/tags/v4.3.3
We obtain the patch file https://bugzilla.kernel.org/attachment.cgi?id=122901

We apply the patch to the file

patch -p 4 < hp_wmi.patch

We put a Makefile with this file in it

obj-$(CONFIG_HP_WMI)		+= hp-wmi.o

And we comile it

make -C /lib/modules/`uname -r`/build M=$PWD

Backup the original kernel module

mv /usr/lib/modules/`uname -r`/kernel/drivers/platform/x86/hp-wmi.ko.gz /usr/lib/modules/`uname -r`/kernel/drivers/platform/x86/hp-wmi.ko.gz.bak

And put the patched version in its place.

mv ./hp-wmi.ko.gz /usr/lib/modules/`uname -r`/kernel/drivers/platform/x86/hp-wmi.ko.gz

When we press the wireless button now, rfkill reports Hard Blocked: no and we're able to use WiFi, Bluetooth and 3G again.

As the year is coming to an end it’s time to look back. Usually I would have prepared a post to post today. However, last week has been rather turbulent. So due recent events, I will write my post about this year next year.

I wish…
I wish those who are in despair will find new hope.
I wish those who are depressed will find new happiness.
I wish those who are filled with hate find the courage to let it go, learn to love again.
I wish… I wish… for a world in which everyone can be happy, free and independent.
I wish for a world of peace and understanding, a world where people can be themselves.

I suppose I better write about this now, as I encountered these errors a while ago, and the details already started slipping my mind. So, what’s happening? I am writing some PHP code. As a testing server, I’m using my ODROID U3. An ARMv7 board, running ArchLinuxARM. Therefore, we have a 32 bit machine running PHP 5.6. Now, the (soon-to-be) production server is an x86_64 machine, running Ubuntu 14.04LTS. So, this is a 64 bit machine running PHP 5.5.

Let’s have a look at the mcrypt_create_iv() function. This function produces random data. Now, there is a change introduced in PHP 5.6.0. First, let’s have a look on how random data works on a Linux platform. (Other *NIX platform might differ from this)

/dev/random Gives random data, and blocks until there is enough entropy available.
/dev/urandom Gives random data, but never blocks. This means possible less entropy in the result.

Basically, we’re interested in the most possible entropy when we’re doing crypto, then we use /dev/random. That’s why, for example, generating PGP keys takes so long. It’s just waiting for enough entropy to become available. When we need some randomness in a setting that doesn’t require crypto-grade entropy, /dev/urandom is sufficient.

Now, back to PHP. We have the mcrypt_create_iv() function to generate random data. Now, what happened. Since PHP 5.6.0 the default source for randomness is /dev/urandom. In prior versions it was /dev/random. So…. what happens? Code that runs fine on the development machine hangs on the production server, as it’s waiting for entropy. That’s not what we want to happen on a website. So, when using the mcrypt_create_iv() function, always specify the entropy source as the default differs per PHP version.

Well… the difference between 32 and 64 bit PHP versions, it’s all in the size of the int, or rather, using the PHP_INT_MAX for purposes it wasn’t intended for. So, we’re looking at setting a cookie. The idea is to have a “stay logged in” option, so we set the cookie to a date/time way in the future. Considering the Year 2038 problem, the INT_MAX for 32 bit, results in 19 January 2038. However, this is far enough in the future to be used as a “remember me” function. As systems turn 64 bit, this problem is solved, and why not setting the date even to a later date? It just needs to be way ahead in the future to simulate a “never expire” cookie. Well… let’s have a closer look on how cookies work. In PHP, the setcookie() takes a unix timestamp, so, it’s just an INT value containing the number of seconds since the epoch (1 Jan 1970, 00:00 GMT). So far so good, so, if we give it the maximal int value for a 64 bit int….. we end up 293 billion years in the future. (The English Language uses the Short Scale for Numbers, where Continental European Languages uses the Long Scale, note this is “293 miljard” in Dutch. See “Names of Large Numbers” on Wikipedia) So, we’re setting a cookie to a date probably beyond the end of the universe. So, basically, it will never expire. That’s the intention, so…. what went wrong?

Setting a cookie to a date where it will survive the end of the universe causes issues with the Year 10000 problem. The problem is, the server doesn’t just sent that number to the client, it sends a formatted string, it’s format is Wdy, DD Mon YYYY HH:MM:SS GMT Spot the problem? The year is encoded as YYYY, meaning 9999 is last year it supports. So…. setting a cookie to the end of time is not an option.

I don’t know how many 32 bit clients are still out there, but considering the fact they might suffer from the year 2038 problem, I suppose it’s safer to use 2038 as the the-end-of-time value.

Starting today, I am self employed. My company name is The IT Philosopher. My company website is http://www.philosopher.it. Today is the day I am officially registered at the Kamer van Koophandel (Chamber of Commerce). But of cource, I have been preparing for this event for quite some time. One could say I’ve spend all year in preparation for this event.

As part of such, lately I have been working on my web presence. In an earlier stage of my life, I was eager to ensure everything I’ve ever blogged remained online, and imported all of my blogging elsewhere on the internet into my own server. That is this blog. Ten years of blogging, that’s a lot of Blaat.

Over the years my blogging style has changed, where I shifted into more of a tech-blog. My plans are to export the tech-related posts to a different site (http://www.andrevanschoubroeck.name. I suppose I could put up a redirect here.

I suppose this also means, my hosting activities, I’ve executed as a hobby until now, will be shifted to a professional level. As The IT Philosopher, I’ve got new servers, which are still waiting to be configured. Busy busy.

The past days my server has suffered a DoS attack. The attack consists of flooding HTTP requests, to a single PHP script, part of a WordPress installation.

For now, the problem appears to be under control. However, as the attack is still ongoing, I will not reveal any more details.