First of all, install jhbuild. And, of course, install Marmita.

In Marmita, just as in Poky, in order to get into the OE environment, the user source the script marmita-init-build-env.

Then, I setup another script, which is though to be the rcfile of a new bash session: marmita-simple-cross-compiling-env.

So, at this moment we have set all those environment variables needed to run a jhbuild session. There is also an alias for the jhbuild build, which specifies the jhbuildrc file, crafted for a cross-compiled environment: marmita.jhbuildrc.

For the moment I’ve only built GStreamer. And as a matter of fact, in the process, I came up with a simple patch for gst-plugins-bad.

By the way, the destination directory is in the /opt directory, under the stage directory; so, if you want to play with the generated output in a device, just copy that directory tree into the device’s file system.

Yes, I cannot say that I achieved a full integration between jhbuild and OE, but what I can state is that cooperation is quite possible.

It doesn’t assume anything. If the stream doesn’t have the correct headers, Firefox just will put a black box in you face without any further explanation.

In order to overcome this issue, struggling a little with the sparse information available through the Internet, I came with this .htaccess file:

AddType video/ogg          .ogv
Header set Access-Control-Allow-Origin "*"
Header unset Etag
FileETag None

First of all, my Apache server doesn’t recognize the video/ogg mime type.

Second, the header MUST NOT include the ETag key.

And finally, there’s new header, which isn’t fully implemented by the all browsers, but it will be, and will mess up all our pages with embedded videos, is the cross domain accessibility.

More information:

http://diveintohtml5.org/video.html
http://www.bluishcoder.co.nz/2008/11/video-audio-and-cross-domain-usage.html
http://en.flossmanuals.net/TheoraCookbook/MyHosting
http://www.askapache.com/htaccess/apache-speed-etags.html
http://httpd.apache.org/docs/2.0/mod/mod_headers.html

I started to generate the bindings for Vala. I never thought it could be that hard: the heavy use of atypical callbacks in Grilo made me find a bug in the code writer of Vala. And eventually I came with a small patch, which I’d just pushed.

Those problems brought into the discussion to use GAsyncResult within Grilo instead of the custom callbacks mechanism. We’ll see where we can go.

Finally I got my small test snippet. Cute, isn’t it?

Today also pushed another patches I’d in my Vala queue. The interesting part is, after talking with Zeeshan, I understood that the gstreamer vapi must be generated with the latest release of GStreamer. Something logical but I never stopped to think about it.

After attaching my first try, Arnout, the first author of the patch, came with some comments to improve the element. Several weeks after I retook the element and almost rewrote it again. So I was waiting for the OK from a GStreamer developer.

Finally, this week, Stefan review it and pushed it. Sadly for me, I didn’t notice, when I rebased my local commits, squashing my change set into one single commit, that this commit had as author Arnout, not me

Now the commit is under the Arnout’s credit.

Yeah, sometimes I’m so absentminded.

I’ve just pushed a rewrite for the ping dsp task node to my dsp-samples repository. It works with the dsp-ping program included in dps-tools.

An interesting thing is that it’s nearly 5 times smaller than the dll provided by TI:

-rw-r--r--    1 1001     1001         3920 Jan 19 15:01 pingdyn_3430.dll64P
-rw-r--r--    1 root     root        19816 Jan 19 14:44 pingdyn_3430.dll64P.bak

And too!

And maybe I’ll talk about this in the embedded devroom… maybe…

The obvious solution to rip music is SoundJuicer, and I started to compile it within my jhbuild environment, but I found a huge list of dependencies which I didn’t want to install, such as brasero. As everybody knows the next logical think then is “let’s code a simple cd ripper”.

Vala was my choosen language (and don’t ask why). What I wanted was have metadata in the files (life without metadata is not feasible anymore), also I want to encode the files in AAC/MPEG4, and finally I didn’t want any user interaction: just run the program and have my directory with my music.

The first problem I found was that Vala hasn’t bindings for libmusizbrainz, so I started to cook one for libmusicbranz v2.x, which I found terrible bad to port to Vala and also it is already deprecated. Then I cooked another for libmusicbrainz3.

After that, I also found that GstTagSetter wasn’t bind to Vala either, so I made the patches for it and another for the GstIterator.

Solved all those issues, finally I came with my mcdripper!

http://gitorious.org/vjaquez-misc/mcdripper

Ah, by the way, it uses async methods, so you’ll need a recent Vala (I use the git’s version).

And finally I’ve been ripping my new CDs and storing the files in my N900.

The OneNAND is faster than the eMMC, and it’s intended to host only the Maemo main system, moving out the third party applications to the eMMC. Though, this new layout has brought new limitations, the more visible one is the /opt problem [2].

