The Software Freedom Law Center (SFLC) describes itself succinctly:

We provide legal representation and other law-related services to protect and advance Free and Open Source Software (FOSS). Founded in 2005, the Center now represents many of the most important and well-established free software and open source projects.

Have you heard of them? If not then maybe their actions are a little more familiar. The SFLC has been involved in GPL compliance actions and lawsuits against companies such as Supermicro, Extreme Networks, Bell Microproducts, and other notable companies. Most of the time these enforcement actions are centered on the busybox application since the SFLC represents the authors of busybox and this tool is commonly shipped with embedded devices.

My position on GPL compliance is simple: I want the company I work for to comply and the customers I work with to comply with all relevant software licenses both proprietary and open source. Compliance often is a natural outcome of having a well designed engineering process. Bradley M. Kuhn in his blog says that “…I’ve found myself repeating this advice on the phone, again and again, to another new GPL violator who screwed it all up, just like the last one did.” My limited observations mesh with his. I’ve see far more simple compliance issues caused by ignorance or oversight and zero complex violations caused by forethought and malice.

Of course… I’m not in the enforcement business. I’m just not looking with the same intent that the SFLC is. My role has mostly been educational.

The SFLC just published “A Practical Guide to GPL Compliance” by Kuhn, Williamson, and Sandler to their website. I’d consider this a “must read” for a few reasons:

• They offer what I consider to be some great advice on the practicalities of compliance. Simple edicts like making sure that you don’t have one “build guru” who holds the sole knowledge of how to assemble your product.
• They clearly have an understanding of the embedded software realm from both the technical and business perspective. Direct commentary on how to work with 3rd party contractors or ODM’s is included.
• The SFLC is also a likely opponent in a GPL compliance issue if it were to face your company. They want you to comply and do so without coercion. If one were to fail to comply then the SFLC might well knock on your door. Their advice on how they view compliance is enlightening and reading up on it could be considered a risk mitigation strategy.

I do have some criticisms of the document, however. My engineering perspective of the world has often caused frustration as I’ve learned about legal issues from experts like MontaVista’s Jason Wacha. I’ve always looked for a “license compliance compiler” that would crunch your code and tell you if you were in compliance with the applicable licenses. The truth of the matter is that no such tool will ever exist. Yes, I know about Black Duck and Palamida. These tools just correlate source code to the licenses conventionally associated with the code. Not the problem I’m concerned about here.

The reason that there will never be a “license compliance compiler” is that, at least in civil law in the US, much of it seems to be about risk. My engineer observations are that attorneys view the situation and then describe the risks of proposed decisions to management. The GPL does not provide complete and total guidance on all aspects of compliance. Much of the risk evaluation comes from the viewpoints and opinions of groups who have standing to sue… in this particular case the SFLC!

[Note that this lack of complete and total guidance for complying with the GPL isn’t a criticism of the GPL. Many (all?) contracts and licenses seem to be like this.]

My criticism is that there are some places where the SFLC’s compliance guide represents their opinion of necessary compliance steps as something grander. An example:

“We consider the name of the [proprietary] compiler [that can’t be shipped with source code], its exact version number, and where it can be acquired as information that must be provided as part of the Corresponding Source.” [emphasis theirs]

The “We” in this statement is the SFLC which represents the authors of various open source licensed code. The word “must” really means that it is SFLC’s strong opinion that one should provide this information. It is also my opinion that this is a common courtesy that is painless to implement. Why not provide this information?

My opinion on the matter, and SFLC’s as well, should be more clearly designated as just that: opinion. My last nuance on this before I end is that not all opinions are created equally. SFLC can enact a GPL compliance action against your company. I can’t. You should read this document and factor the advice it offers as both practical advice for complying with the GPL and for avoiding the ire of the friends of the open source communities at the SFLC.

ShareThis

It has been a very interesting year looking out the window at the embedded Linux scene. I see total mainstream adoption as a clear and present trend. I base this off of “man-on-the-street” conversations with acquaintances. I was at a training conference on a non-technical topic. Asked what MontaVista did I gave my non-technical explanation. Quick as anything the person replies… “oh, embedded Linux. Yes, our engineers use that.”

Linux and the importance it has to technology product companies is now common awareness. That means something significant.

I’ve also seen a strong trend in recognition that the compelling problems of today are well outside the realm of just kernels, toolchains, and booting. The profound increase in potential software capability that open source brings to bear on new products has its one set of challenges. You can do media, office applications, advanced networking, wireless networking, power management, etc… but making choices and integration are far more challenging.

We’ve been able to help many of our clients to fabricate compelling products using a whole range of technologies north of the kernel. We’ll have some fun time discussing these in the coming months, I hope.

