The Perpetual Notion

Yum ;-)

2011-12-16T20:20:00.001-05:00

A nearly-vegan pad thai (no eggs, but crab & otherwise some fish sauce).

Two Thumbs Up to Koush

2011-11-29T11:46:00.001-05:00

I just installed & tweeked Koush's Cyanogen Mod 9 alpha 11 for my Nexus S running Ice Cream Sandwich from AOSP. You can read his original message on the XDA forums.

For an engineering build it's running quite smoothly. I'm certainly looking forward to mirroring his git and building a userdebug variant. Typically this speeds up most aspects of the UI and other software since debug messages are less frequent.

A few pointers:

If you feel that the boot animation is continuing infinitely, you probably forgot to erase the data partition (I did, originally)
If you like Google Car Home, which is a great home-replacement while driving, then install it manually from a backed-up apk and install the 3rd party Car Mode Control app. The original google car home will install, but it is claimed not to work with ICS and does not show up in the launcher so there is no way to use it unless Car Mode Control is installed.
If you encounter "Unfortunately, Google TTS Engine has stopped" Select PicoTTS to get Navigation and My Tracks to work.

An Update

2011-11-11T21:59:00.001-05:00

Just to dispel any confusion that might arise if people google me to dig up 'dirt'.

Yes, I am in fact single again. Yes, there may be photos of me & my ex floating around on the interwebs that seem to be very recent - and they are! I only did become single again recently, and it was a bit sudden for me too!

So is life, however, and it does go on, as they say.

It's actually really surprising how little I'm blogging these days, with the major shift changing from blogging to micro-blogging via Twitter, FaceBook, and Google+ . Sorry if I haven't been terribly vocal.

Just thought I would post an update.

Ciao!

C

Google Nexus S Android Phone Suffers USB Death

2011-08-31T16:11:00.000-04:00

Today I am a very lucky guy, in spite of the fact that the USB OTG functionality on my Google Nexus S has just vanished. Why does that make me lucky? Well, it doesn't, but luckily I had ordered a second Nexus S that works properly with Canadian HSDPA frequencies on the Rogers network, and it arrived literally the same second that my old Nexus S stopped working. Total coincidence... I think.

Actually, I should be more specific - nothing on the old phone has stopped working except for the USB OTG controller. So when I plug my in my phone to my workstation, I receive "unable to enumerate device on port... " under Linux and "USB Device Not Recognized" under Windows 7. In layman's terms, my phone no longer works as a USB disk.

Being a clever hacker, I managed to get the dmesg output on my Nexus S, which I hope will be of some use for people at either Google or Samsung. The source code for the Nexus S (codenamed crespo) is available, so I might look into it further some time later.

In reference to the dmesg output below,

"The FSA9480 chip is used on some Samsung phones to detect various accessories using sensing resistors on the ID pin of the USB port." [1]

It's likely an authentication chip - there are several vendors that provide something similar. The datasheet is only available under NDA of course. Naturally, I've tried several cables, and several different workstations, to no avail. There are many layers of software and electronics at work (or rather not at work) here, so without some chip documentation / resources, there's not really a way that I can debug this just using the source code of the Linux driver.

But just to clarify - anytime an 'err -6' appears, that corresponds to with -ENXIO "No such device or address", and anytime 'err -5' appears, it corresponds to -EIO "I/O error", so the outlook is not good. It's likely that the chip in question had a bad solder joint and is not powering up with the rest of the phone, or it experienced a "massive" current spike from my laptop that it couldn't handle.

I believe my device is still under warranty though, so I'll certainly be shipping it back for repair soon.

The strangest part of this whole thing is that I've kept my phone in pristine condition, which (sadly) suggests that the design quality of this Nexus S was lacking, in spite of what Google has said in various marketing videos. It could also be Fairchild's fault, if in fact it turned out to be an ESD issue. Anything that's connected on the USB should be able to handle 'typical' levels of ESD from a PC's USB pins.

[ 2066.560942] fsa9480 7-0025: dev1: 0x0, dev2: 0x0

[ 2068.234132] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2068.362855] fsa9480 7-0025: fsa9480_irq_thread: err -6

[ 2068.363813] fsa9480 7-0025: fsa9480_detect_dev: err -6

[ 2068.363919] fsa9480 7-0025: dev1: 0xfa, dev2: 0xff

[ 2068.374642] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2068.377227] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2068.377957] i2c i2c-7: sendbytes: NAK bailout.

[ 2068.378051] fsa9480 7-0025: fsa9480_reg_init: err -5