One of the debates about what left and what not in the OneNAND is the apt’s database and metadata. Moving out the apt’s database out from the OneNAND to the eMMC, in my personal opinion, is very risky: It will slow down the database processing (which is already slow given the size of the Fremantle repositories), and if the eMMC gets corrupted, the base system wouldn’t be upgreadable either, because apt couldn’t read its database. And that’s why I’m against the proposal.

Nevertheless I’m aware that the apt’s metadata and database could be huge, consuming much of the precious OpenNAND storing space. Just to mention it,  I’ve found myself, in my development cycles, moving out those files.

That’s why I cooked this script: move-apt-dirs.sh

WARNING: this script is not official. You’re at your own if you run it: no promises, no guaranties.

There have been 178 commits since the first public release in the HAM repository, all of them affording user experience and trying to cover several corner cases on the SSU realm, specially dealing with reduced disk space in the OneNAND.

New section view in HAM

There are several new features and some eye candy:

1. The section view has been improved greatly GtkIconView instead of the old buttons grid.
2. Several user interaction (work flows and dialogs appearance) optimizations.
3. Keep the cursor position in the package lists among operations.
4. Add live search support, dropping the old search dialog.
5. Avoid the update icon blink when the screen is blank, saving power
6. maemo-confirm-text can show the package name who launched it.
7. Minor fixes in logic strings and text display.
8. Speed up the HAM launching loading the back-end using a lazy strategy.
9. Speed up the package list processing in the back-end, so the package list are shown more quickly in the UI.

For the packagers there are also some bits:

1. Adapt the .install files in order to interact with the packaged catalogs.
2. Initial support for OVI store packages.
3. Add a dbus function to search packages so other applications can interact with HAM.

And for the SSU, specially handling the reduced space disk in the root file system:

1. Use always the eMMC for downloaded packages, avoiding the rootfs even as fallback.
2. Stop as much process as possible when going into the SSU (stop prestarted apps, camera-ui, browser, rtcom-messaging-ui, alarmd, etc.) in order to reduce the double mappings of large files.
3. Go into rescue mode if the SSU fails and change its looks to a less scary one.
4. Sync the disk before fetching it status, moving the operation to the back-end.
5. Because the documentation use a lot of disk space, we hack a way to get rid of it during the SSU.
6. Use the higher disk compression during the SSU

Special thanks to Lokesh, David Kedves, Mario, Marius, Gabriel,  and all whom patient had helped us to make HAM a better piece of software to Fremantle users.

One of the bad sides of living in A Coruña is the fly connections needed to go to anywhere. This time it was A Coruña – Madrid – Lyon (St Exupéry Airport) – Grenoble. Even though I found entertained and challenging all these heterogeneous connections.

In the registration area surprisingly I came across with Rob Taylor and Mark Doffman, from Codethink. Later on I saw also David Neary and Christian Schaller around.

The opening key talk was in charge of Jon Masters, and was about “Porting Linux” to other hardware platforms, where he just highlight some hints and landmarks in the porting process, such as run the vendor tests in the board, port the u-boot, read the hardware erratas (which are more insightful than the rest of the documentation); read the linux kernel mailing lists; use the flattened device tree to specify the device’s addresses (there’s no BIOS neither ACPI in embedded system); gave some recommendations using cscope; and finally insisted in not to take the x86 architecture implementation as references, because is too dirty, he rather recommended use the score arch (“x86 wouldn’t be designed today”). At the end he strongly advised about reading the development-process under the kernel documentation.

The next talk I attended was “Use of the Fast IRQ (FIQ) in ARM-Linux” by Allesandro Rubini. The FIQ is an interrupt request with a higher priority and can be handled while another IRQ. Allesandro use them as near-real-time signal processing under a non-real-time linux kernel. In this talk he showed his project, which hasn’t been accepted in mainstream, because is too task specific.

Then I stayed in the talk “Constrained Power Management” by Patrick Bellasi where he described multiple-policy power management optimization. Patrick distinguish two PM policies: device specific and system-wide. So he propose a coordinator entity among the local policies, and this coordinator uses some kind of linear programming optimization. Cool research stuff.

My objective for the conference was twofold: to learn about embedded linux distributions build systems, and to come aware of the community opinions about Android. So I’d the intention to attend the Matt Porter’s talk, nevertheless Masters recommended the PTXdist one, and I bought it: failed! The Porter’s talk won the “best talk” conference’s award.

PTXdist is just another embeddable-linux-distribution builder, based on Kconfig to “cook” your distro and in makefiles (GAR style) to build the packages and express their dependencies. An interesting feature is the ltmain.sh fixup to avoid path hard-coding in libraries lookups.

