Yocto BSP in an hour

Posted on by
Reply

I am an experience OpenEmbedded hacker. But I was pleased  yesterday when I decided OK let me add a new machine (namely qemumips64 ) to Yocto kernel.

How hard could it be after all. Well it turns out to be not that much. I started of with

https://wiki.yoctoproject.org/wiki/BKM:_starting_a_new_BSP#Adding_new_options_and.2For_changing_kernel_code

Pretty good reference. I was working on yocto kernel 3.2 so adjust the versions accordingly. Copied the mti-malta32 to mti-malta64. Renamed the files underneath to reflect mti-malta64

Changed

meta/cfg/kernel-cache/bsp/mti-malta64/mti-malta64-common.cfg

 CONFIG_CPU_MIPS32_R1=y

to

CONFIG_CPU_MIPS64_R1=y

and committed the metadata

added a linux-yocto_3.2.bbappend file in my own layer to have something like

 KMACHINE_qemumips64  = “mti-malta64-be”
KBRANCH_qemumips64 = “standard/mti-malta32″
COMPATIBLE_MACHINE_qemumips64 = “qemumips64″
SRCREV_meta_pn-linux-yocto_qemumips64 ?= “f5892b6b3a1fef34cf948c3075d91bec6249e7c8″

FILESEXTRAPATHS := “${THISDIR}/${PN}/${MACHINE}:”

KSRC_linux_yocto ?= “/home/kraj/linux-yocto-3.2.git”
SRC_URI = “git://${KSRC_linux_yocto_dev};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta”

and thats it !!!

I had linux-kernel building for mips64

Well later Bruce ‘zeddii’ Ashfield mentioned that he already has done mips64 support in upcoming linux-yocto-3.4 but nevertheless I learnt something new

 

Using OpenEmbedded-core to build Angstrom for QEMU

Posted on by
Reply

I was working on getting oe-core to build something. It is pretty easy though

Clone the angstrom setup scripts

git clone git://git.angstrom-distribution.org/setup-scripts

cd setup-scripts

(PLEASE MAKE SURE THAT ALL BITBAKE OPERATIONS ARE PERFORMED INSIDE setup-scripts DIR)

$ ./oebb.sh config qemuarm

This will clone openembedded-core meta-openembedded meta-angstrom bitbake and angstrom-layers into sources/, generate an environment setup script in ~/.oe and create build directory and local configuration in the build directory. The default local.conf is in build/conf which can be manually edited after creation for customization.

$  . ~/.oe/environment-oecore

This will complete the setup now. You are ready for building

$ bitbake systemd-image

After few hours the build completes and the images are available in

build/tmp-angstrom_2010_x/deploy/eglibc/images/qemuarm/

Now we can use the oe-core’s scripts for launching the qemu and boot this image into it.

First lets create the nfs root

$ runqemu-extract-sdk ./tmp-angstrom_2010_x/deploy/eglibc/images/qemuarm/systemd-image-qemuarm.tar.bz2 /tmp/qemuarm

It will extract the image into /tmp/qemuarm that can be used to boot qemu from nfs

Now boot, you should be inside the build directory (e.g. setup-scripts/build ) to launch following

$ runqemu /home/kraj/work/setup-scripts/build/tmp-angstrom_2010_x/deploy/eglibc/images/qemuarm/zImage-qemuarm.bin /tmp/qemuarm/

Voila !!

Downgrading package versions in OpenEmbedded

Posted on by
Reply

Sometimes its required to downgrade a package version e.g. you are suspecting that the problem is caused by udev version 171 so you would like to build a root file system incrementally using udev 164

So you do required rituals of selecting 164 version of udev using PREFERRED_VERSION_udev = “164″

and then bitbake <your image>

and expectedly it should build your image again with udev 164 in it but it may not happen and you might end up with errors like

| Configuring udev.
| Configuring task-base-extended.
| Configuring sysvinit-pidof.
| Configuring tinylogin.
| Configuring sysvinit.
| Collected errors:
|  * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-base:
|  *    libudev0 (>= 171) *
|  * opkg_install_cmd: Cannot install package task-base.
| ERROR: Function ‘do_rootfs’ failed (see /home/kraj/work/angstrom/build/tmp-angstrom_2010_x-uclibc/work/qemumips-angstrom-linux-uclibc/console-image-1.0-r0/temp/log.do_rootfs.15163 for further information)
NOTE: package console-image-1.0-r0: task do_rootfs: Failed
ERROR: Task 8 (/home/kraj/work/angstrom/sources/meta-angstrom/recipes-angstrom/images/console-image.bb, do_rootfs) failed with exit code ’1′
ERROR: ‘/home/kraj/work/angstrom/sources/meta-angstrom/recipes-angstrom/images/console-image.bb’ failed

You could try to clean task-base or console-image but it wont help. The problem here is that there is a package which has created a dependency on libudev0 >= 171 but now we are sysrooting with 164. Ideally bitbake should have noticed it and rebuilt the concerned recipe but it does not happen.

Time for some sleuthing. You need to figure out with package is wanting libudev0 171+

$ cd build/tmp-angstrom_2010_x-uclibc/deploy/ipk/mips