[ 2068.379090] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2068.975317] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2068.977052] fsa9480 7-0025: dev1: 0x1f, dev2: 0xff

[ 2068.978903] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2068.991221] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2068.992016] i2c i2c-7: sendbytes: NAK bailout.

[ 2068.992109] fsa9480 7-0025: fsa9480_reg_init: err -5

[ 2068.993178] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2068.994968] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2069.003127] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.004982] fsa9480 7-0025: dev1: 0x10, dev2: 0x3

[ 2069.006708] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.008463] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.009962] i2c i2c-7: sendbytes: NAK bailout.

[ 2069.010054] fsa9480 7-0025: fsa9480_reg_init: err -5

[ 2069.010498] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2069.012253] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.014000] fsa9480 7-0025: dev1: 0x10, dev2: 0x1f

[ 2069.015793] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2069.035247] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.037069] fsa9480 7-0025: dev1: 0xff, dev2: 0xff

[ 2069.038796] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2069.041289] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.043017] fsa9480 7-0025: dev1: 0x10, dev2: 0xff

[ 2069.044765] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2069.048313] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.050040] fsa9480 7-0025: dev1: 0x17, dev2: 0xff

[ 2069.051853] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2069.060308] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.062035] fsa9480 7-0025: dev1: 0x13, dev2: 0xff

[ 2069.063858] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2069.067409] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.068963] i2c i2c-7: sendbytes: NAK bailout.

[ 2069.069124] fsa9480 7-0025: fsa9480_detect_dev: err -5

[ 2069.069209] fsa9480 7-0025: dev1: 0xfb, dev2: 0xff

[ 2069.070971] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2069.091186] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.092983] fsa9480 7-0025: dev1: 0x10, dev2: 0x3

[ 2069.094731] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2069.104292] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.105018] i2c i2c-7: sendbytes: NAK bailout.

[ 2069.105108] fsa9480 7-0025: fsa9480_reg_init: err -5

[ 2069.106102] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2070.150280] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2070.152079] fsa9480 7-0025: dev1: 0xff, dev2: 0xff

[ 2070.153836] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2070.166528] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2070.167026] i2c i2c-7: sendbytes: NAK bailout.

[ 2070.167188] fsa9480 7-0025: fsa9480_reg_init: err -5

[ 2070.168389] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2070.192257] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2070.193986] fsa9480 7-0025: dev1: 0x10, dev2: 0x1

[ 2070.195786] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2070.210682] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[1] http://electronics.stackexchange.com/questions/13041/how-do-i-make-the-fairchild-fsa9280-fsa9480-fsa880-boot-pin-trigger-samsung-gal

UNetbootin on Mac OS X

2011-08-29T22:15:00.001-04:00

Just in case anyone wants to use UNetbootin to create e.g. an Ubuntu Live USB device and it isn't working, there are two key steps that are not performed by the UNetbootin binary for OS X.

After downloading the ISO, use Disk Utility to partition your USB device. Ensure that you've selected Options -> MBR . After formatting the disk...

1) Ensure that you've marked the partition active

fdisk -e /dev/rdisk1

f 1

 write

exit

2) Download syslinux and write the critical mbr binary your device.

dd conv=notrunc bs=440 count=1 if=mbr.bin of=/dev/rdisk1

After that, just use UNetbootin as usual.

OMAP3 SGX EGL Drivers Add Wayland Support

2011-08-03T11:28:00.008-04:00

Just in case anyone was wondering this is a pretty big deal. Imagination Technologies, whose 3D graphics cores drive most mobile displays, has announced support for the EGL_KHR_Image_Pixmap extensions used by the Wayland display server protocol.

For those who haven't been following, Wayland has gained a lot of momentum as a non-X-based window compositor for Linux-based operating systems. Wayland facilitates client-side rendering, similar to the Quartz compositor used in Mac OS X. It has since been adopted by Meego and Ubuntu as their preferred compositing backend.

The stated goal of Wayland is to provide a user experience where "every frame is perfect". This is a rather necessary and long overdue improvement since traditional Linux desktops based on the aging X11 display server tended to suffer from artifacts such as tearing, visible redrawing, and flickering. However, Wayland retains the capabilities to encapsulate the traditional rootless X server for legacy applications. Wayland rendering targets already exist for popular toolkits such as GTK+ and QT among others.

Check out the video below for a (slightly older) demo.

Today, Wayland support exists for graphics chipsets from Intel, AMD, NVIDIA (nouveau) and SGX (OMAP3) platforms. OMAP4 support probably isn't far off.

I guess it's time to fire up the old BeagleBoard ;-) Incidentally, happy birthday!