Afterward I assisted to Nina Wilner’s talk about “Porting Android to Power Architecture”. She’s technology chief at IBM for the revamped PowerPC platform. Sadly she just make advertising for Mentor Graphics, the guys who employ Matt Porter and actually done the PowerPC port of Linux to Android. A couple interesting insights is that even though Google insist that Android is multi-platform it’s full of ARMisms, and porting its Bionic C Library to other architectures painfully. Nevertheless she stated that Android could make, in the embedded stage, what Linux made for Unix in the servers: do all over again and do it right.

Then I backed to the hardcore topics with “Analyzing Kernel Function Execution with ftrace” by Tom Bird. He’s also one the organizers of the conference. ftrace is the first generic tracing system to get mainlined. In this talk Tom explained his adventures to measure the duration of each kernel’s function at boot. With ftrace you can execute logging functions at every filtered function call. Meanwhile the community is expecting the port of dtrace to Linux.

In the afternoon Marcin Juszkiewicz talked about “Hacking with OpenEmbedded”. It was about different use cases for OpenEmbedded beside the embedded distro building.

Finally, the BoFs of the conference. I stayed at first in the Buildroot, another
embedded-distro-building which is too similar to PTXdist. At the middle of it I ran away to the Android BoF which I catch at the conclusions. Again, Android doesn’t bring nothing new, nothing breakthrough, but a lot of questions and doubts, as its ties with Google, its GPL licensing avoidance efforts, and so on.

And the Small Business BoF, organized by Michael Opdenacker, the owner of the company Free Electrons. Most of the companies there were quite small, several just one-person companies. The hottest topics there were about the lawyers need, the time tracking and billing, the hiring process and local vs abroad clients.

At the night we’d the social event: a cocktail buffet at Restaurant du Téléphérique, with a great panoramic view of the city.

At the next and last day, the opening keynote was in charge of Philippe Gerum: “State of real-time Linux: Don’t stop until history follows”. I arrive late to the talk but as far as I understood, he talked about the advances in the Linux kernel in the Real Time arena. He put special attention to the project Xenomai, which bring hard real-time support in the GNU/Linux user-space.

I flipped a coin and decided to go to “The LLVM MIPS and ARM backends” but I was gladly surprised with the talks swapping to “Coccinelle: A program matching and transformation tool” by Nicolas Palix. I came aware of the powerful concept of semantic patch. The principal use case for it, is to detect the collateral effects of an API breakage, also to fix common programming mistakes. It has been used in the kernel finding tons of potential unseen bugs. Neat!

After a short coffee break I ran into the “Survey of Linux measurement and diagnostics tools” by Frank Rowand. He shown a quick survey of several software tools for performance measurement such as smem (quite interesting); oprofile (quote: “sampling tools are not that good” also is turning obsolete); systemtap (measure the processor use in a non-intrusive way); time (the old & honest); perf (here Frank talked about the interesting problem of cache misses); bootchart; the kernel function trace; the LLTng, Timechart, an finally the famous ftrace.

Meanwhile the lunch time was getting arranged, a showcase took place in a room, where a couple projects were shown. The most impressive IMHO was the Nsec Linux system boot by Montavista. There was also Codethink with a all-microbloggers-on-one application; an LZO compression algorithm for the kernel; a demo of Android in PowerPC, etc.

In the second part of the second day, Gilad Ben-Yossef, from Codefidence, talked about “The good, the bad and ugly: on threads, processes and co-processes”, where he probed that in the Linux realm, threads and processes have no performance differences. In theory the big difference between a process and a thread is that the first owns a memory space and the second share it, so the context switching among process should be more expensive that in threads. So he decided to do some measurements with a modified version of lat_ctx, and surprise! no appreciable differences were shown. Thus, his conclusion, is that the reason why people prefer use threads instead of process is because the API. The mental model offered by the threads is more appeal to the common programmer than the process model, so Gilad decided to create a wrapper library to implement process API in terms of the threads API called coproc.

“A computer is a state machine. Threads are for people who can’t program state machines” — Alan Cox

The last talk I assisted was “Technical features and components of open source build systems” by Alex de Vries from Wind River Systems. It tried to bring a survey of all the requirements of a “perfect” embedded-distro-builder and then a pseudo BoF was raised with the question why we don’t have already one? There are tons of these system on the wild, but every has a very specific and reduced set of features. There was no conclusions but at least the seed was planted.

Finally, the closing keynote was carried on by Tom Bird and Klaas van Gend, in a mixed talk about the purpose of the CE Linux forums its goals and achievements with a contest of the butterfly effect. It was fun.

The conference closed with a round of drinks. I got a nice Chinese beer.