Tag Archives: ELC-E 2015

Creating Open Hardware Tools – David Anders (prpplague), Intel

See http://elinux.org/Open_Tools

In science, open tools are created fairly often, since for experiments you often need specialised tools, and scientists share it with each other. E.g. Bunsen burner – Bunsen distributed it under an essentially open source license.
All commercial debugging tools that exist have limitations, e.g. limited OS support, price, features. Since it’s commercial, you can’t change it.
One of the first open source HW projects was LART. To be able to program it, they needed a JTAG dongle, so they also developed a parallel port JTAG dongle: Holly Gates.
Nowadays the Maker/Hacker community is booming. These people want to have a logic analyser, scope, and other tools, so there is a drive to create less expensive ones and where features can be added.
Logic Analysers: Open Workbench Logic Sniffer: FPGA based. Bus Pirate: PIC based – very limited but very cheap ($10). Saleae Logic: based on Cypress FX2 reference design. Also many Arduino based designs.
Oscilloscopes: handhelds, which are repurposed mp3 players – mostly not open source but there are a few that are (or at least where the schematics and firmware are released). Arduino-based. Kits for building your own oscilloscope.
Custom solutions, specific for the use case. E.g. TI TFP410: converts DVI to RGB. You can use this to create a DVI debug board. In general, bridge chips are a good way to create debug boards.
Shared tools. E.g. flashrom is intended to flash e.g. BIOS, led to creating little pieces of hardware to assist doing that. These have reference schematics, so if it doesn’t match your design you can use it. Similar for OpenOCD, sigrok.
To create your own simple hardware: kicad (UI is clunky but will improve now it’s the primary development tool for CERN). Eagle CAD (proprietary but free version with license limitations). Altium but David hasn’t tried it because he’s not fond of cloud applications. Its only real limitation is that you are only allowed to work on open hardware. Note that each package has their own format (though there’s an open interchange format but don’t rely on it; there are also conversion tools but they’re dodgy), but the way that kicad and Eagle CAD is that they have fairly open formats. More expensive packages make it really difficult to do version control.
Once you create something, be sure to license it, otherwise it can’t be shared! Note that you can still make money off it even if it’s open source.
Still some serious challenges in the open hardware tools.
Displays: simple LED, 7 segment, LCD: it becomes very difficult to debug. Therefore, you will need more complex boards for debugging. This leads to heavier requirements on the design software: 4+ layers, differential lines (PCIe, SATA, HDMI), matched impedance, QFN and BGA packages (difficult to solder manually).
For e.g. differential pairs, FPGA could be a solution, but the libraries to do the decoding are closed, restrictively licensed, including DRM restrictions.
If you can’t do soldering yourself, you can go to companies that take care of PCB + soldering, e.g. microfab.


Developers Care About the License: Using SPDX to Describe License Information – Jilayne Lovejoy, ARM

Jilayne previously worked for a company that did audit services, where she learned about all the ways that developers can not provide license information in their code. If they would do that better, then some of these tools would not be necessary.
What developers really care about is sharing the code. So how do we go about that? Given that it is by default protected by copyright? By giving permission. If you don’t do that (if you don’t specify a license), it’s not open source.
Github is notorious for not having licenses. When gh added a way to create a license file at repo creation time, the % of projects with license jumped from 10% to 20%. Repos with a higher rating have a higher % of licences.
How do we specify the license? LICENSE.txt. But the problem is that as the package travels downstream (e.g. binaries), it may get lost. In addition, there can be many different components collected together so the license may be hard to find. When someone takes a few files out of the package, the package license also becomes useful. So it’s important to put a license notice in every file.
SPDX: human and machine readable format, focuses on capturing facts, not interpretation. It’s a pretty large standard, 72 different use cases were considered for defining it.
So how to use it as a developer? First of all, use a short identifier from the SPDX License List. This includes guidelines to identify if the license text matches. Put this identifier in every source file. E.g. SPDX-License-Identifier: xxxx, either with or without the actual short license reference. Of course, also include the full license text in the project. Cfr. poco project.
What if more than one license applies? There is a license expression syntax, see appendix IV in the license list. Operators: AND, OR, WITH (= exceptions), + (= or later).
Second way to express license: provide an SPDX document. The SPDX file contains file checksums, so you need a tool to generate it. FOSSology (install or use unomaha instance), WindRiver (submit through website), Yocto generates during build, Debian generates during build, Maven plugin generates during build, Eclipse plugin (under development), DoSOCS (stores info in a database), and more.
What SPDX by itself doesn’t solve is getting good data, i.e. do you trust the SPDX file you get from someone else?
If not all files are really used to generate the binary, SPDX does allow you to express dependencies between files (i.e., the binary and the corresponding source) and use this to interpret what the license of the binary is.