Canon Printer Drivers under Mac OS X

2011-07-26T16:13:00.002-04:00

Parc Oka for the Canada Day Long Weekend

2011-07-06T12:53:00.001-04:00

We went on a bike & camping trip to Parc Oka for the weekend and documented the trip with some photos.

Originally we were supposed to take a train to and from Deux Montagnes, which would have made this trip very easy, but the AMT had some unannounced line work. So Erin threw together some last minute improvisational plans and the "to" portion of our trip included a horrific STM then CIT commuting.

We ended up biking from St. Eustache, which was only about 5 km further. Taking the AMT from Deux Montagnes on the way back was much more accommodating for our bikes, and our bike-seats and Croozer full of camping gear / 3yo child.

I also traced our trip using MyTracks for Android, and it worked quite well. Considering how much I'm on my bike, MyTracks is practically like a personal trainer given that it records all of the stats you can imagine (latitude, longitude, bearing, speed, elevation, time, etc).

It was the perfect weekend to get away, and Parc Oka was awesome. The water provided an excellent escape from the heat that weekend.

The End of an Era

2011-05-24T09:44:00.004-04:00

Today I arrived at my office (which just happens to be wherever I sit down with my notebook), and was quite contented to read that Linus has seemingly decided to move on to the next major version change. This will probably also include a change in the numbering system that is currently used for kernal releases, much to the appeal of GregKH.

I have been using Linux since around the 2.2 days, and have been actively hacking / employed with Linux related projects on various architectures with both the 2.4 and 2.6 kernels. I guess you could say that I have Linus and many other kernel, arch, & subsystem maintainers to thank for that.
Sentimentally speaking, I find it immensely cool that I am currently writing this blog post using a phone running Linux/Android released by a company that leveraged the power of Linux for a significant part of their commercial success. If anyone is wondering, the phone is a Nexus S and the company is Google.

Here's to all Linux hackers, wherever your workstations may be.

update-20110529: 3.0!

Time for Change

2011-05-03T15:11:00.000-04:00

Lately I've been trying to write less political editorial on my blog, but I'll make an exception just for today.

There are some things that I'm very (indeed, historically) happy about after yesterday's Canadian Federal Election and there are things that also make my skin crawl. What those things are is an exercise for the reader to determine.

Regardless of the winners and losers of the election, I wanted to write about the topic of proportional representation in the house of commons.

Most of the time

... when somebody argues against proportional representation, they usually make the argument that small communities will suffer if they do not share the same ideals as the majority

That argument has some merit particularly when considering the right to maintain a cultural identity or a specific type of business or industry in Canada.

In this context, there are some cases where locality does play a major role. However, for the most part, Canada is everywhere-diverse in terms of culture. Almost everywhere in the country, there are people celebrating and learning about their own and different cultures, together as Canadians.

In terms of industrial locality, the issue can be fairly easily solved by transferring more power to the provincial governments and by supporting particular focus groups rather than dismantling them. It also affords voters the privilege of having an equal voice at the federal level.

That is the argument... most of the time.

Occasionally

... when somebody argues for proportional representation, they usually make the argument that large communities will suffer if they do not share the same ideals as the minority. To put more of a positive spin on it, one could also make the argument that the majority would not have the benefit of hearing the oft important message of a marginalized voice.

Why not let our political system reflect the diversity of our population? Let unique voices be heard & eliminate redundancy.

The USRP E100

2011-03-30T11:07:00.016-04:00

I thought that I would take a moment to plug a product that I think has great potential for anyone working, experimenting, or interested in learning about digital wireless communication - the USRP E100. This device, jointly developed by Ettus Research and OpenSDR, was announced just a few months ago. It's a tightly-integrated embedded Linux solution for research into digital baseband signal processing for wireless systems.

I've worked with previous products from Ettus, like the USRP2, and have had 99% good experiences. The entire USRP product family is supported with GNURadio, which greatly facilitates signal visualization, processing, and software interfacing. The one down-side of using the USRP2 was that the only way to connect with it was by using a Gb ethernet cable (which is not a standard feature on laptop / desktop computers). The Gb ethernet port did not make the USRP2 'networkable' since it was only used for data transfer using raw ethernet packets.

