Showing posts from 2015

git rebase eats my commits when the rebase fail... (no, not really)

I'm playing with git --rebase for the first time. The first patch of the series was fixing coding style, but it was also introducing some coding style errors related to continuation lines. Instead of adding two additional tabs, I was aligning the continuation lines with the previous opening parenthesis. Oops. So I needed to edit the first commit of the series to be able to resent all of them. git makes it quite convenient, right?      $ git --rebase --interactive <commit hash>^ Then git will show a text file for you to edit and choose what to do with each commits. Everything fine until now. My workflow is      $ vi path/to/file.c      $ make path/to/file.o      $ git add path/to/file.c      $ git commit --amend      $ git rebase --continue Well this is awesome, and I had fun rebasing all my 11 commits and it was looking very good. Even when the automatic rebase doesn't work it is very intuitive and great to work with. This is one sample output when the auto

bool b = -1; if(b) printk("Yes, -1 maps to true!");

/* Assign -1 to bool variable */ bool b = -1; if(b) printk("Yes, -1 maps to true!"); /* Return -1 in bool function */ bool f(void) { return -1; } if (f()) printk("Yes, -1 maps to true!"); Yesterday I was reading this interesting discussion about the boolean type in C. The most interesting sentence was: "0 is false, 1 is true, any other value is *undefined behavior*." Then I started to look for abuses of the bool type in the Linux kernel. I wrote simple semantic patches for getting cases in which a negative values are being returned by bool functions: @@ identifier f, ret; constant C; typedef bool; @@ bool f (...){ <+... ret = -C; ... * return ret; ...+> } and @@ identifier f; constant C; typedef bool; @@ bool f (...){ <+... * return -C; ...+> } The first search for boolean functions that assign negative value to a

Adding a serial console to the Buffalo Air Station WZR-1750DHP

Playing with custom kernels and OpenWRT... It took me more than a month to flash a kernel that won't boot, but I did it yesterday. So the only way was to open the case, and connect the cables to access the serial console. Here is what I learned. Before you start Tools For opening the case you will need to remove two screws that are similar to those of mobile phones. I don't know the type name nor the size, so I recommend you to check type and size before starting. The screws are under the adhesive on the back of the router near the power plug and the mode button. UPDATE: Matt Sealey posted a comment saying that the screws are Torx T6. Thank you Matt! USB to Serial You will need something to connect your computer to the serial interface of the router. The most common solution is to use an USB to serial adapter. There are plenty of options, but I'm using this one that I bought on Ebay for less than € 10. Search for 'FT232RL' on your favorite online store.

Buffalo WZR-1750DHP + OpenWRT

This is the first of a series of posts about Linux kernel development for ARM. There will be one or two more posts before we get into the Kernel, describing tasks as building, and configuring OpenWRT. Maybe I'll also write about de-bricking devices if I manage to do something silly with my router. :-) What I like about the Buffalo WZR-1750DHP are the specs and the case without external antennas. It has a dual core ARM CPU with 512MB of RAM, and two wifi adapters: One for 2.4GHz and other for 5GHz. I was expecting that to install OpenWRT in a device like the WZR-1750DHP, it would require to find and use a serial port. Luckily that's not necessary. All the procedure was done over friendly web interfaces. As the router do not allow to install random firmware images, there are some workarounds to install OpenWRT. The steps I used are: 1 - Install and upgrade DD-WRT Download the latest versions of the files  factory-to-dd-wrt.bin and  buffalo-wzr-1750d