Sunday, July 14, 2013

git repository made available via windows share

I keep stumbling upon people setting up git repositories on a local hard disk and then sharing the repository via windows share for others to use;

I cringe when I see this for a number of reasons:

  • It is not scale-able.
  • It's not as fast as using a git server (bandwidth)
  • If you access files on a Linux box the line endings are going to be different. In this case git can become confused and suggest that files have been changed when they have not been.
  • Accessing this between work and home is slooow. You have to mount the drive and do the push pull to that drive.
    • Accessing via a slow Atlantic VPN connection is very questionable in this case as you have now lost the distributed part of git.
  • All your changes are on that share. If you loose a file or the file becomes corrupted you've got problems.
    • Atomic File access and file-locking: It should work....

Atomic File Access and File-Locking:

This should work see Git Over NFS/CIFS

However I would not recommend this especially as you need up-to date Samba, NFS etc...

I have found that if you have a mixture of different Operating Systems for testing and supporting customers on specific Linux distributions (some quite old) ensuring that the network filesystems are all up-to date is very time consuming and sometimes not possible without modifying the source code.

Sometimes NFS file-locking is turned off due to compatabilities between versions or suppliers.


Given that it does not take that long to setup a proper git-server I would not recommend a local git repository shared with other developers unless your environment is hetrogenous and all your developers are local on a fast network.

In other words: "Setup a Git-Server".

Wednesday, July 18, 2012

Rasbian gcc compiler options

I am going to try and use the following options for building:
-mcpu=arm1176jzf-s -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard

Hard-float toolchain

Switching to hard-float Raspbian

If your toolchain is not setup correctly for hard-float you will get something like the following:
/home/raspberrypi/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-ld: error: adler32.lo uses VFP register arguments, does not

Build a new toolchain

Follow the options for setting up crosstools-ng.
This time select hardware floating point.
  • Target Options->Floating point:  softfp
  • You might also want to build to somewhere else. I will not be using the soft-fp version again so I am starting from clean again.

    Create a new rootfs for wheezy

    Download debootstrap from
    Create a directory for debootstrap and cd to it.
    Unpack the download.
    export DEBOOTSTRAP_DIR=`pwd`
    ./debootstrap --verbose --include=apt --arch armhf \
      --foreign wheezy \
      /home/raspberrypi/Development/wheezy-armhf \

    Change the permissions.
    cd /home/raspberrypi/Development/wheezy-armhf
    chmod -R 777 *

    Configure scratchbox to use new rootfs and compiler chain.

    Change directory to wheezy.
    sb2-init wheezy-armhf /home/raspberrypi/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc
    sb2-config -d wheezy-armhf

    Thursday, July 12, 2012

    Secure Digital life

    The following activities will reduce the usable life of a secure digital card:

    writing to /temp
    log files (/var)

    More to follow...

    Use of noatime

    proc /proc proc defaults 0 0 /dev/mmcblk0p1 /boot vfat defaults,sync 0 0 /dev/mmcblk0p2 / ext4 defaults,noatime 0 0 /etc/dphys-swapfile update-rc.d -f dphys-swapfile remove sudo apt-get install rcconf sudo rcconf

    Raspberry Pi cross compilation

    Download the VM from russelldavis vm

    Use the v.0.8 or newer (if there is one).

    I am using the wheezy beta version for Raspberry Pi and need a cross compilation environment to build very large projects.

    The instructions that follow describe how to build a new toolchain and to setup an additional scratchbox2 environment for wheezy and the toolchain.

    Install some missing packages we will need later:
    apt-get install bison
    apt-get install flex
    apt-get install subversion
    apt-get install gperf
    apt-get --fix-missing install texinfo
    apt-get install libtool
    apt-get install schroot

    Build a cross compiler toolchain for wheezy (gcc 4.6.x)

    Download crosstool-ng
    Create a directory for crosstools.
    cd into the directory and unpack the downloaded file.
    make install
    /usr/local/bin/ct-ng menuconfig
    The configuration I used is:
    • Paths and Misc options: Enable 'Try features marked as Experimental'
    • Target Options->Target architecture: arm
    • Target Options->Floating point:  softfp
    • Operating System->Target OS: Linux
    • Operating System->Linux Kernel Version:3.3.4 (should match the kernel version if you are building a kernel or device driver).
    • Binary Utilities->binutils version: 2.21.1a or latest that is not experimental
    • C Compiler->Enable Show Linaro version (Experimental) option
    • C Compiler->gcc version: linario-4.6.2012.04
    • C Compiler->Select C++ compiler
    • Companion tools->Select Build some companion tools
    • Companion tools-> select all the tools
    Now build the toolchain (you might need to have lunch and tea ;>> while you wait):
    /usr/local/bin/ct-ng build

    Create a new rootfs for wheezy

    Download debootstrap from
    Create a directory for debootstrap and cd to it.
    Unpack the download.
    export DEBOOTSTRAP_DIR=`pwd`
    ./debootstrap --verbose --include=apt --arch armel \
     --foreign wheezy /home/raspberrypi/Development/wheezy \
    I do not seem to be able to install the apt package. So this is just for a small base system. We will come back to this.

    Change the permissions.
    cd /home/raspberrypi/Development/wheezy
    chmod -R 777 *

    Configure scratchbox to use new rootfs and compiler chain.

    Change directory to wheezy.
    sb2-init wheezy /home/raspberrypi/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc
    sb2-config -d wheezy
    Note: we pass the path to the gcc compiler... to sb2-init

    Test the setup

    Test the compiler is the one you want to use:
    sb2 gcc -v
    Test the compiler works:
    sb2 gcc test.c
    What test.c contains:
    raspberrypi@raspberrypi-developer:~/Development$ cat test.c
    int main(int argc, char*argv[])
      return 1;
    Test the exe produced works:
    raspberrypi@raspberrypi-developer:~/Development$ sb2 ./a.out
    raspberrypi@raspberrypi-developer:~/Development$ file ./a.out
    ./a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.3.4, not stripped
    The ultimate test is to run this on your raspberrypi.

    Update the rootfs

    The rootfs is minimal you will need to copy from you raspberrypi boot card the necessary include and lib folders.

    I upgraded by raspberrypi before I copied off what I needed:
    apt-get update
    apt-get upgrade
    apt-get --fix-missing install xorg-dev
    You may need to answer some questions while doing the updates.
    When it's all finished reboot and check the raspi-config settings and enable CTRL-ALT-BACKSPACE.
    Copy off the necessary include and lib folders and put them in the same place in your wheezy rootfs


    The X11 libraries are not in the usual directory. They can be found here:
    Additionally the base library names are missing so you will need to do:
    ln -s

    Issues To watch out for

    If you copy all the libraries off your wheezy image you may get link errors with libc. Try moving the one in usr/lib to a new name.