The main differentiator of the E100 is that this device ships with a modular ARM board from GumStix. The stock GumStix board is powered by an OMAP3 (Cortex-A8) chip from Texas Instruments. The modular design makes repairs and upgrades easy (any COM can be used with conformant electrical and mechanical specifications). The OMAP3 has appeared in several mobile phones, but (more importantly) has also been the driving force behind a tidal wave of low-cost and powerful embedded Linux developer boards such as the BeagleBoard and BeagleBoard xM. Texas Instruments really has made a great contribution back to the developer community just by making these developer boards available. The OMAP3 processor is capable of running just about every operating system in existence, ranging from Windows Mobile to Ubuntu or Android (all flavours of Linux, and FreeBSD too). The E100 (probably) ships with Ångström by default. As for interfacing, the E100 even exposes HDMI, ethernet, and USB ports so this SDR box can literally be it's own work-station. I really wish this was available back when I was working on the USRP2!

So - that's great - an SDR device that eliminates the need for an external laptop or desktop computer so the entire system consumes much less power in total.

There's just one more thing...

The way that the OMAP3 interfaces with the radio hardware is super-efficient. The TX and RX buffers are mapped directly in to the OMAP3's MMU. To the layman, this means that the Linux kernel can easily expose the radio as a regular device to userspace using Phil Ballister's driver, which is on its way upstream. Furthermore, users of TI's Code Composer Studio (or developers who choose to use CGT directly) can write DSP firmware for OMAP3's integrated C64x+ DSP. Thus, keen developers can run code on the DSP to control the baseband radio and process baseband signals directly (the way nature intended). Naturally, only one processor on the chip can 'own' the radio buffers at one time (without proper synchronization).

To summarize: the USRP2 E100 is the ideal product for most engineers researching embedded RF systems and digital baseband processing.

PS: Nice work Phil! (he was my co-mentor for GSOC2010). I would love to use the E100 for some of my more recent work with ahumanright.org to engineer a low-cost / low-power satellite modem...

GSOC 2011: I Recommend Mono.SIMD

2011-03-23T09:51:00.009-04:00

If anyone is looking for a good GSOC 2011 project, I would suggest Mono.SIMD. If you don't already know what SIMD is, then this project probably isn't for you, but you might find it interesting nonetheless. Although the Microsoft .NET version of C# does not explicitly support SIMD, once Mono has it for x86, ARM, and others, Microsoft likely will want it as well. The ARM port is just as important (if not more) important than the x86 port, so please don't ignore it. Buy a BeagleBoard or a PandaBoard to tackle NEON SIMD, (or even buy a Plug Computer or Verdex Pro for iwMMXt) . Although some people may think that iwMMXt is old news, it still lives on with Marvell's Sheeva and ARMADA product lines. You can still do blazingly fast multimedia with iwMMXt (h264, for example) but its limited to integer operations rather than floating-point (which is more efficient for multimedia in any case).

Chances are you already have a PC with several flavours of SSE, so you should be all set to do add x86 SIMD and at least one flavour of ARM SIMD to the Mono JIT. Read this article to see why it makes sense.

PS: Good luck to all volunteering organizations and students this year!

Death, Taxes, & Voting

2011-02-27T11:48:00.002-05:00

Considering that less than 50% of Canadians of the age of majority actually vote, why don't we make it mandatory to vote every time an individual files their taxes?

PS: I am intentionally leaving a lot of editorial commentary out of this post.

AMD Open-Sources Video API

2011-02-26T09:16:00.000-05:00

This is quite a leap forward for free and open-source software users everywhere.

Nvidia ARMs Themselves for a Shot at the Desktop Market

2011-02-16T09:52:00.002-05:00

X86 chip manufacturers should probably be a little bit worried at this point, considering that Microsoft has also decided to do a full windows port to ARM. Of course, Linux has been running beautifully on ARM for almost two decades already.

Don't be fooled, Nvidia's ARM team is not only aiming at the netbook / laptop market - they're setting their crosshairs on the desktop market as well, as indicated by their roadmap.

PS: If you are reading this, and you were present at a certain meeting with me not too long ago where we were talking about buying an ARM architecture license, then I hope you are hearing this message loud and clear. My honest opinion is that you need to act now or suffer tremendously in sales.

Ahem... Picasa?

2011-02-13T10:29:00.000-05:00

Dear Google,

Don't you think it's about time to make functional Picasa clients for Linux and Android?

Currently, I am relying on a random 3rd-party app maker to upload video from my Google Nexus S to my Google / Picasa Web account - it's a little discomforting.

Also, video transcoding for Picasa Web albums is really straight forward to do using ffmpeg from the command-line, and it will even do VP8 :) ... but still, I can only upload videos from Picasa using Windows or Mac. If you're worried about software patents, then just use a plug-in architecture with dlopen(). That way, users can supply "their own" versions of popular multimedia encoders / decoders. For closed-source platforms, just write a plug-in that uses the codecs available on that system (e.g. windows, os x).