So since the action just starts at the kernel let’s take a moment to plug some upcoming conferences where you can explore these issues:

• Linux Plumbers Conference, September 17th-19th in Portland, OR: If you’ve ever been to the Ottawa Linux Symposium then I imagine this will be like that… just with a focus on all of the interfaces that bridge the kernel/userspace/application divide.
• MontaVista’s own Vision 2008 conference, October 1-3rd in San Francisco, CA: We had 400 attendees from 13 countries attend last year on this inaugural event. If you’re focus is on commercial product creation using Linux then this is a great even to network, learn, and brainstorm at.
• DESIGN & ELEKTRONIK Entwicklerforum, Oct 15, 2008 in Stuttgart: I had not heard of this conference before but there are a number of interesting presentations scheduled including two of from my fine colleague, Klaas van Gend and Ned Miljevic.
• Embedded Linux Conference Europe, November 6-7th in Ede, The Netherlands: One of the big dogs of the annual embedded Linux conferences. The Klaas & Ned show is making an appearance here as well.

So there you go… blow your annual travel budget out and make them all!

If you can only pick one then pick Vision 2008.

Brad

ShareThis

In this line of work there are often things you can’t say. You just can’t go around talking about what our customers do with MontaVista Linux. Like I couldn’t possibly talk about the smile I get on my face when the chock-full-of-MontaVista-goodness high speed 3G cellular data network delivers packets to my <insert the name of the absurdly popular phone>. Can’t talk about that.

A few LinuxDevices.com articles will show you what other folks have said, though. Over on linux.com read up about how RipCode is helping MySpace to deliver video using MontaVista Linux.

Or you can read about how seven new MontaVista powered LiMo based phones were announced.

[Note… I don’t have a problem directly linking to LinuxDevices.com… maybe they’ll return the favor the next time they mention my blog!]

I stared with MontaVista back in 2000. Long time ago. I spent all my time answering questions about what Linux was, why open source wasn’t communism, and how someday our erstwhile competitors would come to regret the FUD they spread about Linux. Now a days I get to go to Best Buy and point out MontaVista powered products all over the place.

It makes me smile not because of some corporate dominance game. It makes me smile bcause I was part of this fight in the war for open source ascendancy and we won it. Reading Cuong Nguyen of RipCode say “We only considered Linux” makes me smile and would make me smile even if they weren’t our customers.

ShareThis

Last week’s webinar left off with several questions from the participants. I answered mine in an earlier post. My collaborator Kaitlin Murphy has provided answers to the hardware questions. Courtesy of Intel and Kaitlin I was permitted to post her answers here:

Q: What kind of power benefit we can gain by entering C6 of Atom CPU?

In the C6 state, the Intel(r) Atom processor will consume approximately 6% of the power it would consume in the C0 state. This roughly correlates to 100 mW, although the exact value may vary depending on which SKU of the processor is used and other factors. Obviously, the more time the Intel(r) Atom processor spends in the C6 state (or any other sleep state), the more power savings will be realized.

Q: What is the typical power consumption on a MID device using Atom on C0 and C6?

The power consumption of the Intel(r) Atom processor will vary significantly by usage conditions. For the MID type application, the average power is 160 - 220 mW, with ~100 mW idle power. (Idle and Average Power power quoted is using a mean leakage CPU which means that 50% of the CPUs will have leakage values below the median value and 50% will have leakage values above the median.) These numbers will differ in an embedded use case.

Q: Is it possible to disable part of the chipset (in our case, no video needed).

On the Intel(r) System Controller Hub US15W, it is possible to effectively disable the graphics core via clock gating. Intel does offer other “headless” products - such as the Intel(r) EP80579 which may work for your application, depending on your needs.

Q: …can [you] give me a [watt per MHZ] value?

This will be SKU dependant. For the Intel(r) Atom Z530 SKU at 1.6 GHz, the TDP is 2.2 W. Therefore, your theoretical W/MHz value is ~727 MHz/W. A similar calculation applied to the Z510 SKU yields ~550 MHz/W.

Q: How much as a percentage does the SpeedStep technology help if I have a real time application and cannot go to the lowest C state?

Intel(r) Enhanced Speed Step Technology can still be a big asset in power savings and power management - even if you can’t go into the lowest C state(s). The amount of time a processor can spend in a lower sleep state is primarily dependant on what it has been tasked to do. There is no reason a processor can’t handle real time requests when operating at a frequency lower than HFM. In fact, I’ve seen customers de-rate a processor (essentially forcing it to run at a lower frequency, simulating SpeedStep) if lower power consumption is a requirement.

