More muddle improvements

To wit:

• visdep (in the sandbox) now uses 'xdot' to display, not 'xdot.py'. This means that on apt-get based systems, sudo apt-get install xdot should suffice to install the dependencies needed for visdep to work.
• The output of CPIO file generation is tidied up and made easier to understand (although still terribly verbose), and the irritating (at least to me) warnings have been fixed (this was a bug in applying instructions, in fact).
• muddle status will now detect if a git checkout is behind the remote repository, without needing a git fetch, and also reports the checkouts that need attention at the end of its output. See muddle help status.
• A long-standing bug has been fixed in cleaning deployments - this makes packages depending on deployments (which Richard introduced a while ago) work that bit better.

muddle 2.4.1 - "just pulled"

Muddle 2.4.2 is now in the repository. It adds support for the _just_pulled command line argument, which allows you to do things like:

    muddle  pull  _all
    muddle  rebuild  _just_pulled

See the documentation at http://muddle.readthedocs.org/en/latest/cmdline.html#special-command-line-arguments for how it actually works.

(What, you may ask, was 2.4.1? Well, it was the version of upstream repository support which actually worked properly.)

Version 2.4 of muddle is released

The main changes are below the cut.

Kids! Want to use the ARM PMU event counters on DM3730?

There is a long-standing bug that prevents DM3730 users from using the ARM performance monitor counters on OMAP3 (my machine is a Beagle xM with a DM3730 on it).

The PMU counters are described in ARM DDI0344K, s. 3.2.42-3.2.51 and allow one to count interesting events such as data fetches, TLB and cache misses, and so on. There are four PMU counters and one cycle counter.

In order to access these from userspace, one must persuade a kernel module (or the kernel itself) to perform:

 {
     int fred = 1;
     asm("MCR p15,0,%[r], c9, c14, 0" : : [r] "r" (fred));
 }

However, if one does this in a 'stock' 3.2.0 kernel (or before, I guess), one will find that only the cycle counter works - the others are all stuck at whatever value you last wrote into them (not necessarily zero, oddly enough).

This is because the four performance unit counters are clocked from the EMU clock domain, which is in turn in the EMU power domain, which is turned off by the kernel shortly after boot, since nothing is currently using it.

The "right way" to turn it on again would be by calling clk_enable() on emu_src_clk. However, a bug in the power management subsystem means that whilst this will attempt to turn on the EMU domain clocks, it will fail to turn on the EMU power domain and the counters will remain stuck.

Since that bit of the kernel is in flux right now, a quick hack to get you going is to find arch/arm/mach-omap2/clockdomains3xxx_data.c and change:

static struct clockdomain emu_clkdm = {
.name  = "emu_clkdm",
.pwrdm  = { .name = "emu_pwrdm" },
.flags  = /* CLKDM_CAN_ENABLE_AUTO |  */ CLKDM_CAN_SWSUP,
.clktrctrl_mask = OMAP3430_CLKTRCTRL_EMU_MASK,
};

to

static struct clockdomain emu_clkdm = {
.name  = "emu_clkdm",
.pwrdm  = { .name = "emu_pwrdm" },
.flags  = /* CLKDM_CAN_ENABLE_AUTO |  *//*CLKDM_CAN_SWSUP*/ 0,
.clktrctrl_mask = OMAP3430_CLKTRCTRL_EMU_MASK,
};

Thus stopping the kernel from ever suspending that domain. No guarantees that this works over suspend/resume, but it at least allows you to clock the counters.

muddle version 2 stamp file support

The latest version of muddle now supports version 2 stamp files. See "muddle help stamp" (and the associated subcommands). There's a tag "stamp-v2-support" if you like that sort of thing.

...and muddle continues to evolve

muddle v2.3.1 fixes a couple of bugs, and beyond that, head-of-tree adds "muddle --version", which uses git to report a sensible version string, and also the directory that muddle is being run from. For instance:

$ muddle --version
muddle v2.3.1-3-g34519ca in /home/tibs/sw/muddle


(That's the last tag (v2.3.1), the number of commits since then (3) and the start of the SHA1 string for this commit (34519ca))

KBUS on Google Code now using Git

The KBUS repositories on http://code.google.com/p/kbus/ have now been moved from Mercurial to Git.

The "default" (userspace) and kernel repositories are now recombined. The changes from the kernel submission work on github have also been folded in.

See http://code.google.com/p/kbus/wiki/DevelopmentHistory for more information.