OMAP4-powered Blackberry Playbook runs QNX

2011-01-25T10:45:00.001-05:00

Congrats for TI, RIM, and QNX on being a choice pick of CES.

Make

2011-01-24T15:57:00.000-05:00

Having a modern (i.e. multi-core) workstation makes such an unbelievable difference. I can't even begin to describe how much my life has been made easier by "make -j9".

U-Boot on the TS7260

2011-01-19T01:40:00.004-05:00

Click here for the original image

The Future of Android and the Chrome OS

2010-12-16T13:03:00.001-05:00

Apparently I'm not the only one to have some innovating thoughts about Android and the Chrome OS. Slashdot has a story that mentions how the two should be merged in the near future. Furthermore, Paul Buchheit, the creator of Gmail, also seems to agree. I'm still a little bit hesitant to disclose all of the technical details publicly, but it would seem that Google is starting to take some steps in the right direction. My plan essentially boils down to taking the Android userspace back to the desktop and incorporating an Android App Screen, much like what Apple showcased at their Back to the Mac event, but also modifying apps so that they are literally write-once, run-anywhere - on any architecture. Incidentally, it would also enable users to run any of the tens of thousands of amazing open-source applications already available, and potentially tie in a revenue system for open-source projects via the Android app store.

Perhaps it was slightly selfish to come up with these ideas - I really just wanted to beautify Linux in both software and hardware, and make the user experience just as enjoyable as it is on a Mac (minus the annoying hard-coded settings). Could 2011 finally be the Year of the Linux Desktop?

Oracle vs. Google, Apache Resigns from JCP

2010-12-09T17:08:00.004-05:00

Now that the Apache Software Foundation has officially resigned from the Java Community Process, I think it's fair to say that Oracle has passively waged a war on any entity pairing the terms "open" and "java".

Most people are unaware at just how large and far-reaching of an impact this has. What it boils down to is this

Oracle is unwilling to participate responsibly for the community revision and release process that they wholeheartedly bought into with their acquisition of Sun Microsystems
thus, anyone wanting to use a certified Java environment to run their code must obtain that Java environment from Oracle
therefore, Java, as a specification, will be 100% controlled, owned, and steered by Oracle

This effects everything from the software you can run on your mobile phone, to the software that you can run on your corporate servers - so yea, it's pretty far-reaching. Furthermore, there are probably millions of companies that rely on (open source!) Java technology to do their day-to-day business whose livelihoods are now threatened.

Oracle's only "open source" offering of Java, is OpenJDK, which is completely inadequate in MOST of the cases where I would ever use Java. Let me elaborate.

I use Java to program for two platforms mainly. The first is a barebones Linux system running on an ARMv4T processor with 32MB of storage. I actually tried to run OpenJDK on it over an NFS root - let me tell you how much of a freaking joke that was. OpenJDK used over 110MB of storage space. My preferred JVM, on the other hand, is JamVM paired with the GNU Classpath, which can be tuned to use as little as 7MB of storage. OpenJDK is bloated, and I'm putting that as euphemistically as I can. OpenJDK takes a century to do anything on this platform. JamVM on the other hand is practically like lightning. In short, OpenJDK is only for desktops and servers. I've never even attempted to use J2ME due to its long list of shortcomings (just google j2me shortcomings, e.g. this).

My second platform for programming in Java is Android, which (openly and welcomely) borrows its Java base from the Apache Harmony Project. I think Harmony has some serious potential on ARM, considering what I've seen so far with Android. Anyone who knows me, knows that I like Android and I think it's a great piece of work. I have personally hacked Android onto several devices, and continually find that it's doing great things with both the native code and Dalvik / Java. One could arguably say, that Android was the best thing to happen to Java in the last decade. Oracle is suing Google, claiming that Google had copied code directly from them (or Sun) somehow, and put it right into the Apache Harmony Project. This is completely ridiculous because Harmony was, in fact, created before Sun made any of its source open.

Oracle also owns a few patents covering various 'inventions' in the form of software (originally filed by Sun) and they're incorporating claims of patent violation in to the Android / Google lawsuit. Let me be (hopefully not the first) to reveal something here. Sun's original strategy, by filing these patents, was to prevent any kind of patent-related lawsuit that might be inflicted upon Java or any of its users. Indeed, the Sun patents were only originally intended to be defensive in nature. Oracle has turned that around 180 degrees and started using those patents offensively to sue companies that actually do innovative things with Java.