Again: A big thank you to Kaitlin, Intel, and all of our participants.

ShareThis

VDC (a research firm covering developers of embedded systems) recently unveiled a “teaser” press release commenting on developer attitudes towards multicore architectures. The teaser said “…embedded developers still do not yet consider multiprocessing and multi-core architecture support a highly critical factor influencing their selection of embedded operating systems for current projects.”

Well… isn’t that confusing? Is multicore a flop? Did Intel, Cavium, ARM, TI, and Freescale all place the wrong bet?

My opinion is, no, multicore isn’t a flop. This survey is, however, a symptom of a few inconvenient truths.

Most applications likely can’t exploit multicore without significant re-engineering.

Recent discussions with several customers helps to confirm some of this thinking. I’ve heard all sorts of misconceptions about multicore and what developers need to do to exploit it. There is some real wishful thinking going on in some minds about how throwing 8 processors at a single threaded application will make the whole job GOFAST! right now.

We had a discussion in the office a while ago that was sparked by this informal ESC poll about multicore adoption:

Only 51 percent of respondents said they have applications running on multicore CPUs or will migrate to multicore processors in the next 3-5 years. A whopping 49 percent said they neither use multicore chips nor plan to in the next five years.

[Note that this was just a casual survey by Freescale and Virtutech. Likely they just walked around the show floor and asked folks what they thought. VDC runs a good shop and employs strong survey methodologies with secondary sources.]

The discussion got started with this quote from Donald Knuth that was shared in a recent article:

I might as well flame a bit about my personal unhappiness with the current trend toward multicore architecture. To me, it looks more or less like the hardware designers have run out of ideas, and that they’re trying to pass the blame for the future demise of Moore’s Law to the software writers by giving us machines that work faster only on a few key benchmarks! I won’t be surprised at all if the whole multithreading idea turns out to be a flop, worse than the Itanium approach that was supposed to be so terrific until it turned out that the wished-for compilers were basically impossible to write.

Let me put it this way: During the past 50 years, I’ve written well over a thousand programs, many of which have substantial size. I can’t think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading. Surely, for example, multiple processors are no help to TeX.

I know that important applications for parallelism exist… rendering graphics, breaking codes, scanning images, simulating physical and biological processes, etc. But all these applications require dedicated code and special-purpose techniques, which will need to be changed substantially every few years.

The office debate that followed was interesting. It boiled down to:

• There well could be many uses for multicore processors that don’t have anything direct to do with the implementation of multicore aware algorithms. Pinning a critical algorithm to a dedicated processor is one example. More efficiently implementing virtualization for its many use cases is another. All of these are in effect using multicore inefficiently from an algorithm standpoint but delivering benefit nevertheless.
• Multicore transition is a marathon, not a sprint.
• Many of the edge cases Knuth highlights as suitable for multicore are actually typical in the world of embedded devices.

Heterogeneous multicore processors are hotrods… but application developers need huge motivation or lots of help to use them.

I first heard wiffs of this in discussions with a company that makes consumer products based on a popular ARM+DSP architecture. While we certainly are aware of companies that will employ DSP developers to exploit this heterogeneous multicore chip this particular company didn’t want to be in that business. They would rather have the DSP code pre-cooked and provided to them by the vendor or ISV partners.

You’ve seen this in graphics processors for years. Most everyone has a heterogeneous multicore computer on their desk now. The graphics processors have a slew of processors that can be used, in some cases, for running algorithms other than graphics processing. Specialty companies even exist to help you exploit these capabilities.

Exploiting the GPU is still, however, a niche activity for engineers.

Intel’s upcoming Larabee graphics processors will be an interesting test. Larabee is described as a multicore x86 based GPU. Will introducing a familiar instruction set remove a barrier to running non-graphics algorithms?

This is a broad market survey.

VDC typically surveys a wide swath of developers who are building all sorts of applications. If you segmented the market and isolated developers who are likely to have applications that would benefit from multicore you’d likely have a different view.

Wrap up

I don’t share’s Knuth’s opinion that multicore could end up being Itanium like in any way. There is a demonstrated track record of successful multicore applications in the embedded software domain.

I do wonder if in the broad embedded systems market if multicore adoption will lag or the multicore architecture will be used inefficiently to serve other important use cases facing designers.

ShareThis

If you missed the webinar this week you can view the slides here or the recorded version here.

These are the questions provided by the audience that I thought I could handle. Kaitlin Murphy from Intel is working on hers and we should get them together here shortly.

Q: Hi, you discussed the cpu-freq and dynamic frequency and power scaling? What about the control of idle sleep modes?

The questioner went on to correctly identified the cpu-idle subsystem as being responsible for putting the processor into various sleep states (C-states).

