SlimLogic Ltd

OpenEmbedded/Ångström Kernel Workflow

xora — Wed, 25 May 2011 10:23:12 +0000

2013-01-21: This guide was based on OE classic and some of the commands seem to have changed for oe-core, specifically the -c deploy for the kernel. I have not yet discovered the replacement command.

This article is to detail the workflow I personally use when I am doing kernel development for devices supported by OE. I find OE very useful for this as I can use it to build the toolchain and ultimately to control my patch tree until I am ready to send the patches upstream.

If you have a correctly configured machine then virtual/kernel should point to the correct kernel for your device. So in this article I use virtual/kernel to represent the present kernel. Paths will of course vary with kernel versions.

So I first make sure I am starting from clean

bitbake virtual/kernel -c clean

Then take the kernel as far as the configuration stage, this makes sure all patches in the metadata are applied and that the defconfig has been copied to .config and make oldconfig has been run.

bitbake virtual/kernel -c configure

Now I switch to another window where I shall be actually editing the code. I change to the temporary working directory of the kernel I am working with. This path below will change depending on kernel version or name. Kernels are always found in the machine workdir so tmp/work/$MACHINE-angstrom-linux-gnueabi/

cd tmp/work/elphel-10373-angstrom-linux-gnueabi/linux-elphel-2.6.31+2.6.32-rc8+r4+gitr2a97b06f43c616abb203f4c0eb40518c44c8d7fe-r28/

At this point I normally elect to use quilt to temporarily manage my patches so.

quilt new new-feature.patch

And to add files to this patch, I make sure to do this before I make any edits as the diff ends up being the diff from when this is first called to the current state.

quilt add driver/camera/random.c

Then load the file into my favourite editor.

vi driver/camera/random.c

I make the changes I require then it is time to create a patch from these changes so I then do.

quilt refresh

The above steps created a patches/ directory inside this is one or more patches and a file called series. series is a list of all the patches in the order they should be applied (quilt takes care of this).

So now I want to actually build this code to make sure it compiles so I switch back to my original terminal and issue.

bitbake virtual/kernel -c compile

If this stage fails I continue editing the files to correct the errors remebering to refresh the patches as I go. The above command can be issued repeatedly until is succeeds. When it does I then wish to make the kernel image used on the the board I am playing with so.

bitbake virtual/kernel -c deploy

I take the uImage file from tmp/deploy/images/ and send it to the board for booting however it is done in my setup. For this kernel I will write it into flash on the Elphel camera.

It is almost certain that this first attempt as create the new feature will have some problems. In this case I return to the terminal where I was editing the code and fix it (still not forgetting to refresh the patches). To force the compile stage to happen again I issue the command.

bitbake virtual/kernel -c compile -f

The -f means force and forces bitbake to return to that stage. When the compile is successful I can again issue the following command to deploy the image again.

bitbake virtual/kernel -c deploy

I repeat this cycle as needed until I have my new feature working as I wish.

When I am happy with the changes that have been made to the kernel I will have a patch file in patches/new-feature.patch that is suitable for adding directly to the OpenEmbedded meta data or which can be applied to a git tree ready for sending upstream.

I shall leave the git instructions to the git manual. For the case where I want to apply it to the OE meta data then I edit the original bitbake recipe, adding the patch to the SRC_URI in the form

file://new-feature.patch;patch=1

For example a finished line.

SRC_URI = "git://elphel.git.sourceforge.net/gitroot/elphel/linuxdavinci;branch=elphel-10373;protocol=git \ file://new-feature.patch;patch=1 \ file://defconfig"

I copy the patch into a suitable directory in the metadata. More information on how the build system searches directories for patches can be found on the OE wiki and the bitbake manual. In this case.

recipes/linux-elphel/new-feature.patch

Now I test everything is ok with a clean rebuild so.

bitbake virtual/kernel -c clean bitbake virtual/kernel

This should successfully complete the build and I should have a kernel with my new feature. If at a later date I find my new feature does not quite work as expected I can use a variation of the same process to update it. Instead of issuing the quilt new/add commands I just start editing the files in the patch again and a quilt refresh will refresh the last patch applied to the source which is most likely my new feature. If it is not or I have done this process multiple times I can use quilt pop and push to move between patches.

OMAP3 SD Booting

xora — Wed, 25 May 2011 10:16:40 +0000

Since the instructions to format an SD card for booting with beagle/zoom2/other omap boards seems to be so complex I decided to write a script that was nice and simple to accomplish the same task.

Here is my tested and working script.

omap3-mkcard.sh

To run this script you will require to run it as root. On Ubuntu or other linux with sudo setup run the script as

sudo sh omap3-mkcard.sh /dev/sdX