$ for f in *.ipk; do ar p $f control.tar.gz | tar -zxO ./control|grep “libudev0 (>= 171)” && ls $f; done
Depends: libgcc1 (>= 4.6.0+svnr175150), libx11-6 (>= 1.4.3), libz1 (>= 1.2.5), libxcb1 (>= 1.7), uclibc (>= 0.9.31+0.9.32rc3), libxml2 (>= 2.7.8), libxext6 (>= 1.3.0), gstreamer (>= 0.10.32), libudev0 (>= 171), libxv1 (>= 1.0.6), gst-plugins-base, libiconv (>= 1.13.1), libice6 (>= 1.0.7), libgudev-1.0-0 (>= 171), libglib-2.0-0 (>= 2.28.8), libxau6 (>= 1.0.6), libsm6 (>= 1.2.0), libuuid1 (>= 2.19.1), libxdmcp6 (>= 1.1.0)
gst-plugins-base-video4linux_0.10.32-r0_mips.ipk

So you know now the ipk which is depending on udev 171 and is being pulled into the image

so now you can go and manually clean the recipe which is providing gst-plugins-base-video4linux_0.10.32-r0_mips.ipk and bitbake <your image> again

Now it should it get it right :)

Cross testing eglibc regression testsuite using OpenEmbedded-core/QEMU

Posted on by
Reply

OpenEmbedded builds systems using eglibc or uclibc for a C standard library.  Both the libraries come with there own regression testsuites which have there own requirements to create the right environment to execute the tests. Glibc testsuites are written to execute for native builds more than a cross build therefore eglibc has put efforts to make it possible to test it in a cross environment. Here I discuss how to run eglibc testsuites in cross envronment in OE-core

Make sure that you dont have “rm_work” turned on since you will need access to build tree of eglibc.

Export the build directory over nfs on the build machine which could be mounted at exact same location on the target when e.g

if build tree is /home/kraj/openemebdded-core/build then it should appear exactly same on the target when mounted.

on build system edit /etc/exports to add

/home/kraj *(rw,sync,no_subtree_check,no_root_squash)

restart the nfs server

sudo service nfs-kernel-server restart

Check with exportfs if the directory is now exported

sudo exportfs

Now Add following to local.conf

EXTRA_IMAGE_FEATURES += "tools-sdk nfs-server ssh-server-openssh tools-debug"
MACHINE=qemuarm bitbake core-image-minimal
runqemu qemuarm nographic

Now this should bring up the qemu with the minimal image. login into console and change the default password to something else since the initial password is empty and it does not allow you to copy anything into this machine

Now from your host you can copy the public key to the qemu machine

$ ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.7.2

This should have now setup passwordless login to the target system.

On target mount the eglibc build directory something like

mkdir -p /home/kraj
mount -t nfs 192.168.x.x:/home/kraj /home/kraj

During the build OE would have generated a testing driver for eglibc in the eglibc build tree. It should be named something like powerpc-oe-linux-testeglibc for ppc32 e.g. You would run the script something like

$ ./powerpc-oe-linux-testeglibc root@192.168.7.2 >& test.log

Now you can get failures from the results

grep "Error 1" test.log

Openembedded bblayers and bbappend

Posted on by
Reply

OpenEmbedded has implemented bblayers and bbappend features recently (Thanks to Richard Purdie).
These features are very useful when one wants to tweak the OE recipes but not necessarily override
it completely.

BBLAYERS

bblayers lets you create a layer of your own recipes.

to enable bblayers one needs to create a file called bblayers.conf in toplevel conf directory along with
local.conf

The content of bblayers is typically

TOPDIR := “${@os.path.dirname(os.path.dirname(d.getVar(‘FILE’, True)))}”
BBPATH = “${TOPDIR}”
BBLAYERS = “${TOPDIR}/openembedded ${TOPDIR}/mylayer”

Here it defines two layers one being the standard OE metadata and second mylayer being own layer
both the layers exist at same level in directory structure

# ls oe/

conf mylayer bitbake downloads openembedded

I need to have a file called layer.conf in mylayer/conf/
The contents look like below

BBFILES += “${LAYERDIR}/recipes/*/*.bb”
BBPATH .= “:${LAYERDIR}”
BBFILE_COLLECTIONS += “pvt”
BBFILE_PRIORITY_pvt = “1″
BBFILE_PATTERN_pvt = “${LAYERDIR}”

This enables the bblayers feature and now I can put bitbake in my path and call bitbake
wherever I am under oe/ directory structure.

BBAPPEND

bbappend is a novel feature where one wants to override few files that a given
recipe uses but not everything or even everything. So far overlays let one
hijack the complete recipe dir. bbappend is very useful in lot of usecases.
I will discuss one of such here.

Suppose one wants to have his own etc/network/interfaces file on the target
root file system but still would like to use the netbase recipe from OE metadata
advantage being that it does not have to sync changes made upstream into
local overlay everytime but instead use the upstream recipes and make little
tweaks that are needed to customize it for one’s use.

bitbake recognises .bbappend extension so we could do these customizations in
.bbappend file. This file is per recipe and usually named _.bbappend

Firstly we need to let BBFILES recognize the new extension to do so one will
modify the mylayer/conf/layers.conf file

BBFILES += “${LAYERDIR}/recipes/*/*.bb ${LAYERDIR}/recipes/*/*.bbappend”

Now bitbake will parse the *.bbappend files.

continuing netbase example we will define

recipes/netbase/netbase_4.21.bbappend

FILESEXTRAPATHS := “${THISDIR}/${PN}-${PV}”

PRINC = “1″

PRINC will increment the base PR by 1. So lets say base PR of netbase_4.21.bb is r125 then for your layer it will use r126 and if you have PRINC set to 2 then it will be set to r127

This file prepends mylayer to FILESPATHBASE which will make bitbake to search
for files in mylayers ahead of stock openembedded metadata.

this will enable me to have my own etc/network/interfaces file which I will
place in mylayer/recipes/netbase/netbase/qemumips in the final package.

Voila!!