Posts

Cross compiling libpng for ARM Linux with Neon and Zlib

libpng is the standard software library for creating .png image files. It can be built for arm with NEON SIMD support. Cross compiling it for ARM is reasonably straight forward. Its only dependency is zlib which configure can have problems finding.

Before building libpng you will first need to compile zlib.

Then download the libpng source from here, un-zip it etc. and then run confgure as follows:

In the above command replace:

a.) the path to your zlib include files (probably inside the install directory the the zlib build installed to)
b.) the path to your zlib lib files
c.) The path to the directory into which you want all of the output files installed
d.) change the compiler names (if different from arm-linux-gnueabi-gcc etc.)

Once configure completes you make & install:

Now copy the files from the output directory to your ARM device.

Linux – General Purpose IO (GPIO) from user space code

I came across this good article about how to program general purpose IO (GPIO) from user space code in Linux

http://falsinsoft.blogspot.ie/2012/11/access-gpio-from-linux-user-space.html

It contains a nice little synopsis of the steps involved with setting up and reading & writing inputs and outputs!

Fedora released for Raspberry Pi

Another OS option for your Pi – Fedora Remix has been released for the Raspberry Pi, it is based on the Fedora ARM secondary architecture project, more details can be found here:

http://zenit.senecac.on.ca/wiki/index.php/Raspberry_Pi_Fedora_Remix_FAQ

I love the 4th. item in the FAQ, it is entitled – “Why is the Remix slow?” lol

It makes me very curious, just how slow is it? I guess I will have to install it to find out! :-)

Building / Cross Compiling OpenCV for Linux ARM

This article outlines the steps necessary for building OpenCV for a Linux ARM target. OpenCV is an open-source, cross-platform computer vision and machine vision library.

 

I cross compiled OpenCV for a Xilinx Zinq ARM system yesterday by more-or-less following the steps outlined in the above document – I had to change a few things to get the build to work. I am documenting the exact steps that I took in case anybody is having trouble (probably future me!).

 

I started with a fairly clean Ubuntu install on a virtual machine (it already had git installed) , first I installed some build tools, feel free to skip any that you already have:

Then I installed the GNU ARM tool-chain:

This installed version 4.7 of the compilers while the build process calls for version 4.6, to get around this I modified the cmake platform file slightly, see below.

 

Create a build directory, cd into it and get the OpenCV source from github:

 

To fix the version problem I modified the compiler version in the platform file (this may not be the most correct way to do this but it worked for me!):

 

I edited this file:

 

./opencv/platforms/linux/arm-gnueabi.toolchain.cmake

 

I changed the GCC_COMPILER_VERSION variable’s value from 4.6 to 4.7 to match my installed compiler. I had to edit the file as I wasn’t able to override these variables from the command line.

 

Now create a sub-directory called build and cd into it:

And configure the build:

This should complete without errors if you have the compiler that it is looking for installed etc.

 

Now run ‘make’ and ‘make install’:

Make will take a few minutes to run, make install should copy the output files to a subdirectory called ‘install’.

 

All being well you should now have all the include and lib files that you need to build an OpenCV app for your ARM device.

 

Cross compiling libjpeg for Linux on ARM

I am taking this opportunity to document a cross compilation procedure for libjpeg targeting ARM Linux mostly so that I won’t have to go searching for it again in the future!

First create a directory and cd to it: 

Now get the source and un-tar it:

Configure the build, specifying your C compiler and cross compilation host, then make:

Here, I am using the xilinx build of the compiler, hence the reference to xilinx in the host and CC parameters, if I wasn’t using the xilinx tools the above configure command may have looked more like this:

Now make install, specifying a directory for the output:

If all goes well the output of the build process should be written to the _install directory, copy the .so files to the appropriate directory on your target device (e.g. /usr/local/lib)

Xilinx Zynq Linux – Mount NFS Volume, Connection Refused, failed to register lockdv1 RPC service (errno 111)

You may have been having problems mounting an NFS volume on a Xilinx Zynq kernel build, perhaps mount fails with a ‘Connection Refused’ error message. If you check the /var/log/messages

Then you may see some entries like this:

If this is the case, then you may have to provide some extra option arguments to mount to get things working as follows:

I was having huge problems getting mount to work but this fixed things for me, thanks to all here for the tip!.

 

Debian external disks – /dev/sda1 /dev/sdb1 randomly swapping

I ran into a funny problem recently with Ridge’s debian fileserver – I connected a second external USB drive to it and it stopped working! It always had one external USB drive connected, this was mapped to /dev/sda1 and auto-mounted in /etc/fstab along the lines of:

 

/dev/sda1    /mnt/usb   auto    rw    0       0

 

Everything was running nicely until I introduced a second usb device, this time a large flash disk onto which our automatic backup script is going to periodically dump an encrypted tarball (to provide an easy way for us to move encrypted backups off-site.)

 

Anyway, I saw that the second disk was mapped to /dev/sdb1 and I optimistically modified /etc/fstab to cater for the new flash disk along the lines of:

 


/dev/sda1    /mnt/usb   auto    rw    0       0
/dev/sdb1   /mnt/flash  vfat  rw,users,umask=0   0    0

 

So far so good, after reboot both file systems successfully mounted. But after the next reboot things were not as expected, the original disk was mounted onto the new ‘flash’ mount point and the FAT flash disk was not mounted at all!

 

With the second USB disk connected the way in which the disks were mapped to Linux devices would change randomly every time the system was rebooted – sometimes a disk would appear as /dev/sda1 and sometimes as /dev/sdb1.  As you can imagine this completely ruined the file system setup as configured in /etc/fstab!!

 

I had never encountered this before, but after a little research I found a work around – this involved mounting the disks by label rather than by the more traditional device name.

 

All labelled disks/volumes can be found in /dev/disk/by-label/ , these labels are static and can be used to mount their volumes (instead of using the non-static /dev/sda1 etc.).  Only labelled device appear in the by-label directory, so if you don’t see a disk you may have to give it a label using the tune2fs command. I had to give my original USB disk’s volume a label, I determined that it was currently mapped to /dev/sdb1 and issued the following command to label it as ‘external’:

 

tune2fs -L external /dev/sdb1

 

Now with both disks labelled I modified /etc/fstab as follows:

 

/dev/disk/by-label/external    /mnt/usb   auto    rw    0       0
/dev/disk/by-label/CORSAIR    /mnt/flash  vfat  rw,users,umask=0   0    0

 

And thankfully that fixed the problem! – with the IT systems purring along I can get back to the many more mundane aspects of running a software development consultancy…

Debian steps into the Breach as Linksys NSLU2 NAS Dies

Our Linksys NSLU2 NAS finally died after a long and protracted fight to keep it on its legs and serving.  It has been acting up for a month or two now and now simply refuses to boot unless there are no drives plugged in (that’s not much use!!), I have a feeling that I could probably get it up and running again with freshly formatted disks etc., but I couldn’t really be bothered as I have wasted far too much time on the thing already.

 

It is only two years old, and although it is a very useable and low cost NAS solution I think that due to the shocking manner of its demise I couldn’t possibly recommend that anybody uses it at all!  My opinion has been backed up by the people to whom I have since talked, their Linksys NSLU2s suffered very similar fates at eirily similar ages.

 

Anyway, as the attached disks are formatted as linux ext3 volumes I just plugged them into a spare mini-ITX ‘black box’ type PC that we had here and installed a very slim and cut-down version of Debian with Samba.  A few quick fsck’s later confirmed that there was no damage to the volumes (phew!) and in an hour or two the disks were back on the network and stable.  A very acceptable gratis stop-gap solution thanks to Debian and a spare PC!