Portable Linux Lab: A Novel Approach to Teaching Programming in Schools – Emma Foley & Laura Reddy, Intel

When Emma was in secondary school, one of her teachers decided he was going to teach programming, even though they hardly had a computer – this is how she got into technology.
There is a lack of STEM (science, tech, engineering, math) professionals, there is not much computing done in schools, tech is not very well known and stereotyped, and there’s a lack of diversity.
GIFT-ED (Firls influenced for technology in education) program is a 8-week mentoring initiative for 14-year old female students. Goals is to make a carreer in STEM something normal. Why is it not considered normal now? Girls think it’s not interesting, that they wouldn’t be good at it, and that the people in it are not very nice. This program was a big success. However, it wasn’t really scalable. One problem was that the school computer labs were very restricted. It also wasn’t easy to continue independently, because it’s difficult to get started at home (they partly achieved that by teaching HTML/Javascript which they could continue at home). So maybe better to use Linux instead of windows, with a live USB; you also have a lot more things you can tackle that way: shell, python, and even compiled languages (HTML doesn’t teach you that many computer skills). However, it is still staring at a screen and not real-life. Hence Portable Linux Lab:
Portable Linux Lab is a Galileo or Edison with a breadboard with LEDs and buttons, so something real is happening which keeps the motivation going. This also gives more opportunities for problem solving, because things can go wrong in the HW as well as SW. And it allows you to teach about electronics with the same thing. And it’s portable. And it gives them Linux experience, which will give them more confidence.
At earlier age, scratch or graphical programming in Arduino is probably better (spelling is an issue…).

Balancing Power and Performance in the Linux kernel – Kristen Accardi, Intel

Different types of power management.

Simple on/off, but when off you can’t do anything. Suspended and runtime idle are inbetween states that still don’t allow you to do any work but that allow you to resume more quickly. Runtime idle is opportunistic, i.e. automatic. Both for d-states (devices) and c-states (CPU). Suspend is userspace initiated. User tasks are frozen, devices forced into idle. S-state (system state). Could be just CPU idle state as well, but since tasks are frozen, you get less wakeups.

Active power management will reduce power consumption without turning off, i.e. you continue working. = DVFS = P-states, governed by cpufreq. Also device active power management, e.g. PCIe ASPM. GPU is completely divorced from the rest of the system.
P-states != frequency (also voltage); P-states != power (also temp governs power, so we don’t really control power).
How to choose the right p-state: governor. Ultimately a user decision. intel_pstate driver is also a governor with just powersave and performance; acpi_cpufreq driver also works on x86 and has descrite governor so more governor points.
Race to idle: just stay in performance state, do things as quickly as possible, and rely on runtime idle to save power. This only works if runtime idle indeed consumes significantly less.
Powersave attempts to balance performance with energy saving. It looks at CPU utilization (= load at this specific p-state, will probably go down when going to a higher p-state) and capacity (= maximum performance in highest p-state) to determine whether to increase or decrease p-state.

Intel p-states: depending on the number of cores that are active, the power budget is redistributed over the active cores so they can use it to increase the maximum allowed frequency (= “Turbo mode”). Under the lowest frequency, there is still a “Thermal zone” where your CPU will be pushed to exceptionally low frequencies when it’s overheating. Recent (Haswell) processors have an integrated voltage regulator so each core can get a separate voltage (otherwise changing frequencies differently for different cores have multiple impact).
Hardware coordination of p-states: OS asks for a frequency, but the hardware will decide itself between all the cores which one will be selected. The OS should therefore check afterwards with the hardware what the real frequency is. intel_pstate does this, but acpi_cpufreq just reports the (wrong) requested frequency.
Looking at capacity and utilization isn’t always the right metric, e.g. when waiting for something a higher p-state will just wait faster. Also the sampling rate is a limiting factor, you may miss interesting events. It’s also not always clear if scaling is worth it. There’s a big risk of jitter when the CPU is interacting with another element (e.g. the GPU) and intermittently waiting: when it goes back to having work to do, it will take a long time to go back to high p-state. Hardware support can solve these issues, because it can sample at high rate and it can look at GPU and PCI transactions. = Intel Speed Shift Technology = HWP. You get the highest and lowest frequency, but also a guaranteed frequency and most efficient frequency. The latter is calculated based on temperature, race-to-idle information, HW counters to evaluate benefit, this gives Pe = most efficient frequency. The OS provides a Pa value = how aggressive it should be. The algorithm operates between Pe and Pa. It’s also possible to actually set the frequency between Pe and Pa from software, but then of course the benefit is largely gone. You can control the minimum and maximum pstate from userspace.