replacing sdX with the base device name of your SD card device.

If your running a distribution without sudo setup then become root then run the script as

su -
sh omap3-mkcard.sh /dev/sdX

2011 ASoC and Embedded ALSA Conference – 4th & 5th May, Edinburgh

lrg — Thu, 24 Mar 2011 16:45:26 +0000

We are pleased to announce that there will be an ASoC (and embedded ALSA) conference/workshop in Edinburgh this year on the 4th and 5th of May at the Scotch Malt Whisky Society on Queen Street, in the centre of Edinburgh.

Agenda - (still open to new items)

1) Audio DSP support. A look at the new ASoC DSP core architecture with Q & A. How can we integrate and easily exploit the features of PCM and Media DSPs. What else do we need. What are the problem areas (these may be different for each vendor). How do we solve these problems. Case study with the ASoC DSP core and the OMAP4 ABE and a case study with considerations for offboard DSPs.

2) UCM (Use Case Manager). Intro + Q & A on UCM alsa-lib and Pulseaudio. Anything missing or cumbersome to use with current code base. How are vendors doing this at the moment. How can we share the UCM configuration DB with Android audio HAL. How do we best integrate UCM support in Pulseaudio.

3) Android ALSA Integration. libaudio, HAL, Audio Flinger. What needs to be done here to allow Android to fully exploit features in the audio hardware. How can ALSA/ASoC provide this in a generic manner.

4) Runtime coefficients and algorithms. Suggest a common framework, gather requirements from vendors and design a common API to solve. Any problem areas. We may need to re-generate and tune coefficients during runtime depending on external factors and re-load.

5) Runtime firmware. Can this be helped with common code and how different is this for each vendor? What about latency, selection algorithms, memory footprint.

6) DAPM graphs. How can we get the most out of the graphs we have for DAPM. What tools are needed to exploit this. How can this be used to simplify code development and debug. What about runtime update of DAPM graph depending on firmware changes.

7) Power Management and QoS – ASoC and ALSA already have good PM features, but what are we missing to fully exploit the audio hardware. e.g. DAPM is used in the OMAP4 ABE to calculate lowest clocking frequency (OPP level) for ABE depending on use case. Do other vendors need similar features that are dependent on use case.

How can we better support QoS to audio. Most audio hardware has low power modes sacrificing quality. An extra alsa-lib API call would allow simple configuration per PCM stream but what about devices that offer more tuning. Is a simple IOCTL all that is required here?

8 ) SLIMBUS – Common architecture.

9) Future Roadmap – what do we need for next year etc. How should this be prioritized. Who will do the work.

10) Group Picture before the Whisky tasting

11) Next Years Conference

Local Accommodation –

There is a variety of accommodation near the venue including, but not limited to,
The MacDonald Roxburghe Hotel, at only five minutes walk from the venue this is a very good choice. The hotel is situated in the heart of the city, on Charlotte Square.

The Apex Waterloo Place Hotel, at the east end of Princes Street, this modern hotel is perfectly placed for easy access to the conference venue as well as all the sights and tourist attractions Edinburgh has to offer.

And The Caledionian Hilton, sits at the west end of Princes Street, still close to the conference venue, with wonderful views of the castle.

We have created a map with the location of the venue and a handful of local hotels, hopefully it will help in finding your way around.

Travel –

Taxis in Edinburgh are plentiful and easy to get hold of, but we also have a very good public transport network.
From arriving at the airport the easiest and fastest way to get into the city centre is the Airlink Bus, which departs from outside the domestic terminal every ten minutes during the day (from 0430 to 0022), and you can even buy your ticket online in advance.

Booking –

Places are limited so unfortunately this conference is by invitation only. If you have received an invitation and wish to book please email Jen Knowles to confirm your place.
If you have not received an invitation, but think you should have please also let us know and we will try and accommodate.

We already have delegates attending from companies that produce handsets, operating systems and ICs and places are now filling up fast. There is an early booking discount and bookings received before Friday 15th of April will receive the discounted rate of £240 inc. VAT otherwise the normal rate is £280 inc VAT.

Schedule-

