Outils pour utilisateurs

Outils du site


gumstixd

Ceci est une ancienne révision du document !


compiler projet qtcreator

qmake 
make

Installation camera econ

depuis dossier binary de camera econ

scp uImage root@192.168.1.80:/boot/uImage-2.6.30

sur gumstix dans /boot/

rm uImage
ln -s uImage-2.6.30 uImage

copie du module modifié v4l2 vers le home root sur gumstix

scp v4l2_driver.ko root@192.168.1.80:

regarder le readme de econ

doc sur uboot: http://www.denx.de/wiki/DULG/Manual

presser une touche pendant le boot pour avoir uboot

setenv mmcargs setenv bootargs mem=122M i2c_bus=3,100 iconsole=${console} mpurate=${mpurate} vram=${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=${mmcroot} rootfstype=${mmcrootfstype}
saveenv

Mise a jour openembbeded

dans org.openembedded.dev pour mettre a jour les recettes

git pull

effacer tmp pour virer les fichiers temporaires mais preserver tmp/sources (je l'ai mis dans le dossier parent)

So that recipes delete contents of tmp/work (which saves lots of rooms, particularly for the build system) to build/conf/local.conf add :

INHERIT += “rm_work”

A ranger

pour pouvoir compiler des recettes bitbake dont le code source est sur le serveur git du laas

ajouter ma clef publique à trac

ssh bvandepo@trac.laas.fr
vim ~/.ssh/authorized_keys

copier le contenu de /home/bvdp/.ssh/id_rsa.pub de la machine de développement bitbake

puis pour que l'user sur git soit bvandepo au lieu de bvdp, faire sur la machine de développement bitbake:

vim ~/.ssh/config

et ajouter ce contenu:

host trac.laas.fr
"tabulation"    user bvandepo

pour compiler la recette genom, il faut avoir genom installée sur la machine de dev. l'executable de conversion du .gen en .c reste sur la machine de dev. Sur la gumstix, il y aura seulement les executables.

voir la recette demo-genom.bb pour compiler un module genom

éventuellement, pour compiler depuis des sources en local, remplacer SOURCES… par FILES et une liste de fichiers.

install robotpkg et genom

http://homepages.laas.fr/mallet/robotpkg

dans home:

git clone ssh://bvandepo@softs.laas.fr/git/robots/robotpkg
cd robotpkg
./bootstrap --prefix=${HOME}/openrobots

ajouter à ~/.bashrc

export ROBOTPKG_BASE=/home/bvdp/openrobots

puis faire

cd ~/robotpkg/architecture/genom
make update 
bitbake -b mkdep-native_2.8
bitbake -b demo-genom

Paul's gumstix ethernet config

root@overo:~# cat /etc/rc5.d/network_eth1_static 
sleep 2
ifconfig eth1 192.168.1.80 up
route add -net default gw 192.168.1.1
root@overo:~# ls -l /etc/rc5.d/
<snip>
lrwxrwxrwx 1 root root  19 Jun 19 09:36 S99network -> network_eth1_static
-rwxrwxrwx 1 root root  76 Jun 19 09:40 network_eth1_static
-rwxrwxrwx 1 root root 102 Jun 19 09:36 network_wlan3_static

Création images, package etc...

Images pré-compilée

Pour télécharger des images de linux pré-compilée pour Gumstix Overo : http://www.sakoman.com/feeds/omap3/glibc/images/overo/

Installation des logiciels necessaires à la compilation d'une image linux

sous debian
sudo aptitude install subversion cvs git-core  build-essential help2man diffstat texi2html texinfo  libncurses5-dev gawk python-dev python-psyco  python-pysqlite2   gnome-doc-utils gettext automake flex
sous fedora
sudo yum install subversion cvs git-core  build-essential help2man diffstat texi2html texinfo  libncurses5-dev gawk python-dev python-psyco  python-pysqlite2   gnome-doc-utils gettext automake flex

d'apres http://wiki.openembedded.net/index.php/OEandYourDistro#Fedora_11

sudo yum install python m4 make wget curl ftp cvs subversion tar bzip2 gzip unzip python-psyco perl texinfo texi2html diffstat openjade docbook-style-dsssl docbook-style-xsl docbook-dtds docbook-utils sed bison bc glibc-devel gcc binutils pcre pcre-devel git quilt groff linuxdoc-tools patch linuxdoc-tools gcc gcc-c++ help2man perl-ExtUtils-MakeMaker glibc-static
récupération OpenEmbedded
 
git clone git://gitorious.org/gumstix-oe/mainline.git org.openembedded.dev
cd org.openembedded.dev
git checkout --track -b overo origin/overo
cd ..
git clone git://git.openembedded.net/bitbake bitbake
cd bitbake
git checkout 1.8.18
cd ..
cp -r org.openembedded.dev/contrib/gumstix/build .
vim build/profile
pour fedora
 
## Environment setup for oe
setenv BB_ENV_EXTRAWHITE "MACHINE DISTRO ANGSTROM_MODE OVEROTOP OEBRANCH USERBRANCH TITOOLSDIR"
setenv OVEROTOP "/local/users/bvandepo/overo-oe"
setenv OEBRANCH "$OVEROTOP/org.openembedded.dev"
setenv USERBRANCH "${OVEROTOP}/user.collection"
setenv PATH "${OVEROTOP}/bitbake/bin:$PATH"
setenv BBPATH "${OVEROTOP}/build:${USERBRANCH}/:${OEBRANCH}"
setenv TITOOLSDIR "${OVEROTOP}/ti"
umask 0002
## end oe setup

puis concatener avec ~/.tchrc

pour debian
## Environment setup for oe
export BB_ENV_EXTRAWHITE="MACHINE DISTRO ANGSTROM_MODE OVEROTOP OEBRANCH USERBRANCH TITOOLSDIR"
export OVEROTOP="/usr/overo-oe"
export OEBRANCH="$OVEROTOP/org.openembedded.dev"  
export USERBRANCH="${OVEROTOP}/user.collection"
export PATH="${OVEROTOP}/bitbake/bin:$PATH"
export BBPATH="${OVEROTOP}/build:${USERBRANCH}/:${OEBRANCH}"
export TITOOLSDIR= "${OVEROTOP}/ti"
umask 0002
## end oe setup

puis concatener avec ~/.bashrc

sous ubuntu, il faut changer dash contre bash

sudo ln -sf /bin/bash /bin/sh

Création et compilation d'une image / Copie sur la carte SD

Pour créer et compiler une image (installer les logiciels auparavant, puis suivre les instructions de la page suivante):

http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html

Voici les commandes à effectuer :

Note 1: If you are using an Ubuntu distribution, it is likely that /bin/sh is linked to /bin/dash. If this is the case, then you will need to change /bin/sh to link to /bin/bash. Neglecting to do this will cause target system init file corruption and your build image will not boot! Run “sudo dpkg-reconfigure dash” and answer no when asked whether you want to install dash as /bin/sh. Note 2: If you are using Ubuntu 8.04 or later you will also need to edit /etc/sysctl.conf and set 'vm.vdso_enabled = 0' and 'vm.mmap_min_addr = 0'. Afterwards run 'sudo sysctl -p' Build system checkout

First you'll want to check out the source files for OE build system (roughly 250 MB). With a typical DSL connection this step should take less than 20 minutes. You should have at least 10GB of free space on your hard drive in order to do a complete build of the kernel and root file system images.

These instructions will assume that you are installing the build system in your home directory under “overo-oe”. If you decide to put it elsewhere you will need to make appropriate alterations to the steps below.

First we will create the “overo-oe” directory and cd into it:

$ mkdir -p ~/overo-oe
$ cd ~/overo-oe

Then we will install the OE metatdata, and check out the overo branch (you can safely ignore the warnings you will get from the git commands):

$ git clone git://gitorious.org/gumstix-oe/mainline.git org.openembedded.dev
$ cd org.openembedded.dev
$ git checkout --track -b overo origin/overo

The next step installs BitBake:

$ cd ~/overo-oe
$ git clone git://git.openembedded.net/bitbake bitbake
$ cd bitbake
$ git checkout 1.8.18

Creating the OE configuration files and profile

We now will create a profile script and the configuration files required to tailor OE to our needs.

To make this a somewhat easier task, there is a template for the required files in the openembedded installation we just did.

Copy these files to your overo-oe directory:

$ cd ~/overo-oe
$ cp -r org.openembedded.dev/contrib/gumstix/build .

If you have followed the example installation and placed the build system in overo-oe in your home directory, you are now ready to proceed to the next step. If you have installed the build system in a different location you will need to edit overo-oe/build/profile and change the definition of OVEROTOP as appropriate. Source code caching

As part of the build process OpenEmbedded downloads source code tarballs for the linux kernel, compiler, and other software packages. By default this source code cache will be placed in overo-oe/sources. If you would like this cache to be located elsewhere, now is the time to edit build/conf/site.conf and set DL_DIR as appropriate. Environment setup

OpenEmbedded requires some environment setup in order to function properly. There are a couple of ways to handle this requirement. Option A: bash profile

You can set this up via your bash profile:

$ cp ~/.bashrc ~/bashrc.bak
$ cat ~/overo-oe/build/profile >> ~/.bashrc

With most distributions, adding this environment setup to ~/.bashrc will work for both GUI shells and login shells. If your distribution does not source .bashrc for login shells, you may need to use ~/.bash_profile instead of ~/.bashrc (or modify ~/.bash_profile so that it does source ~/.bashrc).

if you chose Option A for environment setup (bash profile method), log out/log back in or close your terminal window and open a new one so that the environment changes you enabled above will take effect. Option B: Command line sourcing

If you don't want to modify your standard terminal profile for some reason, you can do this environment setup on a per session basis by sourcing overo-oe/build/profile prior to issuing any build commands:

$ . ~/overo-oe/build/profile

or alternatively:

$ source ~/overo-oe/build/profile

If you chose Option B (command line sourcing), issue the command to source the environment setup. Your first build

You can build a basic kernel and non-gui root file system image in one step with:

$ bitbake omap3-console-image

If your build machine is missing any essential packages, bitbake will notify you about them at this point. Install the recommended packages and try the bitbake command again.

You will also get a message from bitbake suggesting that you install the psyco JIT compiler for better performance. It isn't necessary to install psyco right now, though it is a good idea to install it at some point.

You may also notice another message complaining about not finding user.collection/packages/*/*.bb. Don't concern yourself with this – you will create this directory later when you create your first package for your own code.

This initial build will take a bit of time since it will need to download all the source code and build the cross compilation tools. Subsequent builds will be much faster. When the build completes, you will find the root file system image and the kernel image in $HOME/overo-oe/tmp/deploy/glibc/images/overo 













==== Pour créer les partitions sur la carte microSD et copier l'image de linux : ==== 

http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html


The Overo COM will boot directly from a properly prepared microSD card. This section will outline how to partition and format a bootable microSD card.

In order to create a bootable microSD compatible with the OMAP3 boot ROM, you must set a special geometry using the fdisk "Expert mode".

This example will show the steps for setting up a brand new 2GB microSD card.

First insert your card into your development machine's flash card slot. You may need to use a microSD to SD card adaptor to fit your slot.

On my Ubuntu 8.04 machine, the newly inserted card shows up as /dev/sde and that is the device name that will be used through this example. You should substitute the proper device name for your machine. You can use 'mount' or 'df' to see where the card mounts on your machine.

Let's unmount the device's existing file system before we get started with fdisk:

  $ sudo umount /dev/sde1

Partitioning the card

Now launch fdisk and create an empty partition table. Note that the argument for fdisk is the entire device (/dev/sde) not just a single partition (i.e. /dev/sde1):

# sudo fdisk /dev/sde
Command (m for help): o
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Let's first look at the current card information:

Command (m for help): p
Disk /dev/sde: 2032 MB, 2032664576 bytes
64 heads, 63 sectors/track, 984 cylinders
Units = cylinders of 4032 * 512 = 2064384 bytes
Disk identifier: 0x00aa8e5c
Device Boot      Start         End      Blocks   Id  System

Note the card size in bytes. We will needed it later in the process.

Now go into “Expert” mode:

Command (m for help): x

Next we will set the geometry to 255 heads, 63 sectors and a calculated value for the number of cylinders required for the particular microSD card.

To calculate the number of cylinders, we take the 2032664576 bytes reported above by fdisk divided by 255 heads, 63 sectors and 512 bytes per sector:

2032664576 / 255 / 63 / 512 = 247.12 which we round down to 247 cylinders.

Expert command (m for help): h
Number of heads (1-256, default 4): 255
Expert command (m for help): s
Number of sectors (1-63, default 62): 63
Warning: setting sector offset for DOS compatiblity
Expert command (m for help): c
Number of cylinders (1-1048576, default 984): 247

Return to fdisk's main mode and create a new partition 32 MB FAT partition:

Expert command (m for help): r
Command (m for help): n
Command action
e   extended
p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-247, default 1): 1
Last cylinder or +size or +sizeM or +sizeK (1-247, default 15): +32M

Change the partition type to FAT32:

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): c
Changed system type of partition 1 to c (W95 FAT32 (LBA))

And mark it bootable:

Command (m for help): a
Partition number (1-4): 1

Next we create an ext3 partition for the rootfs:

Command (m for help): n
Command action
e   extended
p   primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (6-247, default 6): 6
Last cylinder or +size or +sizeM or +sizeK (6-247, default 247): 247

To verify our work, lets print the partition info:

Command (m for help): p
Disk /dev/sde: 2032 MB, 2032664576 bytes
255 heads, 63 sectors/track, 247 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00aa8e5c
Device Boot      Start         End      Blocks   Id  System
/dev/sde1   *           1           5       40131    c  W95 FAT32 (LBA)
/dev/sde2               6         247     1943865   83  Linux

Up to this point no changes have been made to the card itself, so our final step is to write the new partition table to the card and then exit:

Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional
information.
Syncing disks.

Formatting the new partitions

We format the first partition as a FAT file system (the -n parameter gives it a label of FAT, you can change or omit this if you like):

#  sudo mkfs.vfat -F 32 /dev/sde1 -n FAT
mkfs.vfat 2.11 (12 Mar 2005)

We format the second partition as an ext3 file system:

$ sudo mkfs.ext3 /dev/sde2
mke2fs 1.40.8 (13-Mar-2008)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
121920 inodes, 485966 blocks
24298 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=499122176
15 block groups
32768 blocks per group, 32768 fragments per group
8128 inodes per group
Superblock backups stored on blocks: 
32768, 98304, 163840, 229376, 294912
Writing inode tables: done                            
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: ^[done
This filesystem will be automatically checked every 36 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Installing the boot files

There are three files required on the first (FAT) partition to boot your Overo:

1. MLO: the boot-loader loader - this small program is loaded into the OMAP3 processor's static RAM. It does some minimal configuration of system memory and io pins and then loads the second file. 2. u-boot.bin: the boot loader 3. uImage: the linux kernel

You can build these yourself or download pre-built images. It is important that these three files have precisely these names.

Once you have completed building or downloading these files, mount the FAT partition of your microSD card. This example will assume that you have mounted it at /media/card:

sudo mount /dev/sde1 /media/card

Due to constraints of the mask boot ROM in the OMAP processor, MLO should be written first:

$ sudo cp MLO-overo /media/card/MLO

Then copy u-boot and the linux kernel to the card:

$ sudo cp u-boot-overo.bin /media/card/u-boot.bin
$ sudo cp uImage-overo.bin /media/card/uImage

You can now unmount the FAT partition:

$ sudo umount /dev/sde1

At this point you have a bootable FAT partition.

The final step is to untar your desired rootfs onto the ext3 partition that you created above.

Note that this step can be dangerous. You do not want to untar your Overo rootfs onto your development machine - be careful!

This example will assume that you have mounted it at /media/card:

$ sudo mount /dev/sde2 /media/card

Now untar your desired rootfs:

$ cd /media/card
$ sudo tar xvjf /path/to/omap3-console-image-overo.tar.bz2 

You can now unmount the ext3 partition:

$ sudo umount /dev/sde2  

Configuration de la communication entre la Gumstix et un PC

installer le logiciel minicom : apt-get install minicom

exécution du logiciel : minicom /dev/ttyUSB0 kernel-module-v4l2-common Configuration du logiciel :

o ⇒ configure minicom serial port setup ⇒ régler le port A⇒ serial device sur le port usb ou est connecté la gumstix /dev/ttyUSB0

		         régler le mode de transfert E => sur 115200 (vitesse) 8N1 (8bit, aucune parité, 1bit de stop)
		         régler F (Hardware Flow Control) et G (Software Flow Control) => « NO »
			
Faire « Y » en quittant puis « Save setup as dev_ttyUSB0 », puis « Exit »

Si rien est branché brancher d'abord l'usb, ensuite l'alimentation! Sinon débrancher et rebrancher l'alimentation de la carte.

Sites interessants

Problèmes / Erreurs

=> Erreur au début de la compilation

Please install following missing utilities: C++ Compiler (${BUILD_PREFIX}g++)

Il faut installer G++ avec la commande : sudo aptitude install g++



 == => Erreur de proxy lors de la compilation : == 

Impossible de télécharger les fichiers à la compilation, il suffit d'éditer un fichier «~/.wgetrc» avec dedans :

// http_proxy = http://'proxy-name':'port-number'

ftp_proxy = http://'proxy-name':'port-number'

use_proxy = on
 //


==== pour installer des modules, softs etc... ====
`
http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Installing-additional-sw-packages/111.html


===== webcam =====
on va utiliser v4l,
exemple pour grabber une image en c++:
http://staff.science.uva.nl/~bterwijn/Projects/V4L2/html/


doc perso sur drivers etc: http://homepages.laas.fr/bvandepo/wiki/doku.php?id=camerauvc


liste les periphs usb branchés:
  lsusb


  dmesg | grep v4

liste des modules chargés:
  lsmod


verifier si un package est installé:
  opkg list-installed | grep 7311
  opkg list-installed | grep v4l
  opkg list-installed | grep uvc

décharger un module: 
  rmmod v4l2-common

chargement de module:
  modprobe gspca-pac7311
  modprobe v4l2-common

on peut automatiser le chargement de ces modules au démarrage en editant /etc/modules

lister les modules chargés:
  lsmod

affichage du flux de données depuis la webcam:
  cat /dev/video0 

on doit obtenir ces modules chargés :
  v4l2_common            16258  0 
  gspca_pac7311          12405  0 
  gspca_main             21653  1 gspca_pac7311
  videodev               33496  2 v4l2_common,gspca_main
  v4l1_compat            14083  1 videodev
  ipv6                  225222  10 

===== clef usb wifi =====
pour la clef blanche
  opkf list-installed  pipe grep rt73
  modprobe  rt73usb
  iwconfig wlan0


voir: https://help.ubuntu.com/community/WifiDocs/Driver/RalinkRT73

 
===== Communication via liaison serie avec le mac =====
installer driver (v2.2.14):
http://www.ftdichip.com/Drivers/VCP.htm

installer minicom 
  sudo port install minicom

le device est accessible en tty.usbserial-A7005rIY 


===== configuration wifi sur mac =====
  /opt/local/bin/airport

  /opt/local/bin/airport -s
  
  Chan Nois Sign  Address            Beac Flgs  SLen  SSID
   9 65444 65470  00:25:84:93:cf:50   100 0431    11: laas-secure
  11 65444 65481  00:12:01:b0:0e:c0   100 0c31    11: laas-secure
  13 65442 65468  00:25:84:90:6d:f0   100 0431    11: laas-secure
  11 65444 65481  00:12:01:b0:0e:c1   100 0c21    12: laas-welcome
   9 65444 65468  00:25:84:93:cf:51   100 0421    12: laas-welcome
  13 65442 65479  00:25:84:90:6d:f1   100 0421    12: laas-welcome
  44 65442 65466  00:14:a5:30:9e:5e   100 0411     8: LAASHRP2



rejoindre un reseau wifi
  /opt/local/bin/airport -J linksys

créer un reseau ad hoc wifi
 /opt/local/bin/airport -A netgumstix 0x0000000000 11

===== acces au routeur wifi linksys =====
http://192.168.1.1
log: rien
psw: admin 
===== carte wifi =====

configuration fonctionnelle au 23 septembre 2010

carte sd 2 

carte wifi intégrée de l'overo 1 sur tobi 1

script sl2 copié en /etc/init.d/setupnetwork puis link 
  ln -s /etc/init.d/setupnetwork /etc/rc2.d/S99setupnetwork
  

          
  #/bin/sh
  export ADAPT="wlan3"
  route flush
  ifconfig $ADAPT down

iwconfig $ADAPT  mode managed
ifconfig $ADAPT inet  192.168.1.101 netmask 255.255.255.0
route add default gw  192.168.1.6
iwconfig $ADAPT rate 6M
iwconfig $ADAPT channel 1
ifconfig $ADAPT up
sleep 3
iwconfig $ADAPT essid linksys
sleep 5
iwconfig $ADAPT essid linksys

routeur wifi linksys configuré pour ne pas diffuser son ssid, il faut demander a se connecter en tapant le nom sous mac

plante a cause du module rt73usb lors de ifconfig, a retester

carte wifi noire 500mW

opkg list-installed | grep 8187                                   
kernel-module-rtl8187 - 2.6.32-r51.5       
modprobe rtl8187 

du coup il accepte

iwconfig wlan0 txpower 500mW  
ifconfig wlan0 192.168.1.107 

automatisation par script:

creer un script /home/root/setupnetwork:

iwconfig wlan0 rate 54M
iwconfig wlan0 channel 6
iwconfig wlan0 mode managed
iwconfig wlan0 essid "linksys"
iwconfig wlan0 txpower 100mW
iwlist 
ifconfig -a
ifconfig wlan0 192.168.1.107 
ifconfig wlan0 up    

copier le script vers /etc/init.d/

cp  /home/root/setupnetwork  /etc/init.d/

update-rc.d  /etc/init.d/setupnetwork defaults

et faire un lien symbolique:

ln -s /etc/init.d/setupnetwork /etc/rc2.d/S99setupnetwork

ca ne marche pas, sans doute les modules de /etc/modules sont charges trop tard (carte wifi?)

http://www.labri.fr/perso/billaud/presentations/linux2002/POLY/admin-unix-2.html

http://www.commentcamarche.net/forum/affich-2062649-lancer-un-script-au-demarrage

automatisation par fichier de config (ne marche pas encore):

mkdir /etc/sysconfig/network-scripts cd /etc/sysconfig/network-scripts vim ifcfg-wifi

DEVICE=wlan0 ONBOOT=yes # Monter l'interface au démarrage TYPE=Wireless USERCTL=no # Contrôle par un simple utilisateur BOOTPROTO=none # Remplacer par dhcp, mais peut poser des problèmes au démarrage HWADDR=00:e0:4c:03:23:f4 # L'adresse MAC de votre carte NETMASK=255.255.248.0 #DHCP_HOSTNAME=pioupiou1-wifi # Nom de votre ordinateur lorsque le dhcp est utilisé IPADDR=192.168.1.107 # Adresse fixe de votre interface wifi #DOMAIN= #NETWORK=192.193.1.0 # Adresse réseau GATEWAY=192.168.1.1 # Adresse de votre passerelle IPV6INIT=no PEERDNS=yes ESSID=linksys # Le nom de votre réseau wifi (ESSID) CHANNEL=6 # Le canal utilisé par votre point d'accès wifi MODE=Managed # Mode wifi utilisé (Master, Adhoc - Managed par défault) IWCONFIG=“AP 00:16:B6:40:F7:4E” # Adresse MAC de votre point d'accès wifi RATE=54M # Cette valeur permet d'augmenter la stabilité (laisser vide).

touch /etc/sysconfig/network-scripts/ifcfg-wifi

ne marche pas….

connexion en ssh sur la gumstix

ssh root@192.168.1.107

copie de fichiers vers la gumstix

 scp overo_snapshot_19.pdf root@192.168.1.107:/home/root/

copie de fichiers depuis la gumstix en étant loggé sur la gumstix par ssh

scp overo_snapshot_19.pdf guillaume@192.168.1.102:/home/guillaume   

Screen

en cas de connexion par ssh, si on perd la connexion, au bout d'un certain temps, les programmes plantent à cause de debordement de buffer. pour lancer proprement des softs depuis un autre pc, on utilise ssh puis on lance screen

yum install screen

une fois connectée à la machine, lancer

screeen

avant de déconnecter le cable reseau, pour rendre la main, taper

CTRL-A  D

puis exit de ssh

a la prochaine connexion ssh, pour reprendre la main, taper

screen -r

infos sur un module

modinfo rtl8187

modules à charger pour la gumstix

-driver webcam serverin: gspca-pac7311

-driver video for linux: v4l2-common

-driver clef usb dlink wifi: rt73usb

-driver clef usb noire wifi: rtl8187

hokuyo

Pour charger le fichier cdc_acm

Pour charger dans un premier temps on peut modifier le fichier 'modules' qui se trouve dans :

/etc/

de la facon suivante :

### This file is automatically generated by update-modules"
#
# Please do not edit this file directly. If you want to change or add
# anything please take a look at the files in /etc/modutils and read
# the manpage for update-modules.
#
### update-modules: start processing /etc/modutils/cdc_acm
cdc_acm

### update-modules: end processing /etc/modutils/cdc_acm

### update-modules: start processing /etc/modutils/ipv6
ipv6

### update-modules: end processing /etc/modutils/ipv6

La deuxième solution pour ne pas toucher au fichier 'modules' de /etc/ qui est généré automatiquement Il est possible de créer un fichier (script) qui sera automatiquement executé au démarrage de la gumstix

Ce fichier doit se trouver dans : /etc/rc'num du runlevel'.d (par exemple:/etc/rc5.d/) pour avoir le numéro du runlevel 2 possibilités :

soit taper la commande runlevel (ici on trouve le numéro 5) :
		root@overo:/etc# runlevel
		N 5

Soit au démarrage de la gumstix le numéro est précisé :
		INIT: Entering runlevel: 5

Le fichier doit porter un nom de la forme “S'numéro''nom'” (par exemple numéro=90 et nom=local : S90local) Le fichier doit contenir, pour lancer le module cdc_acm au démarrage, la ligne de commande :

modprobe cdc_acm

Une fois le fichier sauvegardé il suffit de redémarrer la carte gumstix (reboot) et vérifier que le module a bien été chargé au démarrage avec la commande 'lsmod' :

root@overo:/etc/rc5.d# lsmod
Module                  Size  Used by
cdc_acm                14477  0     // => le module est bien chargé
ipv6                  219420  14 
tentative d'installation de player

http://playerstage.sourceforge.net/wiki/Cross_Compile_Player_with_Openembedded_and_bitBake

http://playerstage.sourceforge.net/wiki/Cross_Compile_Player_with_Gearbox

opkg install player-dbg_3.1.0-r0.5_armv7a.ipk 
opkg install player-dev_3.1.0-r0.5_armv7a.ipk  
opkg install   player_3.1.0-r0.5_armv7a.ipk

résultat:

 e.g. opkg info 'libstd*' or opkg search '*libop*' or opkg remove 'libncur*'

root@overo:~/hokuyo# opkg install player-dbg_3.1.0-r0.5_armv7a.ipk

Installing player-dbg (3.1.0-r0.5) to root… player-dbg: unsatisfied recommendation for player player-dbg: unsatisfied recommendation for glibc-dbg player-dbg: unsatisfied recommendation for libltdl-dbg player-dbg: unsatisfied recommendation for libjpeg-dbg player-dbg: unsatisfied recommendation for libz-dbg player-dbg: unsatisfied recommendation for libstdc++-dbg player-dbg: unsatisfied recommendation for libgcc-dbg Configuring hicolor-icon-theme. usr/lib/opkg/info/hicolor-icon-theme.postinst: line 7: gdk-pixbuf-query-loaders: not found usr/lib/opkg/info/hicolor-icon-theme.postinst: line 13: gtk-update-icon-cache: not found Configuring player-dbg. Collected errors: * pkg_run_script: postinst script returned status 127. * opkg_configure: hicolor-icon-theme.postinst returned 127.

root@overo:~/hokuyo# root@overo:~/hokuyo# opkg install player-dev_3.1.0-r0.5_armv7a.ipk Installing player-dev (3.1.0-r0.5) to root… player-dev: unsatisfied recommendation for libtool-dev player-dev: unsatisfied recommendation for libjpeg-dev player-dev: unsatisfied recommendation for libc6-dev player-dev: unsatisfied recommendation for libltdl-dev player-dev: unsatisfied recommendation for libz-dev player-dev: unsatisfied recommendation for libstdc++-dev player-dev: unsatisfied recommendation for libgcc-dev Configuring hicolor-icon-theme. usr/lib/opkg/info/hicolor-icon-theme.postinst: line 7: gdk-pixbuf-query-loaders: not found usr/lib/opkg/info/hicolor-icon-theme.postinst: line 13: gtk-update-icon-cache: not found Collected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for player-dev: * player * * opkg_install_cmd: Cannot install package player-dev. * pkg_run_script: postinst script returned status 127. * opkg_configure: hicolor-icon-theme.postinst returned 127. root@overo:~/hokuyo# root@overo:~/hokuyo# opkg install player_3.1.0-r0.5_armv7a.ipk Installing player (3.1.0-r0.5) to root…

Configuring hicolor-icon-theme. usr/lib/opkg/info/hicolor-icon-theme.postinst: line 7: gdk-pixbuf-query-loaders: not found usr/lib/opkg/info/hicolor-icon-theme.postinst: line 13: gtk-update-icon-cache: not found Collected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for player: * libjpeg62 * libstdc++6 * * opkg_install_cmd: Cannot install package player. * pkg_run_script: postinst script returned status 127. * opkg_configure: hicolor-icon-theme.postinst returned 127. root@overo:~/hokuyo# root@overo:~/hokuyo# Broadcast message from root (ttyS2) (Thu Apr 15 22:11:53 2010):

hokuyo matthieu

http://artisan.karma-lab.net/node/60

apres avoir installe un paquet hokuyo:

ls /usr/lib/ipkg/info/ | grep hokuyo                                                                                             
  gbx-hokuyo-aist.control                                                                                                                                   
  gbx-hokuyo-aist.list   
vim /usr/lib/ipkg/info/gbx-hokuyo-aist.list   
  /usr/lib/gearbox/libhokuyo_aist.so.1.0.0
  /usr/bin/hokuyo_aist_example
ln -s /dev/usbdev1.10 /dev/ttyACM0 

en remplacant le 10 par le numero de device affiche a la connexion sur l'usb → probleme /dev/usbdev1.10 n'est pas utilisable par /usr/bin/hokuyo_aist_example

Le device a besoin du module cdc_acm

modprobe cdc_acm

fichiers .bb installé sur borderouge dans:

cd /local/users/bvandepo/overo-oe/hokuyo/gearbox-oe

Ils sont sous git, a mettre dans user.collection/recipes/

  git clone ssh://trac.laas.fr/git/robots/gearbox-oe

connexion en ssh sur borderouge pour compiler

ne pas oublier de faire

source ~/.tcshrc

verifier avec env si j'ai bien le meme environnement que: http://homepages.laas.fr/bvandepo/data/envpourbitbake

driver adaptateur USB-serie bleu turquoise

Centrale MTI Xsens

Installation sur borderouge

par defaut les devices /dev/ttyUSB0 et 1 ne sont pas accessibles à tous les utilisateurs

pour changer temporairement le propriétaire du device:

sudo chown -vR bvandepo /dev/ttyUSB0

pour le configurer de manière permanente:

créer un fichier /etc/udev/rules.d/99-mti.rules
SYSFS{idVendor}="04033", SYSFS{idProduct}=="6010", MODE="0666", OWNER="root", GROUP="root"

configuration de minicom pour dialoguer avec la MTI:

115200 baus 8N2 Stops, Pas de controle logiciel et materiel

driver Xsens MTI

matthieu a fait la recette et explique comment intégrer les paquet openrobots dans bitbake:

https://intranet.laas.fr/intranet/robots/wiki/Gumstix/OpenEmbedded#preview

modules

modprobe usbserial
modprobe ftdi_sio vendor=0x0403 product=0x6010    

programme de test

MTIHardTest -v /dev/ttyUSB0 -o 1 -d 2

http://www.lefinnois.net/wp/index.php/2009/04/15/ttyusb0-ttyusb2-non-ttyusb1-graaaahh-udev/

  • je branche un adaptateur, il est accessible via /dev/ttyUSB0
  • j'en branche un autre qui devient /dev/ttyUSB1
  • je débranche le premier et en branche deux autres et ça devient la fête aux ttyUSB*

Où est ma Fonera 1, où est mon Attiny2313, où est ma Fonera 2… etc… ?

On trouve dans /sys/bus/usb-serial/devices plein de choses intéressantes avec udevinfo -a -p. Parmi lesquelles :

ATTRS{manufacturer}=="FTDI"
ATTRS{product}=="FT232R USB UART"
ATTRS{serial}=="A90066ai"

Du coup, il ne reste plus qu'à se construire des petites règles sympathiques dans un fichier placé dans /etc/udev/rules.d :

SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ATTRS{product}=="FT232R USB UART", \
SYSFS{serial}=="A90066j7", SYMLINK+="TTYUSB0"
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ATTRS{product}=="FT232R USB UART", \
SYSFS{serial}=="A90066ac", SYMLINK+="TTYUSB1"
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ATTRS{product}=="FT232R USB UART", \
SYSFS{serial}=="A900669W", SYMLINK+="TTYUSB2"
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ATTRS{product}=="FT232R USB UART", \
SYSFS{serial}=="A90066ai", SYMLINK+="TTYUSB3"

On redémarre udev avec un petit /etc/init.d/udev restart et on marque des petits chiffres au feutre indélébile sur les adaptateurs. A la connexion du périphérique identifié par son numéro de série, un lien symbolique est créé dans /dev. Peu importe le /dev/ttyUSB*, le lien symbolique donne toujours accès au bon périphérique.

Done.

PS : ça marche pour plein de périphériques. Ceci inclus les clef USB par exemple :

BUS=="usb", SYSFS{serial}=="123456789ABCDEF", NAME="%k", SYMLINK="usbkey1"

Article posté on Mercredi, 15 avril 2009 à 21:19 dans Configuration. Vous pouvez suivre les commentaires sur cet article via un feed RSS 2.0. Commentaires et pings fermés.

compilation d'une image linux perso

structure des dossiers de OpenEmbedded

recettes pour les images: $OVEROTOP/org.openembedded.dev/recipes/images

  j'utilise omap3-console-image.bb
j'y ai ajouté notamment:

  TOOLS_INSTALL = " \
    pocolibs \
    gbx-hokuyo-aist \  
    mti-libs \
    jpeg-dev\
    tiff\
    busybox\
    gcc\
    glibc\
    libstdc++-dev\
    libtool-dev\
    pstree\
    unzip\
    bash \
    bzip2 \

fichiers image résultat:    $OVEROTOP/tmp/deploy/glibc/images/overo/

attention les differentes versions sont stockees… elles prennent de la place (a peu pres 300mo par image). le lien symbolique omap3-console-image-overo.tar.bz2 pointe normallement vers la derniere version

Angstrom-omap3-console-image-glibc-ipk-2010.4-test-20100520-overo.rootfs.tar.bz2
Angstrom-omap3-console-image-glibc-ipk-2010.4-test-20100520-overo-testlab
modules-2.6.32-r51-overo.tgz
omap3-console-image-overo.tar.bz2
u-boot-overo-2009.11.1+r0+git327f51adacfe8c7b633f90306d646ae03e098554-r0.bin
u-boot-overo.bin
uImage-2.6.32-r51-overo.bin
uImage-overo.bin

fichiers recettes du laas: $OVEROTOP/org.openrobots.dev/recipes


   demo-genom
   gearbox  --> drivers du hokuyo
    gbx-common.inc
    gbx-flexiport.bb
    gbx-hokuyo-aist.bb
    gbx-share.bb
   genom
   mkdep
   mti-libs  --> drivers de la centrale xsense
    mti-libs.bb  
    mti-libs_git.bb
   pocolibs  --> fonctions de communications ( peut être utile pour mti, demander a Matthieu)
    pocolibs_git.bb
===== installation des paquets pour hokuyo=====
lors de l'installation d'un paquet, pour avoir plus d'infos:
  opkg install -V2  hokuyogood_1.0-r0.5_armv7a.ipk 

soit les intégrer directement à l'image système, soit installer les ipk a posteriori

  scp bvandepo@borderouge.laas.fr:/local/users/bvandepo/overo-oe/tmp/deploy/glibc/ipk/armv7a/gbx-flexiport_9.11-r1.5_armv7a.ipk ./
  scp bvandepo@borderouge.laas.fr:/local/users/bvandepo/overo-oe/tmp/deploy/glibc/ipk/armv7a/gbx-flexiport-dbg_9.11-r1.5_armv7a.ipk ./
  scp bvandepo@borderouge.laas.fr:/local/users/bvandepo/overo-oe/tmp/deploy/glibc/ipk/armv7a/gbx-flexiport-dev_9.11-r1.5_armv7a.ipk ./
  scp bvandepo@borderouge.laas.fr:/local/users/bvandepo/overo-oe/tmp/deploy/glibc/ipk/armv7a/gbx-hokuyo-aist_9.11-r0.5_armv7a.ipk ./
  scp bvandepo@borderouge.laas.fr:/local/users/bvandepo/overo-oe/tmp/deploy/glibc/ipk/armv7a/gbx-hokuyo-aist-dbg_9.11-r0.5_armv7a.ipk ./
  scp bvandepo@borderouge.laas.fr:/local/users/bvandepo/overo-oe/tmp/deploy/glibc/ipk/armv7a/gbx-hokuyo-aist-dev_9.11-r0.5_armv7a.ipk ./
  scp bvandepo@borderouge.laas.fr:/local/users/bvandepo/overo-oe/tmp/deploy/glibc/ipk/armv7a/gbx-share_9.11-r0.5_armv7a.ipk ./
  scp bvandepo@borderouge.laas.fr:/local/users/bvandepo/overo-oe/tmp/deploy/glibc/ipk/armv7a/gbx-share-dbg_9.11-r0.5_armv7a.ipk ./
  scp bvandepo@borderouge.laas.fr:/local/users/bvandepo/overo-oe/tmp/deploy/glibc/ipk/armv7a/gbx-share-dev_9.11-r0.5_armv7a.ipk ./
  scp bvandepo@borderouge.laas.fr:/local/users/bvandepo/overo-oe/tmp/deploy/glibc/ipk/armv7a/hokuyogood_1.0-r0.5_armv7a.ipk ./
  scp bvandepo@borderouge.laas.fr:/local/users/bvandepo/overo-oe/tmp/deploy/glibc/ipk/armv7a/hokuyogood-dbg_1.0-r0.5_armv7a.ipk ./
  scp bvandepo@borderouge.laas.fr:/local/users/bvandepo/overo-oe/tmp/deploy/glibc/ipk/armv7a/hokuyogood-dev_1.0-r0.5_armv7a.ipk ./
  scp bvandepo@borderouge.laas.fr:/local/users/bvandepo/overo-oe/tmp/deploy/glibc/ipk/armv7a/hokuyogood-doc_1.0-r0.5_armv7a.ipk ./
  scp bvandepo@borderouge.laas.fr:/local/users/bvandepo/overo-oe/tmp/deploy/glibc/ipk/armv7a/mti-libs_0.4+git63d1948-r0.6_armv7a.ipk ./
  scp bvandepo@borderouge.laas.fr:/local/users/bvandepo/overo-oe/tmp/deploy/glibc/ipk/armv7a/mti-libs-dbg_0.4+git63d1948-r0.6_armv7a.ipk ./
  scp bvandepo@borderouge.laas.fr:/local/users/bvandepo/overo-oe/tmp/deploy/glibc/ipk/armv7a/mti-libs-dev_0.4+git63d1948-r0.6_armv7a.ipk ./
  scp bvandepo@borderouge.laas.fr:/local/users/bvandepo/overo-oe/tmp/deploy/glibc/ipk/armv7a/mti-libs-static_0.4+git63d1948-r0.6_armv7a.ipk ./




  opkg install gbx-flexiport_9.11-r1.5_armv7a.ipk 
  opkg install gbx-share_9.11-r0.5_armv7a.ipk 
  opkg install gbx-hokuyo-aist_9.11-r0.5_armv7a.ipk 	
  opkg install hokuyogood_1.0-r0.5_armv7a.ipk 
  opkg install mti-libs_0.4+git63d1948-r0.6_armv7a.ipk
   
  
  

  chmod +x hokuyogoodgumstix 

scprit shell pour configurer le reseau et executer hokuyogumstix 
  #/bin/sh
  ifconfig eth0 10.31.4.9
  export LD_LIBRARY_PATH=/usr/lib/gearbox/
  modprobe cdc_acm
  cd /home/root/hokuyogood/gumstix
  ./hokuyogoodgumstix /dev/ttyACM0

===== variables d'environnement =====
dans .tcshrc 
  ## Environment setup for oe
  #
  #
  setenv BB_ENV_EXTRAWHITE "MACHINE DISTRO ANGSTROM_MODE OVEROTOP OEBRANCH ROBOTSBRANCH USERBRANCH TITOOLSDIR"
  setenv OVEROTOP "/local/users/bvandepo/overo-oe"
  setenv ROBOTSBRANCH "$OVEROTOP/org.openrobots.dev“

setenv OEBRANCH "$OVEROTOP/org.openembedded.dev"
setenv USERBRANCH "${OVEROTOP}/user.collection"
setenv PATH "${OVEROTOP}/bitbake/bin:$PATH"
setenv BBPATH "${OVEROTOP}/build:${USERBRANCH}/:${OEBRANCH}"
setenv TITOOLSDIR "${OVEROTOP}/ti"
umask 0002
#
## end oe setup
#
#~               

mtiG

branche GPS du depot git

modifier dans la recette mti-libs_git.bb pour choisir la version que l'on veut

SRCREV = "b4638df"

ce sont les premiers numeros d'un commit (on peut les voir en faisant gitk)

cette version est celle qui fonctionne sous mac, pour laquelle il y a le flag -lrt dans le fichier Makefile.in, pour modifier les sources en local, editer : /local/users/bvandepo/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/mti-libs-0.4+gitbcccc5e-r0/git/test/test.cpp

pour cleaner (obligatoire!)

bitbake -b org.openrobots.dev/recipes/mti-libs/mti-libs_git.bb -c clean

pour aller chercher les sources sur le depot git

bitbake -b org.openrobots.dev/recipes/mti-libs/mti-libs_git.bb -c fetch

pour builder

bitbake -b org.openrobots.dev/recipes/mti-libs/mti-libs_git.bb

on obtient les 4 ipk dans: /local/users/bvandepo/overo-oe/tmp/deploy/glibc/ipk/armv7a

IMPORTANT: Si il y a un probleme avec le fetch, il faut effacer dans $OVEROTOP/sources/git


mes sources sont sur garossos dans ~/robotpkg/hardware/MTI/work.garossos.laas.fr/MTI-0.4/test

=====Thomas=====

__**A-Z Create your own bootable MicroSD Card (8GB)**__
-------------------------------------------------------

__**Context**__

This document is a guide for using a Gumstix computer-on-module by creating your own bootable MicroSD Card (8GB)

__**Hardware**__

-> Gumstix Overo COM : OMAP3 Chip with POP Memory (Processor), MicroSD card slot, ISP Camera connector, TPS65950 Power Management Chip, Bluetooth & WiFi Antennas ...

-> Tobi expansion board : USB host, DVI-D (HDMI), Audio IN & OUT ...

-> Cable : USB cable from console port to a USB port on your computer

-> Power supply : 5V

__**Delete the partitions in a SD Card**__

Context : We consider that we have a SD car adaptator (MicroSD to SD)

-> Insert the SD card
  ~$ dmesg ⇒ We can see what happens, informations appears and we can see : [17280329.634829] sdc: sdc1 sdc2 (the SD card is “sdc” and there are 2 partitions inside “sdc1” and “sdc2”)

~$ cd /dev
/dev$ ls

⇒ The SD card appears in /dev/sdc (/dev/sdc1 ; /dev/sdc2)

/dev$ sudo fdisk /dev/sdc

⇒ We can operate in the disk

[sudo] password for xxx :

Command (m for help): m

⇒ Help mode

Command action a toggle a bootable flag b edit bsd disklabel c toggle the dos compatibility flag d delete a partition l list known partition types m print this menu n add a new partition o create a new empty DOS partition table p print the partition table q quit without saving changes s create a new empty Sun disklabel t change a partition's system id u change display/entry units v verify the partition table w write table to disk and exit x extra functionality (experts only)

⇒ Delete a partition

Command (m for help): d

⇒ Choose the first

Partition number (1-4): 1
Command (m for help): d

⇒ Choose the second

Partition number (1-4): 2

⇒ See the partition table to check what we have done

Command (m for help): p

Disk /dev/sdc: 7973 MB, 7973371904 bytes 255 heads, 63 sectors/track, 969 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x000ebad0 Device Boot Start End Blocks Id System

⇒ We can see that the partitions don't appear (nothing is done yet), then we can operate (Write)

Command (m for help): w

The partition table has been altered! Calling ioctl() to re-read partition table. WARNING: Re-reading the partition table failed with error 16: Device or resource busy. The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) Syncing disks.

⇒ The partitions are deleted now

→ Remove the SD card and insert it again

/$ cd /dev
/dev$ ls

⇒ Partitions are well deleted

Partitioning the SD card

The SD card needs to have two partitions :

root = MLO (boot-loader loader) + u-boot.bin (boot loader) + uImage (Linux kernel)

rootfs = Images (Pre-built images for example or your own images)

/dev$ sudo umount /dev/sdc

⇒ The mount command serves to attach the file system found on some device to the big file tree ; the umount command will detach it again

/dev$ sudo fdisk /dev/sdc

⇒ We can perate in the disk

Command (m for help): m

Command action a toggle a bootable flag b edit bsd disklabel c toggle the dos compatibility flag d delete a partition l list known partition types m print this menu n add a new partition o create a new empty DOS partition table p print the partition table q quit without saving changes s create a new empty Sun disklabel t change a partition's system id u change display/entry units v verify the partition table w write table to disk and exit x extra functionality (experts only) ⇒ Create a new empty DOS partition table (partition 1)

Command (m for help): o

Building a new DOS disklabel with disk identifier 0xc9aaa9e6. Changes will remain in memory only, until you decide to write them. After that, of course, the previous content won't be recoverable. Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

⇒ See the partition table

Command (m for help): p

Disk /dev/sdc: 7973 MB, 7973371904 bytes 246 heads, 62 sectors/track, 1021 cylinders Units = cylinders of 15252 * 512 = 7809024 bytes Disk identifier: 0xc9aaa9e6 Device Boot Start End Blocks Id System

⇒ Note the memory size = 7973371904 bytes

Command (m for help): x

⇒ Choose the extra functionality

⇒ Cylinder-head-sector, also known as CHS, was an early method for giving addresses to each physical block of data on a hard disk drive

⇒ Choose 255 heads

Expert command (m for help): h
Number of heads (1-256, default 246): 255

⇒ Choose 63 sectors

Expert command (m for help): s
Number of sectors (1-63, default 62): 63

Warning: setting sector offset for DOS compatiblity

⇒ Calculate the number of cylinders : memory size/heads/sectors/512 bytes per sector = 7973371904/255/63/512

⇒ Choose 969 cylinders

Expert command (m for help): c
Number of cylinders (1-1048576, default 1021): 969

⇒ Return to fdisk's main mode

Expert command (m for help): r

⇒ Add a new partition

Command (m for help): n

Command action e extended p primary partition (1-4)

p
Partition number (1-4): 1
First cylinder (1-969, default 1): 1
Last cylinder, +cylinders or +size{K,M,G} (1-969, default 969): +32M

⇒ Change the partition type to FAT32

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): cChanged system type of partition 1 to c (W95 FAT32 (LBA))

⇒ Mark it bootable

Command (m for help): a
Partition number (1-4): 1

⇒ Create an ext3 partition (partition 2)

Command (m for help): n

Command action e extended p primary partition (1-4)

p
Partition number (1-4): 2
First cylinder (6-969, default 6): 6
Last cylinder, +cylinders or +size{K,M,G} (6-969, default 969): 969

⇒ See the partition table

Command (m for help): p

Disk /dev/sdc: 7973 MB, 7973371904 bytes 255 heads, 63 sectors/track, 969 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0xc9aaa9e6 Device Boot Start End Blocks Id System /dev/sdc1 * 1 5 40131 c W95 FAT32 (LBA) /dev/sdc2 6 969 7743330 83 Linux

⇒ So we have two partitions (1 FAT32 / 2 Ext3 Linux)

⇒ Write

Command (m for help): w

The partition table has been altered! Calling ioctl() to re-read partition table. WARNING: If you have created or modified any DOS 6.x partitions, please see the fdisk manual page for additional information. Syncing disks.

⇒ Now we have to format the two partitions

/dev$ sudo mkfs.vfat -F 32 /dev/sdc1 -n FAT

mkfs.vfat 3.0.3 (18 May 2009)

/dev$ sudo mkfs.ext3 /dev/sdc2

mke2fs 1.41.9 (22-Aug-2009) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 484800 inodes, 1935832 blocks 96791 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=1983905792 60 block groups 32768 blocks per group, 32768 fragments per group 8080 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 Writing inode tables: done

Creating journal (32768 blocks): done

done

Writing superblocks and filesystem accounting information: ^[done

done This filesystem will be automatically checked every 26 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. bash: syntax error near unexpected token `done' The program 'one' is currently not installed. You can install it by typing: sudo apt-get install opennebula one: command not found

⇒ Two partitions are created and they are formated

⇒ Check the SD card

→ system → administration → disk utility

⇒ We can see the 8GB SD card with two partitions

FAT partition 1 41 MB / 41,094,144 bytes Type W95 FAT32 (LBA)(0x0c) Bootable 7.9 GB Filesystem partition 2 7.9 Gb / 7,929,169,920 bytes type linux Ext3 (0x83)

⇒ Rename the two partitions : System → Administration → Disk utility

 Select the partition 1 FAT  -> Mountable Filesystem -> Label "root"   -> Change
 Select the partition 2 EXT3 -> Mountable Filesystem -> Label "rootfs" -> Change

→ Unplug the SD card

Installing the Boot Files

→ Download the last updated “Tested, Stable Images” (Pre-built factory images for the example) or build your own images

 http://gumstix.org/software-development/pre-built-images.html

⇒ You may be routed to : http://cumulus.gumstix.org/images/angstrom/factory/

⇒ We have download the images into /home/thomas/prebuilt

~/prebuilt$ ls

Images oe-commit-id.txt uImage.htm md5sum.txt omap3-desktop-nand-image-overo-booted.tar.bz2 MLO u-boot.bin

⇒ You can see the download files

→ Insert the SD card

⇒ Two windows may appear (2 partitions)

/$ cd media
/media$ ls

cdrom cdrom0 ROOT rootfs System

⇒ They are the two partitions ROOT & rootfs

/$ sudo mount /dev/sdc1 /media/ROOT

⇒ It may be made yet

⇒ Returns in the file with downloads /home/thomas/prebuilt

⇒ Copy all the download files in the partition 1 (begin with the MLO file !!!)

~/prebuilt$ sudo cp MLO /media/ROOT/MLO
~/prebuilt$ sudo cp u-boot.bin /media/ROOT/u-boot.bin
~/prebuilt$ sudo cp uImage.htm /media/ROOT/uImage
~/prebuilt$ sudo umount /dev/sdc1

⇒ Check that it is well unmounted

/media$ ls

cdrom cdrom0 rootfs System

⇒ At this point you have a bootable FAT partition

/media$ sudo mount /dev/sdc2 /media/rootfs

⇒ Go on /home/thomas/prebuilt

~/prebuilt$ ls

Images oe-commit-id.txt uImage.htm md5sum.txt omap3-desktop-nand-image-overo-booted.tar.bz2 MLO u-boot.bin

⇒ Copy the images files in the partition 2

~/prebuilt$ sudo cp omap3-desktop-nand-image-overo-booted.tar.bz2 /media/rootfs

⇒ Go on the partition 2 (rootfs)

/media/rootfs$ ls

lost+found omap3-desktop-nand-image-overo-booted.tar.bz2

⇒ tar = file grouping = archive ; bz2 = compressed archive

⇒ unzip and unarchive the file

sudo tar -xvaf omap3-desktop-nand-image-overo-booted.tar.bz2

⇒ It takes around 15 minutes

⇒ Remove the compressed archive file

/media/rootfs$ sudo rm omap3-desktop-nand-image-overo-booted.tar.bz2

⇒ unmount the partition 2

/media$ sudo umount /dev/sdc2

→ Unplug the SD card

Setting up a Serial Connection

→ Insert the MicroSD card into the Gumstix Overo COM

→ Plug the USB cables (expansion board - computer)

/$ cd dev
/dev$ ls

⇒ We can see it : ttyUSB0

⇒ Run Minicom (communication program)

/$ minicom -s

⇒ Under “Serial Port Setup” choose the following

  • Serial Device: /dev/ttyS0 (edit to match your system as necessary)
  • Bps/Par/Bits: 115200 8N1
  • Hardware Flow Control: No (this is important)
  • Software Flow Control: No

⇒ Hit [ESC] until you return to the main configuration menu

⇒ Select “Save Setup as dfl” to save the default setup

⇒ Select “Exit from Minicom” to exit the program

⇒ Run Minicom

/$ minicom -o

⇒ Power on the board (5V) and wait

⇒ The device demands the username (maybe the password)

overo login: root

⇒ It works, you can move into the tree

root@overo:~# cd /
root@overo:/# ls
bin   dev  home  linuxrc     media  proc  sys  usr                              
boot  etc  lib   lost+found  mnt    sbin  tmp  var  

⇒ To turn off the Gumstix Overo COM

root@overo:/# shutdown 0
                                                                              

Broadcast message from root (ttyS2) (Mon Mar 28 06:59:10 2011): The system is going down to maintenance mode NOW! INIT: Switching to runlevel: 1 INIT: Sending processes the TERStopping OpenBSD Secure Shell server: sshd. [ ok ]pping Avahi mDNS/DNS-SD Daemon: avahi-daemon Stopping Bluetooth subsystem: hidd pand dund rfcomm hid2hci bluetoothd hciattac. Stopping advanced power management daemon: No /usr/sbin/apmd found running; non. apmd. Stopping Hardware abstraction layer hald Stopping system message bus: dbus. Stopping GPE display manager: gpe-dm Stopping ntpd: done Stopping Network connection manager daemon: NetworkManager. Deconfiguring network interfaces… done. Stopping portmap daemon: portmap. Stopping syslog-ng:. INIT: no more processes left in this runlevel

⇒ The device is well stopped

⇒ Quit the Minicom program

[CTRL - a] [z] [q] [YES]

→ Unplug the power supply

→ Unplug the USB cables


A-Z Build your own complete Linux Distribution for embedded systems


Context

There are three files required on the first (FAT) partition to boot your Overo

- MLO : the boot-loader loader

- u-boot.bin : the boot loader

- uImage : the Linux kernel

You can build these yourself or download pre-built images but these three files must be named as stated above

What is Openembedded

Openembedded is the build framework for embedded Linux

OpenEmbedded is a set of metadata used to cross-compile, package and install software packages

OpenEmbedded is being used to build and maintain a number of embedded Linux distributions

OpenEmbedded provides a powerful means of creating customized root file systems and cross-compiling, packaging, and deploying software

Définition du rapport de Guillaume :

Open Embedded est un outil qui gère les différentes versions de Linux et qui met à disposition les fichiers utiles

pour la création d’un noyau Linux pour les applications embarquées. C’est un des meilleurs outils pour la gestion de

la compilation croisée. Il permet aux développeurs de créer leur propre distribution de Linux pour les systèmes

embarqués. Une grande communauté de développeurs utilise et améliore les versions de Linux, Open Embedded permet de

télécharger les dernières versions stables et met à disposition de nouvelles versions régulièrement. Open Embedded

met également des versions de Linux pré-compilées à disposition, dans ce cas on ne peut faire aucune modification du

noyau Linux. Ceci est utile afin d’effectuer des tests sans se préoccuper de la compilation du noyau, on dispose

alors d’une image de Linux compilée par Open Embedded.

What is Bitbake

Bitbake is a tool for executing tasks and managing metadata

At the heart of OE is the Bitbake tool which resolves dependencies between different software packages in order to build a complete embedded system as make is to source code

Although BitBake can build individual packages, it is often more useful to build a set of packages and combine them into an image

The OpenEmbedded (OE) system consists of a collection of·BitBake “recipes”

Gumstix uses the OpenEmbedded build environment so developers can create a complete Linux Distribution for embedded systems

Définition de Guillaume :

Bitbake est un outil qui permet de compiler et de faire de la compilation croisée avec les fichiers utiles à la

création d’un noyau Linux. Cet outil est à la base de Open Embedded, il permet d’exécuter les différentes tâches

utiles à la création d’une image Linux. Pour la création du noyau Linux, Open Embedded utilise un système de recette,

elles permettent de compiler chaque partie du noyau Linux. Une recette est une succession de tâches à ex exécuter,

Bitbake permet exécuter ces tâches une à une et de gérer les indépendances entre les tâches.

→ Basic variable setting

VARIABLE = "value"

⇒ VARIABLE is value

→ Variable expansion

A = "aval"
B = "pre${A}post"

⇒ A containing aval and B containing preavalpost

→ Immediate variable expansion := (le contenu d'une variable est élargi ; elle a déjà qqchose, mais on lui rajoute des infos)

C = "cval"
C := "${C}append"

⇒ C would be cvalappend

→ Appending += and prepending =+ = ajouter des préfixes et suffixes au contenu d'une variable

B = "bval"
B += "additionaldata"
C = "cval"
C =+ "test"

⇒ B is now bval additionaldata and C is test cval

→ Appending .= and prepending =. without spaces = même chose que += et =+ sans les espaces

B = "bval"
B .= "additionaldata"
C = "cval"
C =. "test"

⇒ B is now bvaladditionaldata and C is testcval

→ Conditional metadata set

OVERRIDES is a “:” seperated variable containing each item you want to satisfy conditions
OVERRIDES = "architecture:os:machine"
TEST = "defaultvalue"
TEST_os = "osspecificvalue"
TEST_condnotinoverrides = "othercondvalue"

⇒ TEST would be osspecificvalue, due to the condition “os” being in OVERRIDES

→ Conditional appending

DEPENDS = "glibc ncurses"
OVERRIDES = "machine:local"
DEPENDS_append_machine = " libmad"

⇒ DEPENDS is set to glibc ncurses libmad

→ Inclusion

include directive, which causes BitBake to parse in whatever file you specify, and insert it at that location

→ Requiring Inclusion

require will raise an ParseError if the to be included file can not be found.

→ Defining executable metadata (only supported in .bb and .bbclass files.)

do_mytask () {
  echo "Hello, world!"
}

→ Inheritance

inherit directive is a means of specifying what classes of functionality your .bb requires

→ Tasks (only supported in .bb and .bbclass files.)

⇒ Each step that needs to be run for a given .bb is known as a task

⇒ There is a command addtask to add new tasks (must be a defined python executable metadata and must start with “do_”) and describe intertask dependencies

python do_printdate () {
  import time
  print time.strftime('%Y%m%d', time.gmtime())
}
addtask printdate before do_build

⇒ defines the necessary python function and adds it as a task which is now a dependency of do_build

→ Events (only supported in .bb and .bbclass files.)

BitBake allows to install event handlers (gestionnaires d'évenements)

Events are triggered at certain points during operation, such as, the beginning of operation

addhandler myclass_eventhandler
python myclass_eventhandler() {
  from bb.event import NotHandled, getName
  from bb import data
  print "The name of the Event is %s" % getName(e)
  print "The file we run for is %s" % data.getVar('FILE', e.data, True)
  return NotHandled
}

A BitBake (.bb) file is a logical unit of tasks to be executed. Normally this is a package to be built.

bbread  = command for displaying BitBake metadata
bitbake = primary command in the system - executing a given task

Executing a task with a single .bb (executer une commande bitbake sur un seul fichier.bb)

bitbake -b fil.bb
Executing tasks with a set of .bb files

bitbake fil.bb

Executing tasks with a set of .bb files & continue as much as possible after an error
bitbake -k file.bb

File Download supports :

→ Local File Fetcher

SRC_URI= "file://relativefile.patch"

→ CVS File Fetcher

SRC_URI = "cvs://CVSROOT;module=mymodule;tag=some-version;method=ext"

→ HTTP/FTP Fetcher

SRC_URI = "http://oe.handhelds.org/not_there.aac;md5sum=12343"
SRC_URI = "ftp://oe.handhelds.org/not_there_as_well.aac;md5sum=1234"

→ SVN Fetcher

SRC_URI = "svn://svn.oe.handhelds.org/svn;module=vip;proto=http;rev=667"

→ GIT Fetcher

SRC_URI = "git://git.oe.handhelds.org/git/vip.git;tag=version-1"

Git is a free & open source, distributed version control system designed to handle everything from small to very large projects with speed and efficiency

Git est un logiciel de gestion de versions décentralisée

→ Bitbake command needed to build a particular piece of software

bitbake x-load MLO (OMAP3 bootstrap loader)

bitbake u-boot-omap3 u-boot (boot loader)

bitbake virtual/kernel linux kernel

bitbake omap3-console-image Gumstix console image

bitbake omap3-palmtop-image Gumstix palmtop image

bitbake omap3-desktop-nand-image Gumstix desktop-nand image

bitbake omap3-desktop-image Gumstix desktop image

bitbake sakoman-gnome-image unofficial Gnome-based desktop image

Openembedded installation

→ Create the “overo-oe” directory and change directory into it

/$ mkdir -p ~/overo-oe
/$ cd ~/overo-oe
~/overo-oe$ pwd
/home/thomas/overo-oe

→ Then we will install the OE metadata, and check out the Overo branch (you can safely ignore the warnings you will get from the git commands)

(Git = distributed revision control system with a rich command set that provides both high-level operations and full access to internals

logiciel de gestion de version décentralisée

git clone = Clone a repository into a new directory)

~/overo-oe$ git clone git://gitorious.org/gumstix-oe/mainline.git org.openembedded.dev

Initialized empty Git repository in /home/thomas/overo-oe/org.openembedded.dev/.git/ remote: Counting objects: 397395, done. remote: Compressing objects: 100% (123308/123308), done. remote: Total 397395 (delta 269982), reused 391595 (delta 264327) Receiving objects: 100% (397395/397395), 151.25 MiB | 280 KiB/s, done. Resolving deltas: 100% (269982/269982), done. Checking out files: 100% (24090/24090), done.

⇒ Files are downloaded around 1 hour

⇒ org.openembedded.dev is downloaded

(git-checkout (commande) : a branch or paths to the working tree

–track : when creating a new branch, set up “upstream” configuration

-b : create a new branch named <new_branch> and start it at <start_point>)

→ Enter in the file

~/overo-oe$ cd org.openembedded.dev
~/overo-oe/org.openembedded.dev$ git checkout --track -b overo origin/overo

Branch overo set up to track remote branch overo from origin. Switched to a new branch 'overo'

BitBake installation

~/overo-oe/org.openembedded.dev$ cd ~/overo-oe
~/overo-oe$ pwd
/home/thomas/overo-oe
~/overo-oe$ git clone git://git.openembedded.net/bitbake bitbake

remote: Counting objects: 15674, done. remote: Compressing objects: 100% (4782/4782), done. remote: Total 15674 (delta 9560), reused 15600 (delta 9517) Receiving objects: 100% (15674/15674), 2.81 MiB | 42 KiB/s, done. Resolving deltas: 100% (9560/9560), done.

⇒ It takes around 1 minute

~/overo-oe$ cd bitbake
~/overo-oe/bitbake$ git checkout 1.10.2

Creating the OE configuration files and profile

We now will create a profile script and the configuration files required to tailor OE to our needs

→ Copy these files (-r, –recursive = copy directories recursively)

~/overo-oe$ cp -r org.openembedded.dev/contrib/gumstix/build .

⇒ The '.' is important here

Environment setup

OpenEmbedded requires some environment setup in order to function properly

You can set this up via your bash profile

⇒ bashrc is run when you open a Terminal

→ Copy (.bak = backup = save file)

~/overo-oe$ cp ~/.bashrc ~/bashrc.bak

(cat affiche sur la sortie standard le contenu de chacun des fichiers indiqués

(» redirige à la fin d'un fichier et le crée s'il n'existe pas)

~/overo-oe$ cat ~/overo-oe/build/profile >> ~/.bashrc

→ Close your terminal window and open a new one (so that the environment changes you enabled above will take effect)

First build

You can build a basic kernel and non-gui root file system image in one step with

~/overo-oe$ bitbake omap3-console-image

You can build the kernel and modules using bit-bake. This allows you to incorporate the kernel with camera driver into an image of your design

⇒ It takes a long time (around 2 days) and 40 GB to 60 GB

⇒ At the end, you should have this directory layout (configuration)

a file overo-oe where there is

- bitbake # contains the bitbake tool and its associated configuration files

- build # contains configuration data for the build system : # auto.conf is used primarily to specify what machine configuration the build is targeted toward # local.conf is used to specify build policy # site.conf is used for general configuration

- org.openembedded.snapshot # contains a snapshot of the OpenEmbedded development branch ; it contains the “recipes” to build many hundreds of software packages

- com.gumstix.collection # contains overrides to the standard OpenEmbedded recipes ; this is where all of the gumstix specific customizations reside

- user.collection # this directory is yours to use ; you should place your custom recipes here

- extras # contains a variety of useful, related material

- tmp # where the build system keeps its working files and also where it places the output of the build

..- cache # where bitbake caches information it obtains from parsing all available .bb files

..- stamps # contains zero length files that are used to track each phase of the build as it is completed

..- cross # contains the cross development tools for generating code for the gumstix procesor (compliers, linkers, etc.)

..- staging (mise en scene) # Header files, libraries, and other items needed by the build system are stored in this directory

..- work # where the real work gets done ; a subdirectory is created for each package that is built

..- rootfs # after an image recipe build this directory will contain the complete root file system for the image

..- deploy # contains the final output of the build process : a set of images and ipkg files

Writing a .bb file

⇒ A bitbake recipe is a set of instructions that describes what needs to be done to :

- retrieve the source code for some application

- apply any necessary patches

- provide any additional files (such as init scripts)

- compile it

- install it

- generate binary packages

⇒ The end result is a binary package that you can install on your target device

(If you need a customized root filesystem)

→ Package description, license, etc

DESCRIPTION = "My first application, a really cool app containing lots of foo and bar"
LICENSE = "GPLv2"
HOMEPAGE = "http://www.host.com/foo/"

→ The next step is to specify what the package needs to build and run, the so called dependencies

DEPENDS = "gtk+"
RDEPENDS = "cool-ttf-fonts"

⇒ The package needs gtk+ to build ('DEPENDS') and requires the 'cool-ttf-fonts' package to run

⇒ You need to specify everything else by yourself, which in this case is the 'cool-ttf-fonts' package

⇒ OE will know what to build before trying to build your application

→ Add the source location

SRC_URI = "http://www.host.com/foo/files/${P}.tar.bz2;md5sum=yoursum"

⇒ This will tell the fetcher where to download the sources from and it will check the integrity using md5sum if you provided the appropriate yoursum

→ You can make one by doing

md5sum foo-1.9.tar.bz2

→ replace yoursum with the md5sum on your screen. A typical md5sum will look like this

a6434b0fc8a54c3dec3d6875bf3be868

⇒ Before we can move to the actual building we need to find out which build system the package is using inherit autotools pkgconfig

→ Lets start the build

bitbake foo

⇒ The following files where installed but not shipped = /usr/weirdpath/importantfile.foo

⇒ OE has a standard list of paths which need to be included, but it can't know everything, so we have to tell OE to include that file as well

FILES_${PN} += "/usr/weirdpath/importantfile.foo"

Syntax of recipes :

- Functions (series of actions to be performed)

do_install () {
  autotools_do_install
  install -d ${D}${base_bindir}
  mv ${D}${bindir}/sed ${D}${base_bindir}/sed.${PN}
}

- Variable assignments and manipulations

S = "${WORKDIR}/postfix-${PV}"
PR = "r4"
CFLAGS += "-DNO_ASM"
SRC_URI_append = "file://fixup.patch"

- Keywords

export POSTCONF = "${STAGING_BINDIR}/postconf"
inherit autoconf
require otherfile.inc

- Comments

# This is a comment

- Line continuation: \ = To split a statement over multiple lines you should place a \ at the end of the line that is to be continued on the next line

VAR = "A really long \
       line"

- Using variables: ${...} = To access the contents of a variable you need to access it via ${<varname>}:

SRC_URI = "${SOURCEFORGE_MIRROR}/libpng/zlib-${PV}.tar.gz"

- Quote all assignments = All variable assignments should be quoted with double quotes

VAR1 = "${OTHERVAR}"

- Conditional assignment = is used to assign a value to a variable, but only when the variable is currently unset (commonly used to provide a default value)

VAR1 = "Original value"
VAR1 ?= "New value"

⇒ Will set VAR1 to “New value” if it is currently empty (vide)

⇒ VAR1 is left with the value “Original value” - Appending: += = You can append values to existing variables

SRC_URI += "file://fix-makefile.patch"

- Prepending: =+ = You can prepend values to existing variables

VAR =+ "Starts"

- Appending: _append = You can append values to existing variables

SRC_URI_append = " file://fix-makefile.patch"
SRC_URI_append += "file://fix-install.patch"

- Prepending: _prepend = You can prepend values to existing variables

Expected format of recipe name :

<package-name>_<version>.bb

for example : strace_4.5.14.bb

Bitbake Tutorial Example

OpenEmbedded provides a powerful means of creating customized root file systems and cross-compiling, packaging, and deploying software

to harness this power, it is necessary to write Bitbake recipes !!!

This tutorial steps through the creation of a basic recipe—the configuration file that tells Bitbake how to build your source code

Making a hello.c file with the following content :

→ Create a directory for our recipe, recipes/myhelloworld, and we've created a files subdirectory in there to store our local files

$ mkdir recipes/myhelloworld
$ mkdir recipes/myhelloworld/files
$ cat > recipes/myhelloworld/files/myhelloworld.c
#include <stdio.h>
int main()
{
      printf("Hello world!\n");
      return 0;
}
^D
$ cat > recipes/myhelloworld/files/README.txt
Readme file for myhelloworld.
^D

⇒ We've created two local files, the C source code for our helloworld program and a readme file

→ Create the bitbake recipe helloworld_0.0.bb

DESCRIPTION = "hello world program"  # describe this package
PR = "r0"                            # specifies the package revision
SRC_URI = "file://hello.c"           # specifies where the source code can be found (here the same directory as our recipe file)
S = "${WORKDIR}"                     # refers to the directory where Bitbake unpacks the source ; by default the WORKDIR
do_compile () {                      # it gives the details of how to compile the package (use standard C cross-compiler ... ; output file = hello ; source file = hello.c ; binary sitting in S)
 ${CC} ${CFLAGS} ${LDFLAGS} -o hello hello.c
}
do_install () {
 install -d ${D}${bindir}/
 install -m 0755 ${S}/hello ${D}${bindir}/
}
FILES_${PN} = "${bindir}/hello"      # Linux install command (create the directory where we wish to our hello program if the directory doesn't yet exist and then asks it to copy our application to this directory)

(Bitbake builds a recipe by executing a series of steps: fetching code, unpacking, compiling, linking, staging, and packaging

If our code needs a library to compile, we specify this using the DEPENDS or the RECOMMENDS keyword in our recipe

To specify runtime dependencies, use the RDEPENDS and RRECOMMENDS keywords

The PROVIDES and RPROVIDES variables are, correspondingly, the names given to your recipe in case other packages rely on your package)

→ Build the package

$ bitbake -b recipes/myhelloworld/myhelloworld_0.0.bb

⇒ The package was successfully built, the output consists of two .ipkg files, which are ready to be installed on the target

→ Look at the working directory to see where various files ended up

$ find tmp/work/myhelloworld-0.0-r0

⇒ The two source files are in tmp/work/myhelloworld-0.0-r0, which is the working directory as specified via the ${WORKDIR} variable

=> There's an image directory at tmp/work/myhelloworld-0.0-r0/image ; this is actually the destination directory, as specified via the ${D} variable

⇒ The program was actually compiled in the tmp/work/myhelloworld-0.0-r0/myhelloworld-0.1 directory (this is the source directory as specified via the ${S} variable)

-> Check that we really did produce a binary for the target and not for our host system
  $ file tmp/work/myhelloworld-0.0-r0/install/myhelloworld/usr/bin/myhelloworld tmp/work/myhelloworld-0.0-r0/install/myhelloworld/usr/bin/myhelloworld: ELF 32-bit LSB executable, Hitachi SH, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), for GNU/Linux 2.4.0, not stripped

$ file /bin/ls

/bin/ls: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), for GNU/Linux 2.4.0, stripped

⇒ This shows us that the helloworld program is for an SH processor


A-Z Boot with own built files on MicroSD Card


Context

There are three files required on the first (FAT) partition to boot your Overo

- MLO : the boot-loader loader

- u-boot.bin : the boot loader

- uImage : the Linux kernel

We consider that we have built these images.

Load the images in the MicroSD

→ MLO is not necessary

→ Find u-boot and uImage : /home/thomas/overo-oe/tmp/deploy/glibc/images/overo

~/overo-oe/tmp/deploy/glibc/images/overo$ ls

Angstrom-omap3-console-image-glibc-ipk-2010.7-test-20110411-overo.rootfs.tar.bz2 Angstrom-omap3-console-image-glibc-ipk-2010.7-test-20110411-overo-testlab modules-2.6.36-r100-overo.tgz omap3-console-image-overo.tar.bz2 u-boot-overo-2010.9+r1+git1e4e5ef0469050f014aee1204dae8a9ab6053e49-r1.bin u-boot-overo.bin uImage-2.6.36-r100-overo.bin uImage-overo.bin

→ Copy u-boot-overo.bin in the ROOT partition (1) and name it u-boot.bin

~/overo-oe/tmp/deploy/glibc/images/overo$ sudo cp u-boot-overo.bin /media/ROOT/u-boot.bin

→ Copy uImage-overo.bin in the ROOT partition (1) and name it uImage

~/overo-oe/tmp/deploy/glibc/images/overo$ sudo cp uImage-overo.bin /media/ROOT/uImage

→ Unmount the ROOT partition

~/overo-oe/tmp/deploy/glibc/images/overo$ sudo umount /dev/sdc1

→ Copy omap3-console-image-overo.tar.bz2 in the rootfs partition (2)

~/overo-oe/tmp/deploy/glibc/images/overo$ sudo cp omap3-console-image-overo.tar.bz2 /media/rootfs

→ Untar it

/media/rootfs$ sudo tar -xvaf omap3-console-image-overo.tar.bz2

→ You can remove omap3-console-image-overo.tar.bz2 if you want

→ Unmount the rootfs partition

/media$ sudo umount /dev/sdc2

→ If you want to set up a serial connection, go on “Setting up a Serial Connection”


A-Z Incorporate the kernel with MT9V032 Caspapx camera driver


Context

We want to plug a module camera CMOS APTINA mt9v032/mt9v034 caspa px with the Gumstix

Build the kernel and modules using bit-bake

This allows you to incorporate the kernel with camera driver into an image of your design

~/overo-oe/org.openembedded.dev$ git pull origin overo

⇒ git-pull = Fetch from and merge with another repository or a local branch

~/overo-oe/org.openembedded.dev$ bitbake linux-omap3-caspapx

When the build completes, the kernel and modules will appear in ~/overo-oe/tmp/deploy/glibc/images/overo


A-Z Customize the camera driver and kernel for our needs


Context

We want to plug a module camera CMOS APTINA mt9v032/mt9v034 caspa px with the Gumstix

The version of the kernel is here 2.6.34

Tasks

→ Get the kernel source that and create a new branch from the recipe SRCREV

$ cd ~
$ git clone git://www.sakoman.com/git/linux-omap-2.6.git
$ cd linux-omap-2.6
$ git checkout -b 2.6.34 cb89736af28f583598e49a05249334a194d00f1d

→ Get the patch

$ wget http://cumulus.gumstix.org/sources/mt9v032-2.6.34.patch
$ patch -p1 < mt9v032-2.6.34.patch

→ Get the kernel configuration

$ wget http://cumulus.gumstix.org/sources/mt9v032-2.6.34.defconfig
$ cp mt9v032-2.6.34.defconfig .config

→ Rebuild

$ bitbake omap3-console-image

→ Add the cross compiler to your path and configure the kernel

⇒ It depends on the number of bits of the kernel ; if you don't know, use “uname -a” command

32-bit processors ⇒ C'est notre cas

$ export PATH=/home/<username>/overo-oe/tmp/sysroots/i686-linux/usr/armv7a/bin:${PATH} 

64-bit processors

$ export PATH=/home/<username>/overo-oe/tmp/sysroots/x86_64-linux/usr/armv7a/bin:${PATH}

→ Build the kernel and the modules

$ make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage
$ make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- modules

→ Install the modules

$ mkdir ~/linux-omap-2.6/modules
$ make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- INSTALL_MOD_PATH=./modules modules_install

→ Test the new driver

#! /bin/bash 
TARGET_OVERO="root@10.0.1.15"
make -j8 ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- modules
ssh $TARGET_OVERO 'rmmod mt9v032'
scp drivers/media/video/mt9v032.ko $TARGET_OVERO:/lib/modules/2.6.34/kernel/drivers/media/video/
ssh $TARGET_OVERO 'insmod /lib/modules/2.6.34/kernel/drivers/media/video/mt9v032.ko'
ssh $TARGET_OVERO 'mplayer -display :0.0 tv:// -tv driver=v4l2:device=/dev/video0'

A-Z Use the camera driver in 2.6.36 version


Context

We want to plug a module camera CMOS APTINA mt9v032/mt9v034 caspa px with the Gumstix

The version of the kernel is here 2.6.36

The camera drivers are made for 2.6.34 version

We want to modify the driver and patch 2.6.34 → 2.6.36

Tasks

In comparison with “A-Z Customize the camera driver and kernel for our needs”

→ We have the kernel source and we have modified the name of the folder

$ cd linux-omap-2.6-thomas
$ git checkout -b 2.6.36 6673cc25f781e61cb2d20e2a830047959d3f7801

→ Get the patch (if you don't have it yet)

$ wget http://cumulus.gumstix.org/sources/mt9v032-2.6.34.patch
$ patch -p1 < mt9v032-2.6.34.patch

→ Rename it “mt9v032-2.6.36.patch”

We have removed :

< diff –git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile

< index d28e9e5..e1e4a0c 100644

< — a/arch/arm/mach-omap2/Makefile

< +++ b/arch/arm/mach-omap2/Makefile

< @@ -89,7 +89,7 @@ obj-$(CONFIG_OMAP3_EMU)			+= emu.o

<  obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox_mach.o

< mailbox_mach-objs := mailbox.o

< -obj-$(CONFIG_OMAP_IOMMU)		:= iommu2.o omap-iommu.o

< +obj-$(CONFIG_OMAP_IOMMU) += iommu2.o omap-iommu.o

< i2c-omap-$(CONFIG_I2C_OMAP)		:= i2c.o

<  obj-y					+= $(i2c-omap-m) $(i2c-omap-y)

-> Get the kernel configuration
  $ wget http://cumulus.gumstix.org/sources/mt9v032-2.6.34.defconfig

$ cp mt9v032-2.6.34.defconfig .config

→ Rebuild

$ bitbake omap3-console-image

→ Add the cross compiler to your path and configure the kernel

⇒ It depends on the number of bits of the kernel ; if you don't know, use “uname -a” command

32-bit processors ⇒ C'est notre cas

$ export PATH=/home/<username>/overo-oe/tmp/sysroots/i686-linux/usr/armv7a/bin:${PATH} 

64-bit processors

$ export PATH=/home/<username>/overo-oe/tmp/sysroots/x86_64-linux/usr/armv7a/bin:${PATH}

→ Build the kernel and the modules

$ make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage
$ make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- modules

→ Install the modules

$ mkdir ~/linux-omap-2.6/modules
$ make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- INSTALL_MOD_PATH=./modules modules_install

⇒ There is no big modifications to do (it may be different in any case)


A-Z Know the version of the kernel


~$ uname -a

Linux funjet 2.6.31-21-generic #59-Ubuntu SMP Wed Mar 24 07:28:56 UTC 2010 i686 GNU/Linux


A-Z Use the module camera CMOS APTINA mt9v032


ffmpeg

⇒ If you want ot take a video, use ffmpeg :

-f format

-i filename input (ex : /dev/video0)

-t time (seconds)

-fs taille max (bytes)

-b taux (bit/s)

-vframes “number” (number of frames)

-r fps (frames per second)

-s size (ex : 800×600)

-pix_fmt format

-y overwrite if existing

at the end, name of the output file (ex : file.avi)

⇒ Examples :

→ Take a video without restrictions (bad quality) :

ffmpeg -f video4linux2 -i /dev/video0 fileout.avi

→ Take a video : 10 secondes / 60 fps / 752×480 / name = fileout / overwrite if file exists

ffmpeg -f video4linux2 -s 752x480 -r 60 -i /dev/video0 -y fileout.mpeg

A-Z Configure the wifi in 2.6.34 kernel


→ Create confres file

#/bin/sh
insmod /lib/modules/2.6.36+/kernel/net/wireless/lib80211.ko 
insmod /lib/modules/2.6.36+/kernel/drivers/net/wireless/libertas/libertas.ko
insmod /lib/modules/2.6.36+/kernel/drivers/net/wireless/libertas/libertas_sdio.ko
ifconfig wlan1 up
sleep 2
iwconfig wlan1 essid drones
sleep 2
dhclient wlan1

→ Go to /media/rootfs/etc/init.d and past the confres file

root@overo:/media/rootfs/etc/rc5.d# ls -l
total 4
lrwxrwxrwx 1 root root  16 Jan  1  2000 S02dbus-1 -> ../init.d/dbus-1
lrwxrwxrwx 1 root root  14 Jan  1  2000 S09sshd -> ../init.d/sshd
lrwxrwxrwx 1 root root  14 Apr 12 12:59 S20apmd -> ../init.d/apmd
lrwxrwxrwx 1 root root  14 Apr 12 12:59 S20ntpd -> ../init.d/ntpd
lrwxrwxrwx 1 root root  16 Apr 12 12:59 S20syslog -> ../init.d/syslog
lrwxrwxrwx 1 root root  22 Jan  1  2000 S21avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx 1 root root  19 Apr 12 12:59 S23bluetooth -> ../init.d/bluetooth
lrwxrwxrwx 1 root root  20 Apr 12 12:59 S50usb-gadget -> ../init.d/usb-gadget
lrwxrwxrwx 1 root root  19 Apr 12 12:59 S99rmnologin -> ../init.d/rmnologin

→ Create a link for confres

[/media/rootfs/etc/rc5.d]% sudo ln -s ../init.d/confres S99network

⇒ This may appear :

root@overo:/media/rootfs/etc/rc5.d# ls -l
lrwxrwxrwx 1 root root 19 Apr 12 17:36 S99network -> /etc/init.d/confres
...

⇒ Then when we reboot the overo, the wifi is automatically up


A-Z Modify mt9v032 driver


Context

We consider that you have a camera caspa px (module camera CMOS APTINA mt9v032)

Create setenvcross

Create a file : setenvcross

#!/bin/sh
export ARCH=arm
export CROSS_COMPILE=/home/thomas/overo-oe/tmp/sysroots/i686-linux/usr/armv7a/bin/arm-angstrom-linux-gnueabi-
export PATH=$PATH:/home/thomas/overo-oe/tmp/sysroots/i686-linux/usr/armv7a/bin/
echo $CROSS_COMPILE

Create the Makefile

Create a file : Makefile

KDIR=/home/thomas/linux-omap-2.6-thomas
PWD=/$(KDIR)/drivers/media/video
obj-m := mt9v032.o
all:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
install:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules_install
clean:
rm -f *~
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) clean
copy:
scp  /home/thomas/overo-oe/tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-caspapx-2.6.36-r100/git/drivers/media/video/mt9v032.ko root@192.168.1.2:~
charge:
ssh  root@192.168.1.2 "cd ~ && insmod mt9v032.ko && dmesg | tail -n 10"
decharge:
ssh  root@192.168.1.2 "cd ~ && rmmod mt9v032.ko && dmesg | tail -n 10"

Modify a file

Cross Compilation

[~/exo/makemodule]% source ./setenvcross
[~/exo/makemodule]% make
[~/exo/makemodule]% make copy

ISP : Image Signal Processor


Context

This part discusses about the Image Signal Processor chipped inside the OMAP35x.

It isn't a complete tutorial, it is an overview of the ISP.

Introduction

The camera ISP is a key component for imaging and video applications.

The camera ISP provides the system interface and the processing capability to connect RAW image-sensor modules to the device.

It provides you to :

- do conversions (RGB → YUV, RGB → RGB …)

- do rezising

- do histograms (for estimations & perform auto-focus, auto-…)

- …

See figures :

⇒ Camera ISP (general)

- Figure 12-53. Camera ISP Block Diagram (p°1371)

- Figure 12-54. Camera ISP/Data Path/RAW RGB Images (p°1373)

- Figure 12-55. Camera ISP/Data Path/YUV4:2:2 Images (p°1374)

- Figure 12-56. Camera ISP/Data Path/JPEG Images (p°1374)

⇒ CCDC

- Figure 12-72. CCDC Block Diagram (p°1394)

⇒ Preview

- Figure 12-78. Preview Engine Block Diagram (p°1408)

⇒ Resizer

- Figure 12-80. Resizer Process(p°1415)

Image sensor

ISP can support interface with various image sensors (RGB, Ye Cy Mg G).

CSI1 : Camera Serial Interface

It is compatible with the MIPI CSI1 specifications (MIPI : Mobile Industry Processor Interface).

This module can :

- transfer pixels and data to system memory os to the video pipeline (way of the data, continue to pass into modules)

- support RGB, RAW, YUV, JPEG formats

- read from memory only in RAW format

CSI2 : Camera Serial Interface

It is more efficient than the CSI1.

It is compatible with the MIPI CSI1 specifications.

This module can :

- transfer pixels and data to system memory os to the video pipeline (way of the data, continue to pass into modules)

- support RGB, RAW, YUV, JPEG formats

- read from memory only in RAW format

- converse RGB formats

- …

CPI : Camera Parallel Interface

It supports two modes :

- SYNC mode : the image-sensor provides horizontal & vertical synchronization signals to the CPI, along with the pixel clock

- ITU mode : the image-sensor provides an ITU-R BT 656-compatible data stream, horizontal & vertical synchronization signals are not provided to the interface

VP : Video Processing

It is a video processing HARDWARE !

The hardware pipeline contains two parts : front en & back end.

⇒ VPFE : Video processing front end = CCDC module

- Performs signal-processing operations on RAW image input data

- The output data can go directly to memory for software processing, or to the video-processing back end for further processing

- Signal processing operations : Optical clamping, Black-level compensation, Data formatter, Output formatter …

⇒ VPBE : Video processing back end = Preview / Resizer modules

- Performs signal-processing operations on RAW image input data and outputs YCbCr 4:2:2 data

- Preview module : A-law decompression (cv non-linear 8-bit data to 10-bit linear data), Noise reduction, Digital gain, White balance, RGB to YCbCr conversion, can work from memory to memory …

- Resizer module : Performs on-the-fly upsampling (up to x4) and downsampling (down to x0.25) of YCbCr 4:2:2 data, can work from memory to memory …

SCM : Statistic collection modules

The host CPU uses statistics to adjust various parameters for processing image data.

⇒ 3A metrics module : collects on-the-fly raw image data metrics to perform white balance, auto focus …

⇒ Histogram : performs on-the-fly pixel binning of raw image, based on color value ranges and regions, can work from memory to memory …

SBL : Central-ressource Shared Buffer Logic

Buffers and schedules memory accesses requested by camera ISP modules

Circular buffers (x2)

They prevent storage of full image frames in memory when data must be pre/post-processed by software

MMU : Memory Managment Unit

Manages virtual-to-physical address translation for external addresses and solves the memory-fragmentation issue

More informations

⇒ Don't worry about the MicroSD, when a module writes in memory, it is RAM

⇒ CCDC module

- The CCDC output is programmable with registers : ISP_CCDC_SYN_MODE (p°1554)

ISP_CCDC_SYN_MODE_SDR2RSZ : (0 disable / 1 enable) out = resizer module
ISP_CCDC_SYN_MODE_VP2SDR  : (0 disable / 1 enable) out = output formatter
ISP_CCDC_SYN_MODE_WEN     : (0 disable / 1 enable) out = memory
ISP_CCDC_SYN_MODE_PACK8   : (0 16b/pxl / 1 8b/pxl) data packing configuration when the data is written to memory

⇒ Preview module

- The input / output is programmable with registers : PRV_PCR (p°1607)

ISP_PRV_PCR_SDRPORT : (0 disable / 1 enable) PREVIEW module memory output port enable
ISP_PRV_PCR_RSZPORT : (0 disable / 1 enable) RESIZER module output port enable
ISP_PRV_PCR_YCPOS   : (0 YCRYCB / 1 YCBYCR / 2 CBYCRY / 3 CRYCBY)
ISP_PRV_PCR_SOURCE  : (0 Video port from the CCDC / 1 Memory)

Be carefull : see (p°1477) Table 12-57. Preview Engine Conditional Configuration Parameters (Table des dépendances des registres)

⇒ Writing in memory isn't programmable : the device is autonomous, it is a hardware system, it chooses the adresses where the writing will be …

⇒ The ISP simulate alone the input format (the user don't communicate it with parameters) : ISP = autonomous

⇒ We can change the RGB to YUV conversion and colors with the matrix values : isppreview.c ligne 91 :

/* CSC Coef Matrix */
{66, 129, 25},
{-38, -75, 112},
{112, -94 , -18}
/* CSC Offset */
{0x0, 0x0, 0x0}

Be carefull :

- Gains are in S10Q8 format (10 signed bits / 8 = fractionnal part ; for example : 2.3 = 1000000011)

- Offsets are in S8Q0 format for chroma and U10Q0 for luma

Y      CSCRY   CSCGY   CSCBY      Rin     YOFST
Cb  =  CSCRCB  CSCGCB  CSCBCB  *  Gin  +  OFSTCB
Cr     CSCRCR  CSCGCR  CSCBCR     Bin     OFSTCR

If you want to have a blanck&white image :

/* CSC Coef Matrix BW */
{66, 129, 25},
{0, 0, 0},
{0, 0, 0}
/* CSC Offset */
{0x0, 0x0, 0x0}

If you want to have a red filtered image :

/* CSC Coef Red */
{66, 0, 0},
{-38, 0, 0},
{112, 0, 0}
/* CSC Offset */
{0x0, 0x0, 0x0}

If you want to have a red constant image :

/* CSC Coef Red */
{0, 0, 0},
{0, 0, 0},
{0, 0, 0}
/* CSC Offset */
{0x0, 0x0, 0x0ff}

⇒ VERY IMPORTANT : The ISP files are compiled and sit in the linux kernel (uImage) !!! NOT WITH MODULES


A-Z Modify ISP drivers


Context

We consider that you have a camera caspa px (module camera CMOS APTINA mt9v032)

Create compcpimage

→ Create a bash program used for compilling and sending the files to the overo by wifi

#!/bin/sh
export PATH=/home/thomas/overo-oe/tmp/sysroots/i686-linux/usr/armv7a/bin:${PATH} 
make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage
export IPOVERO=192.168.1.2
scp /home/thomas/linux-omap-2.6/arch/arm/boot/uImage root@$IPOVERO:/media/mmcblk0p1/
ssh root@$IPOVERO "reboot"

Create recuptestffmpeg

→ Create a bash program used to get the file from the overo → PC

scp root@192.168.1.2:~/fichier.avi ./

Modify a filen take a video and see it

→ Modify a file located in :

/home/thomas/linux-omap-2.6/drivers/media/video/isp

→ For example : we modify the isppreview.c, ligne 91 :

/* CSC Coef Matrix */
{66, 129, 25},
{-38, -75, 112},
{112, -94 , -18}

change it by

/* CSC Coef Matrix */
{66, 0, 0},
{-38, 0, 0},
{112, 0, 0}

→ Save the file

→ Compile it and send it

[~/linux-omap-2.6]% ./compcpimage

⇒ The overo reboot

→ Take a video (see A-Z Use the module camera CMOS APTINA mt9v032)

→ Recover it

[~]% ./recuptestffmpeg 

⇒ You may have the video fichier.avi


DDD : Data Display Debugger


Introduction

DDD is a graphical user interface for debuggers such as GDB.

This is a simple tutorial for understanding how to get and use DDD.

Get DDD

- Open Ubuntu Software Center

- Write ddd in the search toolbar

⇒ It may appear

- Download it

Use DDD

- First, we have to create an executable file :

- Create a new file : prog.c

#include <stdlib.h>
#include <stdio.h>
int main ()
{
int x = 17;

printf ("Start ");

if (x > 100)
	printf ("x > 100 ");
else if (x < 100)
	printf ("x < 100 ");

printf ("End");

return (0);
}

- Compile it with these options : (g = data for debugging (lines of the program))

gcc -g -o prog prog.c

- Open the DDD :

ddd

- File/Open Program : choose the prog (executable)

⇒ The source code may appear

- View/Command tool

⇒ A window may appear (run / interrupt / step / next …)

- You can place a beakpoint by double clicking on a line

- Then run the programm (click on run)

- It will stop at the breakpoint

- To erase it, click right, delete breakpoint

- …


A-Z Save the MicroSD


Context

In order to save all the MicroSD config :

- Partition 1 : ROOT

- Partition 2 : rootfs

Save an image

if : inpute file / of = output file

sudo dd if=/dev/sdc1 of=imROOT
sudo dd if=/dev/sdc2 of=imrootfs

Paste an image

sudo dd if=imROOT of=/dev/sdc1
sudo dd if=imrootfs of=/dev/sdc2

Give an @IP to the Gumstix in function with @MAC


Context

We wanted to give a fixed @IP to the eth0/wlan0 … in fuction with @MAC.

We use a Netgear router.

Choose an @IP

- Open Firefox

- Open the Netgear Router Setup by writing on the toolbar the @IP (réseau) :

http://192.168.1.1/start.htm

⇒ The interface may appear

- Go to LAN IP Setup

- In the box named : Address Reservation, choose add :

- Choose IP Address, Device Name and write the Mac Address

⇒ The the IP may be fixed with the hardware


A-Z Introduction - Gumstix Overo Linux Kernel Debugging with kgdb


Context

This tutorial shows how to debug the linux kernel of a Gumstix Overo.

KGDB is a debugger for the Linux kernel. It requires two machines that are connected via a serial connection.

It makes it possible to place breakpoints in kernel code, step through the code and observe variables.

Get gdb for arm

A common error while using gdb,is using the wrong gdb.

This step is very IMPORTANT :

You may have GDB for ARM architectures !!!

With openembedded :

bitbake gdb-cross gdbserver

⇒ A recipe is created and you may find a binary file :

arm-angstrom-linux-gnueabi-gdb located here /home/thomas/overo-oe/tmp/sysroots/i686-linux/usr/armv7a/bin

⇒ You can run it by writing

./arm-angstrom-linux-gnueabi-gdb

BUT it is not easy to use, that why I recommend you to create a symbolical link :

sudo ln -s ~/overo-oe/tmp/sysroots/i686-linux/usr/armv7a/bin/arm-angstrom-linux-gnueabi-gdb gdbarm

⇒ Now you can run the gdb for arm by writing in your ~/linux file :

./gdbarm

Prepare and build the Linux Kernel with kgdb

You must create a kernel with kgdb enabled and debug info.

- Go in your home linux :

cd ~/linux-omap-2.6-thomas/

- Modify the configuration of the compilation

VERY IMPORTANT : You must edit the configuration for ARM !!!

export ARCH=arm
export CROSS_COMPILE=/home/thomas/overo-oe/tmp/sysroots/i686-linux/usr/armv7a/bin/arm-angstrom-linux-gnueabi-
export PATH=$PATH:/home/thomas/overo-oe/tmp/sysroots/i686-linux/usr/armv7a/bin/
echo $CROSS_COMPILE

- If you want to use the camera Caspa px mt9v032, I recommend you to take this config for the first use

wget http://cumulus.gumstix.org/sources/mt9v032-2.6.34.defconfig
cp mt9v032-2.6.34.defconfig .config
make oldconfig

- Then you can configure the file :

make xconfig

You must see scripts/kconfig/qconf arch/arm/Kconfig else your don't configure well for arm …

⇒ An application may appear

- At the tab Kernel Hacking, tick :

KGDB: kernel debugger
KGDB: use kgdb over the serial console
Compile the kernel with debug info

If you don't find these lines, you can search them (edit/find)

- Build the kernel

make uImage

Use kgdb on the target machine before / during the boot

If you want to debug applications loaded in the boot, you have to stop the boot and run kgdb before the boot

- Run the Overo and stop the autoboot by typing a touch of the keyboard

- Display the environment variables

printenv

⇒ You may see this : (trick - enlarge the window to see all the arguments ; minicom don't display all)

mmcargs=setenv bootargs console=${console} vram=12M ...

- Add these instructions : 

kgdboc=ttyS2,115200 : kgdb over console, port ttyS2, communication speed 1152000 Bauds

kgdbwait : stop the kernel (no boot)

  setenv mmcargs setenv bootargs console=${console} vram=12M omapfb.vram=0:4M omapfb.mode=dvi:${dvimode} omapdss.def_disp=${defaultdisplay} root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait init=/init kgdboc=ttyS2,115200 kgdbwait

saveenv
reset

⇒ Now, the boot may stop and you may see this :

Entering kdb (current=0xcec1d9c0, pid 1) due to Keyboard Entry

kdb>

KDB is running, here you can place breakpoints (bp name_function) or continue (go) ; see others (help) …

BUT this use is limited, and I am going to show you how to debug with KGDB/GDB with 2 machines

- Run kgdb :

kdb> kgdb

⇒ You may see :

Entering please attach debugger or use $D#44+ or $3#33

⇒ KGDB is running on the target machine !

Use gdb on the development machine

- Open a new terminal and run GDB for ARM :

./gdbarm ./vmlinux

⇒ GDB is running on the development machine (gdb)

- Configure the communication speed / the port …

set remotebaud 115200
set debug remote 1
target remote /dev/ttyUSB3

⇒ The two machines are dialoging (… ACK … Packet received:)

⇒ Then you can debug all what you want :

EXAMPLE :

- Place a breakpoint, continue the program, …, quit

break name_function
continue
...
q

Use kgdb after the boot

- On the overo, configure the port, stop the execution, run kgdb

echo ttyS2 > /sys/module/kgdboc/parameters/kgdboc
echo g > /proc/sysrq-trigger

- On the development machine, run gdb

./gdbarm ./vmlinux
set remotebaud 115200
set debug remote 1
target remote /dev/ttyUSB3

A-Z ISP Debugging using kgdb


Context

ISP = Image Signal Processsor.

This tutorial shows how to debug the ISP in the Gumstix Overo Linux Kernel.

Run the kernel debugger

See A-Z Introduction - Linux Kernel Debugging using kgdb

Start debugging

You need to have 2 terminals :

ONE = target machine, kgdb is running …

TWO = development machine, (gdb) is waiting

- Place a breakpoint where you want to analyse the execution :

break ispccdc_config_datapath

⇒ Breakpoint 1 at 0xc02f03f8: file drivers/media/video/isp/ispccdc.c, line 576.

⇒ The debugger has found the function

- Run the program in order to go at the breakpoint

continue

⇒ Now the two terminals are busy

- Open a new terminal and do a connexion by ssh with the overo :

ssh root@192.168.1.8

- Then insert the driver of the camera

insmod mt9v032.ko

⇒ The program stop at the breakpoint 1 ispccdc.c - line 576.

Breakpoint 1, ispccdc_config_datapath …

576 syn_mode = isp_reg_readl(isp_ccdc→dev, OMAP3_ISP_IOMEM_CCDC,

(gdb)

- In order to step :

next

⇒ Now you can move on the kernel and see what is doing by the os

Debug with DDD

DDD = Data Display Debugger is a common graphical user interface to GDB.

See DDD : Data Display Debugger

- Run ddd

ddd --debugger ./gdbarm vmlinux
set remotebaud 115200
set debug remote 1
target remote /dev/ttyUSB3

⇒ You can use DDD (see DDD : Data Display Debugger)


Add RAM on Gumstix Overo


Context

If the Overo is in lack of live memory (RAM), you can use ROM.

We consider we want to use a USB key for adding memory.

Create the partition (SWAP)

- Format the USB key (unique partition)

(if you want to delete partitions, see :

A-Z Create your own bootable MicroSD Card (8GB) / Delete the partitions in a SD Card)

- Plug the USB key in the Gumstix Overo (USB port)

Now we have to create a swap partition : it is memoryspace used when too much memory is used

- Create a swap partition

see : A-Z Create your own bootable MicroSD Card (8GB) / Partitioning the SD card

- Change the partition type to 82 Linux swap / Solaris

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 82

- Apply changes

w

Use the swap

We have to prevent the Gumstix there is a swap partition and activate it

mkswap /dev/sda1
swapon /dev/sda1

Introduction - Profiling with gprof


Context

Gprof is a profiling program which measures statistics of a program

in order to optimize the source code.

It evaluates execution time of each function, do various statistics …

Tutorial : Use of gprof

- Write a program : prog.c

#include <stdlib.h>
#include <stdio.h>

void wait (void)
{
unsigned int y;
for (y = 0 ; y < 50000 ; y++);
}

int main ()
{
unsigned int x;
for (x = 0 ; x < 10000 ; x++)
	wait ();
return (0);
}

- Compile it with these parameters (prog = executable)

gcc -pg -o prog prog.c

- Run the program

./prog

⇒ A file appears : gmon.out

- Write the profiler data in results.txt

gprof prog gmon.out > results.txt

- Read the profiling results

gedit results.txt

⇒ The profiling data may appear !

(time, cumulative, seconds, call, numbers, statistics …)


A-Z Profiling capture program


Context

We want to have an efficient capture program (fast, easy to execute …)

in order to relieve the processor of the target.

We consider the files :

input : YUV picture

output : RGB picture

yuvtorgb.c : program (YUV to RGB conversion)

Create the Makefile

- In a new text file named Makefile, write :

# Makefile - Yuvtorgb Optimisation
# This Makefile can :
#	compile yuvtorgb.c with profiling data
#	execute ./yuvtorgb.c on i picture (in - YUV)
#	display the converted picture o   (out - RGB)
#	display the profiling results
# t.daveloose@laposte.net

# "make all"          => compile + execute + display rgb + display profiling data
all: compile execute display-rgb display-prof

# "make compile"      => compile yuyvtorgb.c with profiling data
compile:
	gcc -pg -o yuvtorgb yuvtorgb.c

# "make execute"      => run yuyvtorgb (100 conversions)
execute:
	./yuvtorgb 752 480 input output 100

# "make display-rgb"  => display rgb picture
display-rgb:
	display -size 752x480 -depth 8 rgb:output

# "make display-prof" => display profiling data
display-prof:
	gprof yuvtorgb gmon.out > results.txt
	gedit results.txt

# "make clean"        => delete all the products
clean:
	rm yuvtorgb
	rm gmon.out
	rm output
	rm results.txt

# "make help"         => display the help menu
help:
	@echo "MAKEFILE YUVTORGB HELP"
	@echo "make              - compile + execute + display rgb + display profiling data"
	@echo "make compile      - compile yuvtorgb.c with profiling data"
	@echo "make execute      - run yuvtorgb (100 conversions)"
	@echo "make display-rgb  - display rgb picture"
	@echo "make display-prof - display profiling data"
	@echo "make clean        - delete all the products"

Use the Makefile

- Modify yuvtorgb.c

- Apply the Makefile

make

For more informations about the Makefile functions, type make help


Improve the quality of the image


Context

We consider that you have a Gumstix Overo with mt9v034 sensor

Modify the parameters

- Boot the Gumstix and go here :

cd /sys/module/mt9v032/parameters

⇒ You may see the parameters

- Write a script called parameters :

chmod a+w /sys/module/mt9v032/parameters/*
echo 0 > /sys/module/mt9v032/parameters/hdr

echo 1 > /sys/module/mt9v032/parameters/hflip
echo 1 > /sys/module/mt9v032/parameters/vflip

cat /sys/module/mt9v032/parameters/hdr
cat /sys/module/mt9v032/parameters/hflip
cat /sys/module/mt9v032/parameters/vflip

- Apply it on the Gumstix

./parameters

⇒ Now, the quality of the image should better


Add boot commands


Context

This tutorial shows how to make a boot.scr file.

It is running before the boot.

Write a script

- Edit a new file named myscript.cmd and write commands inside, for example

setenv mmcargs write-what-you-want

boot.scr building

- Build the boot.scr file

mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "myscript" -d myscript.cmd boot.scr

⇒ It may appear a message like that :

Image Name:   myscript
Created:      Fri May 13 14:58:18 2011
Image Type:   ARM Linux Script (uncompressed)
Data Size:    57 Bytes = 0.06 kB = 0.00 MB
Load Address: 00000000
Entry Point:  00000000
Contents:
 Image 0: 49 Bytes = 0.05 kB = 0.00 MB

- Check that boot.scr exists and place it in the first partition ROOT

⇒ Now, before the boot, the commands in the boot.scr will be done


Add a module or an application / Opkg - Ipkg


Context

If you want to add modules in you Overo.

Check your modules

If you want to check how many modules you have :

$ opkg list | wc -l
17698
$ echo 'src/gz angstrom-base http://www.angstrom-distribution.org/feeds/unstable/ipk/glibc/armv7a/base'  > /etc/opkg/angstrom-base.conf
$ opkg update
...
$ opkg list | wc -l
21755

Now you can update your opkg repository

$ opkg update
Downloading http://www.gumstix.net/feeds/unstable/ipk/glibc/armv7a/base/Packages.gz.
Inflating http://www.gumstix.net/feeds/unstable/ipk/glibc/armv7a/base/Packages.gz.
Updated list of available packages in /var/lib/opkg/base.
...
$ opkg list_installed | grep gcc
libgcc1 - 4.3.3-r17.1.6
$ opkg install task-native-sdk
...

Find a module

A giant repository is here :

http://www.angstrom-distribution.org/repo/

- Download a module and place it in the 2nd partition rootfs

Install a module

- In order to install the module, write :

ipkg module.ipk

If you have questions : t.daveloose@laposte.net


compilation avec paquet paparazzi-omap

fichier Makefile:

OVERO_CC = /opt/paparazzi/omap/overo-oe/tmp/sysroots/i686-linux/usr/armv7a/bin/arm-angstrom-linux-  gnueabi-gcc
CFLAGS += -Wall -std=gnu99
IPOVERO=192.168.31.17
all: 	hello upload exec
hello: hello.c
	$(OVERO_CC) $(CFLAGS) $^ -o $@
clean:
#	rm *.o 
	rm hello
upload:
	scp ./hello root@$(IPOVERO):/home/root/hello
exec:	
	ssh root@192.168.31.17 /home/root/hello

formation gumstix laas

dhclient eth0
gumstixd.1307900820.txt.gz · Dernière modification : 2011/06/12 19:47 de 78.245.92.185