Skipping incompatible /lib/ when searching for /lib/

This normally happens when compiling for an arch, say ARM, and try to execute the binary in an x86_64 arch.
But in this case, it was not this problem, I was sure that I was compiling and executing for the right places for the right archs.

The error was the following:

Then I discovered that the same issue appears with
For some reason this happened after a Fedora upgrade, something got missing during the upgrade.

In order to fix it, change to the directory where your sysroot resides, in my case is /opt/gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf/sysroot

Edit the file usr/lib/
Change the GROUP line that is where the linker searches for libpthread:

Edit also the file usr/lib/

After this, I was able again to execute the binaries as before.

Adding a splashscreen in U-Boot in an Atmel based custom board

Normally, when you start an embedded Linux project you have an evaluation kit that comes with an LCD with a splashscreen in U-Boot. Then, when you have your custom board based on that evaluation board and if you’re lucky enough to use an LCD with the same characteristics, changing the splashscreen is an easy task. But if the LCD is quite different, you have to make some changes that are not difficult, but can take some time if you don’t know where to search.

Recently, I had to do just that with an Atmel SAMA5D3 board that was derived from the SAMA5D3 evaluation kit, but instead of mounting the default 800×400 LCD it mounts a 480×272 LCD with different characteristics such as clock frequency, horizontal/vertical syncs, and so on.

The default U-Boot configuration from Atmel (U-Boot 2015.01) does not support a splashscreen, only a raw image (logo) embedded in the code, so the first step is remove the support for the logo, enable the Atmel HLCD driver, enable the splashscreen and enable the bmp command that is needed to display the .bmp image.

These changes take place in the board header file that contains its configuration, in my case, it was the include/configs/sama5d3xek.h file.
This is a code snippet with the changes:

Some of these parameters could change for your LCD, such as LCD_OUTPUT_BPP. Adjust them according to the LCD datasheet.

Now you’ll probably have to change a couple of things: how the LCD is initialized by your board and how it is physically connected. In my case this is in board/atmel/sama5d3xek/sama5d3xek.c.

Set the parameters used to initialize the LCD. You may need to check its datasheet.

Now check how the LCD is connected to the board. Mine has the higher 8 bit connected to peripheral A, while the evaluation kit’s higher 8 bit are connected to the peripheral C. You may need your board schematics to check to which peripheral is connected and change it accordingly:

At this point you should be able to have a nice boot splashscreen that you can change from userspace if you write to the right address.
A new post will describe how to do this.

Official splashscreen U-Boot page.

Migrating from Trac to Redmine

In the past few days, I needed to migrate from a 6 years old server with CentOS 5 (it’s end of life is this month) to a shiny new one with Ubuntu 16.04. One of the services that was running in the old server was Trac 0.11 and I had several issues to move it to version 1.2. I like Trac and I’ve used it without any issues until now. After a while I decided to try Redmine 3.3.2, but I was not sure about the migration process.

After installing a large amount of requirements (a lot of Ruby packages), I followed this migration procedure that seemed straight-forward and should work with Trac 0.11, but it failed almost immediately for a very simple issue: The timestamps in all the database tables in Trac were in microseconds, whilst the script was expecting them in seconds.

I wrote this simple Perl script that changes the timestamps in all the Trac database tables:

Assuming that you have installed all the requirements (including the Perl ones with CPAN) and that the SQLite3 Trac database is called trac.db, execute the above script followed by the Redmine migration script:

The Ruby (rake) script asks for your Trac settings:

and outputs all the items that were migrated without any errors.

I checked immediately in Redmine if everything was migrated correctly and I noticed a couple of issues:

  • The attachments in the wiki and tickets are not migrated
  • The wiki links are corrupted. The whole wiki was migrated (all the pages and their content is correct), but the links got corrupted.

The attachments were not a big issue since I had a few of them.
The wiki links was a bit annoying, I went to the Index by title, check the new name and edit the pages that link the correspondent page. My wiki is large, but it’s not heavily linked, so it didn’t take too much time to fix it.

Now that I’ve been using Redmine for a week I feel quite comfortable with it and I think that its integration with Git is better than Trac’s.