Time	Wednesday
9.00-9.30	Registration
9.30-10.00	Welcome and introductions
10.00-11.00	Audio DSP support part 1. A look at the new ASoC DSP core architecture with Q & A. How can we integrate and easily exploit the features of PCM and Media DSPs. What else do we need. What are the problem areas (these may be different for each vendor). How do we solve these problems. Case study with the ASoC DSP core and the OMAP4 ABE and a case study with considerations for offboard DSPs.
11.00-11.15	Break
11.15-12.15	Audio DSP part 2.
12.15-13.15	Lunch
13.15-14.15	Integration part 1 – UCM (Use Case Manager) Intro + Q & A on UCM alsa-lib and Pulseaudio. Anything missing or cumbersome to use with current code base. How are vendors doing this at the moment. How can we share the UCM configuration DB with Android audio HAL. How do we best integrate UCM support in Pulseaudio.
14.15-14.30	Break
14.30-15.30	Integration part2 – OS ALSA Integration. Android – libaudio, HAL, Audio Flinger. ChromeOS audio stack — likewise. What needs to be done here to allow Android to fully exploit features in the audio hardware. How can ALSA/ASoC provide this in a generic manner and backporting.
15.30-15.45	Break
15.45-16.45	DAPM graphs / Media controller. How can we get the most out of the graphs we have for DAPM. What tools are needed to exploit this. How can this be used to simplify code development and debug. What about runtime update of DAPM graph depending on firmware changes.
17.00-17.30	Group picture before Whisky Tasting
18.00-?	Dinner and Drinks

Time	Thursday
09.00-09.30	Coffee and Refresher, any questions from yesterday?
09.30-10.30	Power Management and QoS ASoC and ALSA already have good PM features, but what are we missing to fully exploit the audio hardware. e.g. DAPM is used in the OMAP4 ABE to calculate lowest clocking frequency (OPP level) for ABE depending on use case. Do other vendors need similar features that are dependent on use case. How can we better support QoS to audio. Most audio hardware has low power modes sacrificing quality. An extra alsa-lib API call would allow simple configuration per PCM stream but what about devices that offer more tuning. Is a simple IOCTL all that is required here?
10.30-10.45	Break
10.45-11.45	Runtime coefficients and algorithms. Suggest a common framework, gather requirements from vendors and design a common API to solve. Any problem areas. We may need to re-generate and tune coefficients during runtime depending on external factors and re-load.
12.00-13.00	Lunch
13.00-14.00	Runtime firmware. Can this be helped with common code and how different is this for each vendor? What about latency, selection algorithms, memory footprint.
14.00-14.15	Break
14.30-15.30	SLIMBUS Common architecture.
15.30-15.45	Break
15.45-16.45	Review of Conference and Future Roadmap What do we need for next year, etc. How should this be prioritized. Who will do the work.
16.45-17.00	Next years conference and conference closure.

Multithreaded ALSA capture code with overrun debug

lrg — Wed, 03 Feb 2010 14:09:47 +0000

I’ve been working on some ASoC multi channel capture drivers lately and was in need of a nice analysis tool to show PCM data throughput and PCM buffering information when writing to slow-ish asynchronous memory cards.

SoC memory card controllers tend to write data in asynchronous bursts and usually compete for SoC CPU IO resources with the audio subsystem. This competition for SoC IO resources between the audio and memory card subsystems can often lead to problems for audio. The two most common audio problems are :-

Audio Controller FIFO overruns.
Audio DMA buffer overruns.

Audio FIFO overruns are caused when the DMA controller cannot empty the audio FIFO before the next incoming audio PCM sample is shifted into the already full FIFO. This ultimately causes the FIFO to lose some audio PCM data and potentially also lose left+right channel alignment. FIFO overruns can be minimised by using the largest FIFO possible and by setting the FIFO DMA IRQ watermark to a value that can tolerate high latency. This should be done by the driver and may depend on number of channels capture and rate.

Audio DMA buffer overruns can be caused when any userspace process reading (capturing) the PCM audio data from the ALSA driver does not manage to completely read the data (from the DMA circular buffer) before it is overwritten by new new data (by the DMA). DMA buffer overruns can be mostly eliminated by making sure our capture program can read from the ALSA driver without any hinderance. This can be achieved by having separate reader and writer threads.

I’ve posted some example ALSA multi threaded capture code here. It’s by no means complete and is a little rough around the edges but should be helpful to anyone debuging overrun or buffering issues. It can be built as follows:-

gcc capture.c -lasound -o capture

The program will capture audio data from the default ALSA device until it receives a CTRL-C signal where it dumps the buffering usage data.

Website Updates

lrg — Fri, 22 Jan 2010 18:41:02 +0000

We have now updated our git web interface to use the faster cgit front end. This should hopefully improve access times as cgit offers better page caching than gitweb.

Additionally, we have also added a planet aggregator for our blog posts here.

ARM Cortex A9 Angstrom Console Image and Tool Chain

lrg — Fri, 22 Jan 2010 18:13:17 +0000

I’ve now managed to successfully build an Angstrom Linux console image and cross gcc tool chain for the ARM Cortex-A9 CPU found on some newer SoC boards. Although unfortunately I’ve not yet had a chance to test this image yet as I’m waiting on the delivery of my new Cortex A9 hardware.