Side track: idle injection. To control thermal issues, it’s not enough to go the the lowest frequency, since that may actually be less energy-efficient. Instead, you should inject idle time so race-to-idle still works.

Making the Most of Dynamic Audio Power Management – Lars-Peter Clausen, Analog Devices

Each component driver describes it hardware as a piece of graph, with special widgets (= nodes) for its inputs and output. A board driver describes how the components are connected.
Each widget has a type, e.g. speaker, amp, …
DAPM (Dynamic Audio Power Management) detects the active data paths on the graph and manager the power states of the widgets on the active paths, and also manages their dependencies (e.g. clocks). It first determines target power state, then power sequencing.
For finding the target power state, three categories of widgets are considered. Endpoint widgets are e.g. PCM device, speaker, micropohone, tone generator: points where data is inserted into the data path or where it comes out. The endpoints are the things that are explicitly activated or deactivated. In addition, endpoints can be marked as disconnected. Pass-through widgets are in-between end points. They are only powered on if they are on an active path between a source and sink endpoint. Some of these have dynamic routing, i.e. the path can change, e.g. a switch can be closed or open (in which case there is no output). Supply widgets are not on the data path, but support it, e.g. a clock. They are only powered up if they are connected to something that is active. To determine power state, the number of connected inputs and outputs (over the whole path) is determined for each widgets. Sources have a fixed 1 #conn_inputs, sinks fixed 1 #conn_outputs. If either #conn_inputs or #conn_outputs is zero, the path is not active (e.g. there’s an open switch on it) and the target power state is off. Finally, the supply widgets are considered: if one of their consumers is powered up, they are powered up as well.
For power sequencing, first a diff is made between the current state and the target state. Then the changes are made in a certain sequence to avoid popping. First, anything that is newly disabled is powered down. Then, any routing changes are executed (this is the point where the minimum number of widgets are powered up so changes will have the minimal number of artefacts). Finally, widgets are powered on. Each widget type has a sequence ID to determine the order in which to power widgets on or off (different ID for on and off). In addition, a driver can assign a sub-sequence ID to specify ordering within the same type (this is only valid for widgets controlled by the same driver). Within the same sub-sequence ID, changes that can be done with a single IO register update are collected together. Note that the IO register manipulations are handled directly by DAPM, i.e. the driver specifies register offset and mask. In most cases, no callback functions are necessary. This makes it possible to optimize register accesses by coalescing, especially important for slow IO like I2C – and it doesn’t have to be redone for all drivers.
Dynamic graph changes are also possible. Adding/removing edges (= routing changes), it’s also possible to just mark an edge as inactive. Builtin support for mixers, muxers, demuxers, which can be “shared” i.e. with single control for multiple widgets (e.g. for stereo). Mixers can auto-mute, i.e. DAPM will switch input off by itself when it’s not on an active path – avoids clicking – and v.v. when powering up. Similar for mux. Enabling/disabling an endpoint e.g. when a jack is not connected. Starting/stopping streams. Hotplug of components is not well supported.
In V4L there is something similar, it would be nice if this could be factored out. Compared to traditional run-time PM, DAPM can handle cyclic dependencies and can handle a number of complexities autonomously (without involving the driver).
It is not possible to disable DAPM, but it’s fairly small. It’s using strings all over the place, removing that would make it even smaller. It could also be converted to an object-oriented approach, right now the widget struct contains info for all widget types.
Is it possible to add more power states than just on or off? Yes, but this should be managed by userspace, they should make sure it’s kept on if it takes too long to warm up.

ELC-E / LinuxCon 2015 (Dublin) Tuesday keynotes

Securing an Open Future – Leigh Honeywell, Slack Technologies
Container Panel – Moderator: Joe”Zonker”Brockmeir, Panelists: Tom Barlow, Sebastien Goasguen, Brandon Philips
Open Source Fueling the Growth of the Internet of Things – Mark Skarpness, Intel
Continue reading

Ten Years of OIN – Keith Bergelt, OIN

OIN was set up to avoid things like the SCO suite in the future. It was created by Redhat, Novell, … . The current rate of adoption is 150 licensees per quarter.

OIN protects, but also enables and influences government.

OIN makes an explicit expression of the idea of cooperation: there is a “system” zone of cooperation and non-agression, and a “Market” zone with competition. It’s a cultural norm rather than just a license.

When joining OIN, core Linux patents should be transferred to OIN but other patents are cross-licensed. In addition it makes defensive publications against future patents.

The only companies that have rejected the OIN commitments are companies that want to reserve the right to sui whin the Linux core OS.