BIOS - ChipI tried to do a BIOS update from Windows. Flashing finished without an error so I decided to reboot. The tablet shut down and… never turned on again. Nothing of what I tried had any effect, the tablet remained dead. Not A sign of life. So I decided the BIOS flash must have gone wrong. What now?

After some research I found that there were more people with the same problem, and some seemed to have successfully flashed their BIOS again. So I decided to give it a try.

First of all I needed some hardware. I searched online for a BIOS programmer, and found a cheap CH314A programmer that should do the job. It had TTL and 3.3V levels, I knew that the BIOS chip was 3.3V so it should work without frying my BIOS chip.

Next step was to find a way to program the chip without soldering. I knew that the chip was in SOP8 package, so I searched a test adapter for a SOP8 chip, and ordered one.

After about a week the hardware was in, and I could get to work. I found the correct BIOS and found a bin file in the download. Then I installed flashrom and connected all the hardware together.
BIOS - Tablet and laptop BIOS - Adapter

First I made a backup of the current rom using flashrom:
flashrom -p ch341a_spi --read backup.bin

After the backup it was time to flash:
Screenshot from flashrom

After this, I disconnected the test adapter, disconnected the battery, reconnected the battery and tried to boot. And with success, the tablet booted straight up to Windows!

I upgraded my Raspberry Pi to a newer kernel and updated the firmware with the following commands:

sudo apt-get update && sudo apt-get upgrade
sudo rpi-update
sudo reboot

After this my pilight couldn’t send anymore using the lirc_rpi module. Al lot of resources mentioned a new device tree and stuff, so I added the following to my /boot/config.txt file:

# Uncomment this to enable the lirc-rpi module

This caused the lirc_rpi module to be loaded and I could receive data using the pilight-raw command. But sending still wouldn’t work.

After lots of time and effort I found the culprit. The new module seems to have enable softcarrier by default. Also autosensing didn’t work always as intended. So I changed the lines in my /boot/config.txt to the following:

# Uncomment this to enable the lirc-rpi module

Now everything works as expected!

Please let me know if this helped you to solve your problem.

iodineI’ve had some troubles getting Iodine-server to work under CentOS 7. So iv’e decided to write an article how I’ve managed to get it to work.

This instruction is based on a setup using iptables instead of firewalld, because I run iptables on all my servers since forever.

DNS setup

For iodine to work there are two records required. An A-record and an NS record. I’ve used the same naming as the iodine documentation, to keep it as simple as possible.
First add an A-record with the name t1ns that points to the ip of your server that will run the iodine server. The ip used here for the example should be replaced by your ip.
A: t1ns.<<yourdomain>> → 374.263.291.194

Then add an NS record with the name t1 that points to the A-record you’ve just made;
NS: t1.<<youdomain>> → t1ns.<<yourdomain>>

That’s all there is required for iodine to work with your domain.

Installing iodine

Firstly, make sure the EPEL repository is installed:
yum -y install epel-release

Then install iodine-server:
yum -y install iodine-server

Next is configuring iodine by editing /etc/sysconfig/iodine-server.
Make sure the line that starts with OPTIONS look something like this:
OPTIONS="-f -c -P <<yourpassword>> t1.<<yourdomain>>"
Replace <<yourpassword>> with the password you wish to use, and <<yourdomain>> with the domain you are using for iodine.

Then, start iodine-server and enable it at boot:
systemctl start iodine-server
systemctl enable iodine-server

Configure traffic routing

Allow DNS and NAT traffic trough iptables:
iptables -t nat -A POSTROUTING -s -o eth0 -j MASQUERADE
iptables -t filter -A INPUT -p udp -m multiport --dports 53 -j ACCEPT
iptables -t filter -A INPUT -i dns0 -j ACCEPT
iptables -t filter -A OUTPUT -o dns0 -j ACCEPT
iptables -t -A OUTPUT -p udp -m multiport --dports 53 -j ACCEPT
iptables -t filter -A FORWARD -i dns0 -o eth0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A FORWARD -i eth0 -o dns0 -m state --state RELATED,ESTABLISHED -j ACCEPT

And save the new ruleset:
iptables-save > /etc/sysconfig/iptables

Next, allow ipv4 packet forwarding and restart the network service to apply this change:
echo "net.ipv4.ip_forward = 1" > /etc/sysctl.d/ip_forward.conf
systemctl restart network


That’s it. You should be able to connect with iodine to your server by using the address t1.<<yourdomain>>.

An Android client that seems to work pretty good and I use is AndIodine, and is available via the F-Droid catalogue.

Please leave a comment if this post was helpfull in any way.

When I tried to compile my own Android ROM, I got the following error:

CHK     include/linux/version.h
target Executable: skia_gm (/media/ssd/buildout//target/product/i9100/obj/EXECUTABLES/skia_gm_intermediates/LINKED/skia_gm)
target Executable: skia_test (/media/ssd/buildout//target/product/i9100/obj/EXECUTABLES/skia_test_intermediates/LINKED/skia_test)
target Executable: test-opengl-configdump (/media/ssd/buildout//target/product/i9100/obj/EXECUTABLES/test-opengl-configdump_intermediates/LINKED/test-opengl-configdump)
CC      scripts/mod/empty.o
/bin/sh: 1: /home/ted/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-gcc: not found
make[4]: *** [scripts/mod/empty.o] Error 127
make[3]: *** [scripts/mod] Error 2
make[2]: *** [scripts] Error 2
make[2]: *** Waiting for unfinished jobs....

The problem was that the arm toolchain wasn’t installed. After installing the toolchain compiling succeeded.

Installing the toolchain can be done with the following command:
git clone

After that, run the following command to add the toolchain to the PATH variable:
export PATH=$(pwd)/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin:$PATH

Compiling should now succeed without the previous error.

I’ve found this information on, a very helpful information source for Android development.

If you own a shared hosting server, you probably want to keep the /var/log/messages file as clean as possible, to make searching for errors as easy as possible.

One of our web servers had a messages file filled with Drupal errors and warnings. It al seemed to come from one site.
After a bit of searching, it seemed the syslog module in Drupal was enabled. There are two solutions to this annoyance. You can disable the syslog module in the database used by this site, or make syslog log all Drupal errors to a separate file.

Database solution

The most easy method to check and disable the syslog module is disabling this module in the database as follows:

Checking if the module is enabled:
SELECT * FROM system WHERE name='syslog';
If the status column is 0, the module is disabled, in case of a 1 the module is enabled.

To disable the module:
UPDATE system SET status='0' WHERE name='syslog';

And to check if the module is really disabled:
SELECT * FROM system WHERE name='syslog';
The status column should now say 0.

Separate log solution

Create the file /etc/rsyslog.d/90-drupal.conf with the following content:

# drupal logging
if $programname == 'drupal' and $syslogseverity <= '6' then /var/log/drupal.log if $programname == 'drupal' and $syslogseverity <= '6' then ~

That's it. There should be no more Drupal messages in the /var/log/messages file.