The state of Oracle vs. Google puts Google in a really tight position. I agree (and so do several now-resigned members of the JCP EC) that Oracle has done the worst possible thing that they can with Java as a platform and specification. Oracle's position threatens people from modifying and redistributing Java for whatever purpose they want (source required), which is the fundamental attribute for any piece of open source software according to the definition by Bruce Perens. This means, that Oracle's "open source" offering of OpenJDK might as well be binary-only for any meaningful purpose.

Now, the Android community, who has had enough vision to do something genuinely new and useful with Java, are relying on a possible court ruling that Oracle's software patents are invalid. In my opinion, they are, but that's only because I think all software patents are invalid. The USPTO, on the other hand, has traditionally given out software patents like business cards. The USPTO is getting more reasonable, and is even revoking software patents in some cases but I feel that it's a dangerous position at large for Google, the Open Handset Alliance, and the Android developer community.

I recently submitted several ideas to Google that should appease both Oracle (from a legal standpoint) and Google in this whole fiasco while simultaneously injecting Android with enough adrenaline, marketability, and sex-appeal to push it even past OS X, the iPhone, and the iPad. I've put in a fair amount of the technical legwork in my free time to see just how realizable this is - and it is very realizable. I've communicated some of these ideas with various developers of original software components and have had very positive feedback. It is doable. Google even responded to me but it's been a couple of weeks and I haven't heard back from them for a while. These suggestions could literally be the best thing to happen to Linux and Android in a long time. I realize that Google is busy (trust me, I understand what its like), but I do hope they reply. I freely offered these suggestions to Google, purely for the sake of securing Android w.r.t. Java. Whether they wanted to give me a job for implementing all of it was irrelevant - I keep myself busy doing the things that I love regardless of who I'm working for.

The solution that I presented to Google was only good for temporary purposes - it still doesn't address the issue of Java as an open specification or Java as an open piece of software. For those reasons, I was saddened today by the announcement of the ASF because it only confirmed Oracle's passive-aggressive position... and potentially the end of Java as a good choice for a programming language.

Edit: I just thought I would point out the self-contradiction of Oracle as well; if you make e.g. OpenJDK available to the public under the GPL, then how can you say that you withhold the right for people to modify it and redistribute it when they provide the source. In this sense, there could be absolutely no wrong done by Google considering they didn't even base their code on OpenJDK but rather on Harmony.

MultiCore Threading

2010-11-06T14:31:00.000-04:00

This post is partially in response to a question somebody asked me recently about threading on ARM Cortex-A9 systems. I was asked whether or not that just by creating a several new "threads", whether the threads will "automatically" run at the same time on separate cores without any operating system or system library interaction. The short answer is no.

The long answer begins with a 1-minute history of computer architecture. A processor generally has something called an instruction pipeline. For scalar architectures, this meant that only one instruction (read: hardware function) could ever be executed at any given time. Some clever hardware engineers determined that this was not utilizing the hardware as effectively as possible, and so they came up with the idea of a pipeline, or the superscalar architecture, which allows more than one hardware function to be executed at a time. Generally speaking, this meant that if the 'add' function was being used at one point in time, the 'memory fetch' function could also be used at the same point of time. This introduced something they industry termed a 'data hazard'. For example, if a certain add operation depended on the result of a memory fetch operation, then the add function would produce unanticipated results if the memory fetch operation had not completed in time. The first solution to this problem was to introduce stalls in the pipeline, which were (and still are) very bad. The second solution (really an improvement on the first solution) was to add another hardware unit in to the chip that would re-order the instructions before sending them down the pipeline in order to minimize pipeline stalls due to data hazards. That hardware unit was called an out-of-order execution unit. Instruction scheduling can actually be done in software as well, by the compiler and linker, but since this only allows off-line instruction scheduling, it cannot account for asynchronous events that are only stochastically predictable. This is where the branch prediction unit comes into play, but I'll omit that for brevity. So far, only instruction-level parallelism has been covered.

The Cortex-A9 Pipeline

The Cortex-A9 MPCore

Now, most manufacturers realized that it would be best to let uniprocessor code execute on multicore systems so that programmers and compiler designers wouldn't have nervous breakdowns trying to optimize their code for the googles of system permutations that would be in existence (all of them would be vector processors). Thanks to all manufacturers for that one. ARM is no different, for the Cortex-A9 family of processors still belongs to the ARMv7a instruction set architecture. However, the general decision to run uniprocessor code on multicore systems necessitated the use of software entities to actually manage and, really schedule, when and where that code would be executed.

