This document is a guide for using a Gumstix computer-on-module by creating your own bootable MicroSD Card (8GB)
→ 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
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
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
→ 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
→ 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
⇒ 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
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
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.
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
→ 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'
~/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
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
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)
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
⇒ 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
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
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.
→ 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”
We want to plug a module camera CMOS APTINA mt9v032/mt9v034 caspa px with the Gumstix
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
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
→ 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'
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
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)
~$ uname -a
Linux funjet 2.6.31-21-generic #59-Ubuntu SMP Wed Mar 24 07:28:56 UTC 2010 i686 GNU/Linux
⇒ 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 : 5 secondes / 60 fps / 752×480 / name = fileout / overwrite if file exists
ffmpeg -f video4linux2 -s 752x480 -r 60 -t 5 -i /dev/video0 -y fileout.mpeg
bitbake -b libgsm_1.0.13.bb bitbake -b ffmpeg_0.5.bb bitbake -b lame_3.98.2.bb bitbake -b ffmpeg_0.5.bb
scp ./armv7a/libgsm-dbg_1.0.13-r2.0.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/libgsm-static_1.0.13-r2.0.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/libgsm-dev_1.0.13-r2.0.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/libgsm1_1.0.13-r2.0.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/ffmpeg-dev_0.5-r17.2.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/gst-plugin-ffmpegcolorspace-dev_0.10.32-r11.1.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/ffmpeg-vhook-dbg_0.5-r17.2.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/ffmpeg-doc_0.5-r17.2.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/ffmpeg-static_0.5-r17.2.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/ffmpeg_0.5-r17.2.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/ffmpeg-x264-presets_0.5-r17.2.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/gst-plugin-ffmpegcolorspace_0.10.32-r11.1.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/ffmpeg-vhook_0.5-r17.2.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/ffmpeg-dbg_0.5-r17.2.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/lame-dbg_3.98.2-r0.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/lame-dev_3.98.2-r0.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/libmp3lame0_3.98.2-r0.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/lame-doc_3.98.2-r0.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/lame_3.98.2-r0.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/libmp3lame-dev_3.98.2-r0.6_armv7a.ipk root@10.31.6.14:~/tmp scp ./armv7a/lame-static_3.98.2-r0.6_armv7a.ipk root@10.31.6.14:~/tmp
puis dans tmp sur gumstix:
opkg install *.ipk
———————————————–
→ 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
We consider that you have a camera caspa px (module camera CMOS APTINA mt9v032)
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 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"
…
[~/exo/makemodule]% source ./setenvcross [~/exo/makemodule]% make [~/exo/makemodule]% make copy
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.
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)
ISP can support interface with various image sensors (RGB, Ye Cy Mg G).
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
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
- …
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
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 …
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 …
Buffers and schedules memory accesses requested by camera ISP modules
They prevent storage of full image frames in memory when data must be pre/post-processed by software
Manages virtual-to-physical address translation for external addresses and solves the memory-fragmentation issue
⇒ 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
We consider that you have a camera caspa px (module camera CMOS APTINA mt9v032)
→ 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=10.31.6.14
scp /home/thomas/linux-omap-2.6.35+/arch/arm/boot/uImage root@$IPOVERO:/media/mmcblk0p1/
ssh root@$IPOVERO "reboot"
→ Or, more simply…
set the environement:
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
then
cd linux-omap-2.6.35+ make module export IPOVERO=10.31.6.14 scp /home/thomas/linux-omap-2.6.35+/arch/arm/boot/uImage root@$IPOVERO:/media/mmcblk0p1/ ssh root@$IPOVERO "reboot"
→ Create a bash program used to get the file from the overo → PC
scp root@192.168.1.2:~/fichier.avi ./
→ 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 is a graphical user interface for debuggers such as GDB.
This is a simple tutorial for understanding how to get and use DDD.
- Open Ubuntu Software Center
- Write ddd in the search toolbar
⇒ It may appear
- Download it
- 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
- …
In order to save all the MicroSD config :
- Partition 1 : ROOT
- Partition 2 : rootfs
if : inpute file / of = output file
sudo dd if=/dev/sdc1 of=imROOT sudo dd if=/dev/sdc2 of=imrootfs
sudo dd if=imROOT of=/dev/sdc1 sudo dd if=imrootfs of=/dev/sdc2
We wanted to give a fixed @IP to the eth0/wlan0 … in fuction with @MAC.
We use a Netgear router.
- 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
dhclient eth0 export http_proxy=http://squid:3128
to do that automatically at startup, edit /etc/init.d/dhcl
sleep 3 dhclient eth0 export http_proxy=http://squid:3128
and create a symlink in /etc/rc5.d/S99dhcl
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.
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
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
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 !
- 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
- 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
ISP = Image Signal Processsor.
This tutorial shows how to debug the ISP in the Gumstix Overo Linux Kernel.
See A-Z Introduction - Linux Kernel Debugging using kgdb
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
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)
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.
- 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
We have to inform the Gumstix there is a swap partition and activate it
mkswap /dev/sda1 swapon /dev/sda1
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 …
- 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 …)
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
prog.c : program (here YUV to RGB conversion)
But this tutorial may be applied for different uses (general uses)
In order to well execute the operations, it will be necessary to create 2 folders :
- Folder /home/root/SCO/ (TARGET)
- Folder /home/thomas/SCO/ (DEVELOPMENT)
- On the DEVELOPMENT machine :
cd /home/thomas/SCO/
- In a new text file named Makefile, write :
# MAKEFILE - SOURCE CODE OPTIMIZATION (SCO) - (DEVELOPMENT) # # Cross-compiles prog.c / Executes prog / Displays profiling data # Needs 2 machines (DEVELOPMENT X86 / TARGET ARM) # # This Makefile can : # cross-compile prog.c with profiling data (DEVELOPMENT) # send prog & input & send-results to target (DEVELOPMENT -> TARGET) # execute ./prog on input file (TARGET / DEVELOPMENT) # display output (if picture) (DEVELOPMENT) # display the profiling results (DEVELOPMENT) # # Requirements : # Folder /home/root/SCO/ (TARGET) # Folder /home/thomas/SCO/ (DEVELOPMENT) # # t.daveloose@laposte.net # @IP Host machine IPDEV = 10.31.6.12 # @IP Target machine (Gumstix Overo) IPOVERO = 10.31.6.14 # Cross-compiler path ARM-GCC_arm = /opt/paparazzi/omap/overo-oe/tmp/sysroots/i686-linux/usr/armv7a/bin/arm-angstrom-linux-gnueabi-gcc ARM-GCC_x86 = /usr/bin/gcc-4.5 # "make" => compiles + executes all: allarm allarm: compile_arm send execute_arm allx86: compile_x86 executex86 # "make compile_arm" => cross-compiles prog.c with profiling data + sends them to target compile_arm: @echo "COMPILATION FOR ARM" $(ARM-GCC_arm) -pg -O3 -o prog prog.c fixpawd.c fixpawd_math.c # "make compile_X86" => cross-compiles prog.c with profiling data + sends them to target compile_x86: @echo "COMPILATION FOR X86" $(ARM-GCC_x86) -pg -O3 -o prog prog.c fixpawd.c fixpawd_math.c # "make send" => sends prog + input + send-results (target program) to target send: @echo "SEND" cd /home/thomas/SCO/ scp prog root@$(IPOVERO):/home/root/SCO/ scp input root@$(IPOVERO):/home/root/SCO/ scp send-results root@$(IPOVERO):/home/root/SCO/ ssh root@$(IPOVERO) "cd /home/root/SCO/ && chmod a+x send-results" # "make execute_arm" => executes prog in the target execute_arm: @echo "EXECUTION FOR ARM" ssh root@$(IPOVERO) "cd /home/root/SCO/ && ./prog 752 480 input output outputrgb 10" # "make execute_x86" => executes prog in the development machine execute_x86: @echo "EXECUTION FOR X86" ./prog 752 480 input output outputrgb 10 # "make display-picture" => display outputrgb if picture display-picture: @echo "DISPLAY PICTURE" display -size 752x480 -depth 8 rgb:outputrgb rgb:input # "make display-prof" => display profiling data display-prof: @echo "DISPLAY PROFILING DATA" gprof prog gmon.out > results.txt gedit results.txt # "make clean" => delete all the products clean: @echo "CLEAN" rm prog rm gmon.out rm output rm outputrgb rm results.txt ssh root@$(IPOVERO) "cd /home/root/SCO/ && rm prog gmon.out input output send-results" # "make help" => display the help menu help: @echo "MAKEFILE SOURCE CODE OPTIMIZATION (DEVELOPMENT) HELP" @echo "Folder requirements : " @echo "/home/root/SCO/ on target machine" @echo "/home/thomas/SCO/ on development machine" @echo "Commands : " @echo "make - compiles + executes" @echo "make compile_arm - cross-compiles prog.c with profiling data + sends them to target" @echo "make compile_X86 - cross-compiles prog.c with profiling data + sends them to target" @echo "make send - sends prog + input + send-results (target program) to target" @echo "make execute_arm - executes prog in the target" @echo "make execute_x86 - executes prog in the development machine" @echo "make display-picture - display output if picture" @echo "make display-prof - display profiling data" @echo "make clean - delete all the products"
- In a new text file named send-results, write :
# SCRIPT - SOURCE CODE OPTIMIZATION (SCO) - (TARGET) # # Sends output + gmon.out to development machine # Needs 2 machines (DEVELOPMENT X86 / TARGET ARM) # # This script can : # send output & gmon.out files (TARGET -> DEVELOPMENT) # # Requirements : # Folder /home/root/SCO/ (TARGET) # Folder /home/thomas/SCO/ (DEVELOPMENT) # # t.daveloose@laposte.net cd /home/root/SCO/ scp output gmon.out thomas@10.31.6.12:/home/thomas/SCO/
- Modify prog.c
- Apply the Makefile (development)
make
- Apply the script (target)
./send-results
- Apply the Makefile (development)
make display-prof
…
For more informations about the Makefile functions, type :
make help
We consider that you have a Gumstix Overo with mt9v034 sensor
- 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
This tutorial shows how to make a boot.scr file.
It is running before the boot.
- Edit a new file named myscript.cmd and write commands inside, for example
setenv mmcargs write-what-you-want
- 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
If you want to add modules in you Overo.
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 ...
A giant repository is here :
http://www.angstrom-distribution.org/repo/
- Download a module and place it in the 2nd partition rootfs
- In order to install the module, write :
ipkg module.ipk
It is not a tutorial, I never have try it ! (Summary of found informations)
media-ctl = program for configuring ISP
yavta = program for using camera
git clone git://linuxtv.org/pinchartl/media.git git branch -a git checkout -b omap3isp-next-omap3isp remotes/origin/omap3isp-next-omap3isp 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
From ed2bf9e424ce0a1fad62bb6cb86c436c11e356e6 Mon Sep 17 00:00:00 2001
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: Fri, 8 Apr 2011 14:05:07 +0200
Subject: [PATCH] board-overo: Add Caspa camera support
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm/mach-omap2/board-overo.c | 62 +++++++++++++++++++++++++++++++++++++
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index cb26e5d..4443b4a 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -65,6 +65,67 @@
#define OVERO_SMSC911X2_CS 4
#define OVERO_SMSC911X2_GPIO 65
+#if defined(CONFIG_VIDEO_OMAP3) || defined(CONFIG_VIDEO_OMAP3_MODULE)
+
+#include <media/mt9v032.h>
+#include "../../../drivers/media/video/omap3isp/isp.h"
+#include "../../../drivers/media/video/omap3isp/ispreg.h"
+#include "devices.h"
+
+#define MT9V032_I2C_ADDR 0x5c
+#define MT9V032_I2C_BUS_NUM 3
+
+static void mt9v032_set_clock(struct v4l2_subdev *subdev, unsigned int rate)
+{
+ struct isp_device *isp = v4l2_dev_to_isp_device(subdev->v4l2_dev);
+
+ isp->platform_cb.set_xclk(isp, rate, ISP_XCLK_A);
+}
+
+static struct mt9v032_platform_data caspa_mt9v032_platform_data = {
+ .clk_pol = 0,
+ .set_clock = mt9v032_set_clock,
+};
+
+static struct i2c_board_info caspa_camera_i2c_device = {
+ I2C_BOARD_INFO("mt9v032", MT9V032_I2C_ADDR),
+ .platform_data = &caspa_mt9v032_platform_data,
+};
+
+static struct isp_subdev_i2c_board_info caspa_camera_subdevs[] = {
+ {
+ .board_info = &caspa_camera_i2c_device,
+ .i2c_adapter_id = MT9V032_I2C_BUS_NUM,
+ },
+ { NULL, 0 },
+};
+
+static struct isp_v4l2_subdevs_group caspa_camera_subdev_groups[] = {
+ {
+ .subdevs = caspa_camera_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = { .parallel = {
+ .data_lane_shift = 0,
+ .clk_pol = 0,
+ .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
+ } },
+ },
+ { NULL, 0, },
+};
+
+static struct isp_platform_data caspa_isp_platform_data = {
+ .subdevs = caspa_camera_subdev_groups,
+};
+
+static int __init caspa_camera_init(void)
+{
+ return omap3_init_camera(&caspa_isp_platform_data);
+}
+
+#else
+static inline void caspa_camera_init(void) {}
+#endif
+
#if defined(CONFIG_TOUCHSCREEN_ADS7846) || \
defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
@@ -457,6 +518,7 @@ static void __init overo_init(void)
usb_ehci_init(&ehci_pdata);
overo_ads7846_init();
overo_init_smsc911x();
+ caspa_camera_init();
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
--
1.7.3.4
You will also need to disable the pull-up resistors on the PCLK, HS and VS
signals due to a hardware bug.
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index 4443b4a..4797a80 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -497,6 +497,11 @@ static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* CAM */
+ OMAP3_MUX(CAM_PCLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_HS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_VS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif
git clone git://git.ideasonboard.org/media-ctl.git
- Open the file Install & do the operations
autoreconf --install ./configure --with-kernel-headers=/home/thomas/media/ make sudo make install
Here :
https://github.com/fastr/yavta/archives/master
- Than compile it (for ARM !)
make oldconfig make uImage make modules
- Print the topology of your interface
media-ctl -p
- Configure a datapath and the formats :
media-ctl -r -l '"mt9034 3-0048":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISPCCDC":1->"OMAP3 ISP CCDC output":0[1]' media-ctl -f '"mt9v034 3-0048":0[SGRBG10 752x480], "OMAP3 ISP CCDC":1[SGRBG10752x480]
- Take pictures :
yavta -f SGRBG8 -s 320x240 -n 4 --capture=10 -F /dev/video0
linux-omap-2.6 : 2.6.34 avec caspapx linux-omap-2.6.35+ : 2.6.35 avec caspapx + isp modifié pour images brutes linux-omap-2.6-thomas : 2.6.36 avec caspapx + KGDB overo-oe : avec openembedded et bitbake pinchart : non opérationnel, sous conseil de Laurent Pinchart pour media-ctl et yavta
/home/thomas/exo
- Placer un de ces dossiers dans :
linux.../drivers/media/video/
- Lui donner le nom :
isp
- Recompiler un noyau :
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 make uImage
- Placer le uImage dans la partition 1 ROOT de la µSD
- Les dossiers existants
isp-darkframe : bloc preview configuré pour écrire une darkframe en mémoire à la place du traitement complet isp-sauvegarde : isp original isp-rawrgb : bloc preview configuré pour annuler la débayerisation (CFA off), ne pas faire de conversion vers YUV, ...
v4l2-save : utilisé pour les données brutes issues de la caméra v4l2-brute : utilisé pour les données brutes de la caméra, autre approche, moins évoluée v4l2-new : utilisé pour les données converties de YUV vers RGB
Prebuilt 2.6.34 caspapx et rootfs