The angstrom-2008.1.conf binutils, gcc and glibc versions used are
PREFERRED_VERSION_glibc ?= "2.10.1" PREFERRED_VERSION_glibc-initial ?= "2.10.1" ANGSTROM_GCC_VERSION_armv7a ?= "4.4.2" ANGSTROM_BINUTILS_VERSION_armv7a ?= "2.20"

Whilst the CPU tuning for Cortex A9 is
# Instead of using -mfpu=vfp[2] we can use -mfpu=neon to make use of gcc intrinsics[1] and vectorize loops with -ftree-vectorize[3] # [1] http://gcc.gnu.org/onlinedocs/gcc/ARM-NEON-Intrinsics.html # [2] http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html # [3] https://support.codesourcery.com/GNUToolchain/kbentry29

TARGET_CC_ARCH = "-march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp" FEED_ARCH = "armv7a" PACKAGE_EXTRA_ARCHS += "armv4 armv4t armv5te armv6 armv7 armv7a" BASE_PACKAGE_ARCH = "armv7a"

All the Openembedded files required to build this too chain and image are available via git in the SlimLogic OE omap4 branch.

The repository URL is git://git.slimlogic.co.uk/oe.git for anyone interested in adding it as a remote.

Kernel Plumbers Conference 2009

lrg — Thu, 27 Aug 2009 19:00:50 +0000

SlimLogic will be in attendance at this years Linux kernel plumbers conference in Portland, Oregon, September 23rd – 25th, 2009. See you there at the embedded and audio tracks.

Updated: Seven new Voltage regulator drivers for Linux

lrg — Thu, 27 Aug 2009 18:23:29 +0000

Updated: New regulator drivers for the Freescale MC13783, Motorola PCAP2, Wolfson WM831x, Texas Instruments TPS65023 and TPS6507x, Marvell 88PM8607 and ST-Ericsson AB3100 have been accepted into the Linux voltage regulator development tree and will be heading for the mainline kernel in the next merge window. This should approximately take place in the next month and mean the drivers will be included in Linux 2.6.32.

Linux Kernel Development

lrg — Thu, 16 Apr 2009 12:42:17 +0000

SlimLogic are active embedded Linux kernel developers and work within the open source community to provide solutions for our commercial partners. We specialize in bringing key embedded technologies to both Linux users and developers on time and on budget.

SlimLogic have a proven Linux track record and currently actively maintain the Linux kernel Voltage Regulator Subsystem and the ALSA System on Chip (ASoC) Audio Subsytem.

SlimLogic can provide 1st class embedded Linux kernel and driver development services.

Linux Voltage Regulator for 2.6.30

lrg — Thu, 16 Apr 2009 11:37:55 +0000

The changes for 2.6.30 include a new twl4030 regulator driver, improved regulator init_data
handling, refcount fixes, some new voltage API functions and numerous minor fixes. Full change log:-

Adrian Hunter (1):
regulator: twl4030 VAUX3 supports 3.0V

Andrew Morton (1):
regulator: minor cleanup of virtual consumer

David Brownell (10):
regulator: minor cleanup of virtual consumer
regulator: add get_status()
regulator: enumerate voltages (v2)
regulator: get_status() grows kerneldoc
regulator: twl4030 regulators
regulator: twl4030 voltage enumeration (v2)
MMC: regulator utilities
twl4030-regulator: list more VAUX4 voltages
regulator: refcount fixes
twl4030-regulator: expose VPLL2

Jonathan Cameron (1):
Regulator: Push lock out of _notifier_call_chain + add voltage change event.

Liam Girdwood (1):
regulator: email – update email address and regulator webpage.

Mark Brown (16):
regulator: Pass regulator init data as explict argument when registering
regulator: Allow init data to be supplied for bq24022
regulator: Allow init_data to be passed to fixed voltage regulators
regulator: Make fixed voltage regulators visible in Kconfig
regulator: Mark attributes table for virtual regulator static
regulator: Hoist struct regulator_dev out of core to fix notifiers
regulator: Suggest use of datasheet supply or pin names for consumers
regulator: Allow regulators to set the initial operating mode
regulator: Fix get_mode() for WM835x DCDCs
regulator: Implement list_voltage() for WM8400 DCDCs and LDOs
regulator: Don’t warn on omitted voltage constraints
regulator: Implement list_voltage for WM835x LDOs and DCDCs
regulator: Allow boot_on regulators to be disabled by clients
regulator: Don’t warn if we failed to get a regulator
regulator: Don’t increment use_count for boot_on regulators
regulator: Support disabling of unused regulators by machines

Mike Rapoport (1):
regulator: add unset_regulator_supplies to fix regulator_unregister

Randy Dunlap (1):
regulator: fix header file missing kernel-doc