Q: How do make the application itself “power aware”?

As discussed in the call there are a few techniques that can be considered:

1. The application could itself serve as a userspace governor for voltage and frequency scaling.
2. The application can use the provided /proc and /sys interfaces to monitor the power status of the system including the AC & battery states, the frequency and voltage scaling behavior of the system. Very intelligent applications might use this data to defer power hungry tasks until later or even limit certain usage modes.
3. One should take care with all applications to ensure that they are not unnecessarily keeping power hungry devices open (which would prevent them from being powered down) or causing wakeups that are not needed. Dave Jones (RH) made a presentation at the Ottawa Linux Symposium 2006 about unneeded wakeups and other topics titled “Why Userspace Sucks” that is worth reading.

Q: Has this power management work been accepted by the open source community and the community will maintain it with kernel evolving?

All of the features I discussed are evolving in a public multi-party fashion in the mainline kernel tree and other contributing subsystem trees. Many companies play a role as do unaffiliated individuals. Notable contributors include Len Brown (Intel, ACPI), Ingo Molnar (RH, RT and everything) and Thomas Gleixner (Linutronix, dynticks, clockevents, etc.), Venki Pallipadi (Intel, deferrable timers). I know there are others but I’m getting tired of Googling. No offense intended at all.

What we’ve discovered over the years is that having the supporting technologies is important but then actually tuning them to work on a specific hardware, kernel, userspace, and application workload is essential.

You can’t download a kernel.org tree and expect power nirvana… but power management in the community has evolved and advanced significantly thanks to contributions from many.

Q: I guess CPUFreq driver should interact with clock framework. When and how they interact with each other?

Yes… you certainly want your timers to go off at the right time and your clocks to advance at the proper rate.

Quick grep study shows that the cpufreq_register_notifier() function is used in most architecture specific timekeeping code in order to register a notifier that updates the loops_per_jiffy. This is reinforced by the file Documentation/cpufreq/core.txt from the kernel source:

The CPUFreq core code is located in drivers/cpufreq/cpufreq.c. This
cpufreq code offers a standardized interface for the CPUFreq
architecture drivers (those pieces of code that do actual
frequency transitions), as well as to “notifiers”. These are device
drivers or other part of the kernel that need to be informed of
policy changes (ex. thermal modules like ACPI) or of all
frequency changes (ex. timing code) or even need to force certain
speed limits (like LCD drivers on ARM architecture). Additionally, the
kernel “constant” loops_per_jiffy is updated on frequency changes
here.

Q: on this slide you have APCI..is that a typo or a new Acronym?

Typo.

Q: What is the maximum amount of time a deferred timer may be deferred?

A: There is no maximal value defined or allowed to be defined. The timer will defer until a non-deferrable event such as another timer awakes the system. For more information this LWN.net article may be useful.

Q: Would the Atom processor be useful to run a real-time OS like MontaVista, and could sleeping between tasks be implemented in the real-time OS?

The question is a wonderful reminder that not all real time tasks are “fast”. There are a great number of RT applications which don’t require non-stop and rapid response to events. Some of these “slow” RT applications could benefit from utilizing power management capabilities in-between events.

Yes, the operating system could put the system to sleep in between events, even RT events. The responsiveness of the platform to the next RT event will be influenced by the speed that the platform can emerge from the sleep state. For example: If the hardware platform can emerge from sleep within 50ms (a totally made up number) and your event only has to be responded to within 100ms you might be fine. If your even requires a 1ms response time then you may have a problem.

Very deep sleep states (like the C6 state mention by Kaitlin on the Intel Atom processor) that flush caches may introduce secondary performance impacts. The caches will have to be refilled from main memory and this would introduce additional overhead as the system emerges from sleep.

If the performance penalty of emerging from sleep is unacceptable you could utilize the other power saving features (frequency and voltage scaling, I/O device shut-down, etc.) and avoid using sleep states.

Q: Could you recommend a development system to play with MontaVista and the Intel Atom processor?

As mentioned earlier we support the Intel® Atom™ Z500 Processor Board with our Professional Edition 5.0 product. You can find our full list of supported hardware here.

---

I forgot to include some image credits in my presentation. Here they are:Public Domain
http://en.wikipedia.org/wiki/Image:9700_HMS.PNG

CC Attribution 3.0 Unported
http://staticfree.info/projects/24h_clock/

CC Attribution-Share Alike 2.0 Generic
http://flickr.com/photos/jojakeman/2433418929/
http://flickr.com/photos/nirmalthacker/2187149611/
http://flickr.com/photos/yahtzeen/37102029/

ShareThis