Getting back to the original question, it's important to consider what a 'thread' actually is. A thread is a pure software abstraction for a logical sequence of events. Threads are often associated with a priority, a state (e.g. ready, waiting, zombie), and an instruction pointer. As for the threading abstraction (e.g. POSIX threads), they must a) introduce data protection primitives, as well as mechanisms to b) wait until data is not in use and c) signal when data is no longer in use. Usually, the operating system deals with scheduling which threads are running at any given time, although it isn't that hard to do this without an operating system. The fundamental method of synchronizing threads is via shared sections of memory and atomic processor instructions. The thread scheduler uses timer-generated hardware interrupts to periodically evaluate the state of all threads, and then schedule code (i.e. determine the next branch target) for 1 to N cores. In the case of a uniprocessor system, this means that the scheduler itself is being swapped in and out after a certain number of time slices, where each time slice is occupied with a thread based on priority, state, etc. The number of cores available at any given time is also controllable with software, since cores can be dynamically powered off to save energy. This is something that the thread scheduler must take into account.

As for initialization of each core, typically a single core would be activated at power on, then as the operating system (or main binary) launches, a threading manager would also be launched. The threading manager would initialize and create descriptive data structures for the remaining cores on the system, and so on. As each core runs, it literally operates in a loop; 'jump' to an instruction and start executing, or go to sleep if not needed; then do the same thing again. The details on power up, particularly in the case of the ARM architecture, are very manufacturer dependent, since e.g. an OMAP MPCore implementation can have several physical differences and register locations than, e.g. an MSM MPCore implementation.

In summary, sure, it's easy to have several cores running at the same time, but getting them to coordinate shared data properly (i.e. run threads with shared data sections) requires that the concept of parallel execution be built into an application or library (which is not always easy). For a simple example, assume a library allocates 512 MB (i.e. 2**19 bytes) of memory, sets it all to zero, and then deallocates the memory. Would it run any faster on a multi-core system than it would on a single-core system? Absolutely not, because the processor cores do not follow the programming methodology of DWIMNWIS (unless it has a pretty advanced hardware rescheduler).

If I modify the library to first query a threading library to find the number of logical cores, partition my buffer into N sections, and then create several threads that are aware of their own partition boundaries, then I can expect my library to perform faster by a factor according to Amdahl's law: S=1/(F+(1-F)/N). In this case, since the amount of the problem that is not parallelizable is 0%, F=0, and the speedup is S=N. However, even in the case where a thread scheduler is present, there is still variability about where the code will actually run - for example, all threads could even be run on a single core, rather than distributed among them all.

Amdahl's Law: S = 1 / ( F + (1-F)/N )

Oddly enough, even though I have been writing threaded code for about a decade, I still have a pretty antiquated workstation on my desk (by today's standards). Indeed, my workstation is a single-core pentium-m laptop. It is a surprising hunk of garbage that never decides to finally die, although its been close on several occasions. In any case, I hope to have that upgraded soon to a quad-core Intel i7 machine, so that I can have 8 logical threads to speed up my ultimate goal of world domination.

Also, I'm looking forward to receiving a PandaBoard shortly, with an OMAP4440 dual-core Cortex-A9 chip. This will give me incentive to do some SMP performance tweaks on some of the NEON-enabled software I've written lately (e.g. FFTW).

Smoking Laws in Ontario, Quebec

2010-10-01T22:56:00.004-04:00

On a different note, I thought that I would talke about an idea I had for an amendment to the existing Ontario bylaws that prohibit smoking in public buildings, places or private automobiles with a child present. It is illegal in most municipalities in Ontario. It's getting better in Quebec, but Ontario is a bit further ahead. The biggest problem, in my opinion, is smoking in the home around children. Certainly, there have already been numerous studies that indicate without a doubt that smoking in the home around children is harmful, but why isn't it illegal? I suppose that one could argue that it interferes with a persons rights... to smoke... and ... err... slowly poison their children (!?). Ridiculous, right? In some cases such as mine, it isn't even a volountary decision, and I would really prefer not to have any member of my family, but especially my son, slowly poisoned.

In Montreal, it's common to rent and live in small buildings where each floor is a residence in itself. In some older buildings, smoke actually travels very easily through areas of flooring (or ceiling), through ventilation, or even through plumbing! I live in such a dwelling, with my 2 1/2 year old son and his lovely mother. And the tenant that rents the residence below us, refuses to smoke outside, even when the weather is clearly warm enough to do so comfortably. The second and third-hand comes up into our apartment through various sections in our fairly old 3-story apartment building - we live on the top floor - and at times it is so dense that we can actually see it in the air. Clearly in those circumstances, we open the front and back doors to our balconies, and use a fan to properly ventilate the apartment. Actually, we need to use 3 fans, since the apartment is rather long and old fashioned, and there are no other sources of ventilation aside from the front and back balcony doors. However, we cannot leave our doors open all day and all night, since it would basically be equivalent to inviting people to steal from us, and we would freeze to death in the winter. Not to mention, that it probably has a measurable effect on our heating & electricity bill. So when we come home, we often find that the apartment smells awful. To be specific, it smells like a mixture of cigarette smoke and fabreeze, which our neighbor downstairs thoughfully uses to mask the odor. Thanks for the thought, but the fabreeze really doesn't make it smell any better, and it certainly isn't reducing the health risks to my son.

I find it particularly bothersome when I hear my son cough in the middle of the night and I go into the kitchen to get him a glass of water, only to be greeted by a cloud of carcinogens. It's really no wonder why he's coughing.

It's most certainly not healthy for our son, or us, at any time of the day or night. I've asked our neighbor politely to only smoke on the balcony, making specific mention about my concern for my son, and I've even asked the landlord to speak with our neighbor, but this hasn't made a difference and has only made our neighborly relationship less pleasant. Actually, our landlord lives in the building too, and he shares the exact same cloud of carcinogens coming up through the flooring. He also said it's intolerable at times, but unless there's a law about it, there's really not much more he can do. Moving is not an option. We really like our place, and from the landlord's perspective, he's stuck - this building is his property, business, and home. We live near a great park and we get a great sunset on our balcony. The kids in the neighborhood all seem happy, it's minutes from downtown and just far enough to be not down-towny, and ... well, there's a really great park across the street!

When will smoking laws catch up with common sense!?

I think this is a reasonable suggestion to the committee responsible for making smoking laws. Although the residences in question are not public buildings, there are direct effects on the health and safety of members of the public. It's basically the same logic that requires drivers to drive slowly in an area where a deaf child lives, even if it's not their child. Logical, right? Complaints would probably be followed by a building inspection and a mandatory no-smoking sign. I'm just hoping that maybe someone in the Ontario & Quebec governments will read this post and decide to finally take some action so that smoking laws catch up with common sense.

Interesting Links

[0] http://www.ocat.org/onlegislation/comparison.html
[1] http://www.scientificamerican.com/article.cfm?id=what-is-third-hand-smoke
[2] http://www.sciencedaily.com/releases/2010/02/100208154651.htm
[3] http://www.thestar.com/living/article/562069
[4] http://www.cbc.ca/news/pdf/prevention.pdf

Will NVidia Follow Suit of AMD's Doc Disclosure?

2010-10-01T14:39:00.000-04:00

Recently, AMD committed to releasing technical documents for their GPUs in order to assist open-source software developers to write better 2D and 3D graphics drivers. AMD actually followed through with that committment as well, and you can find the technical documentation here, if you're interested. Thanks AMD!

Although AMD will continue to release binary-x86* Linux drivers, the release of their chipset documentation (actually for R300 R500 and R600 series), is intended to improve the 'out-of-the-box' experience for PC users.

AMDs chips are entirely x86, from what I can tell, although I think i remember a rumor that they licensed some of their graphics technology to Apple for the chips that went into the iPhone, iPad, and iPod Touch. Aside from that AMD has no (publicly visible) vested interest in having graphics drivers that are architecture independent.

On the other hand, NVidia actually purchased an ARM License and produces their own Cortex-A8 and Cortex-A9 silicon with integrated NVidia graphics (Tegra, Tegra2), so they have both an x86 and an ARM presence now. Not only that, but NVidia continues to be the sole surviving GPU company, since AMD bought out ATI.

However, NVidia seems to be encountering production delays trying to get (Linux-based?) Tegra2 products to market. I can only assume that they aren't having silicon issues[1], so it really must be an issue getting the hardware to work well. They have opened up their Tegra2 site to Linux developers, offering a development board, source code, and binaries. However, I'm really left wondering if they could also benefit from disclosing some documentation of their graphics cores and perhaps the Tegra2 TRM, so that the next generation of NVidia-powered mobile devices would also provide an excellent 'out-of-the-box' 2D and 3D user experience.

Will NVidia follow suit with NDA-free documentation disclosure? Lets hope so... it would definitely be enough convincing to get me to buy a Tegra2-based device.

[1] as in: whoops! this graphics subsystem only processes data at 1/2 the necessary rate! .... ahem... maybe you know who I'm talking about

Today

2010-09-15T21:08:00.000-04:00