We have come a long way since the first Li-f-e live media based on openSUSE was created, the current release is based on openSUSE Leap 42.1. Deployments by Indonesia’s education system is a shining example of openSUSE Education project’s accomplishment.

The openSUSE project has stopped producing live medias for Leap and also live-installer is dropped from live medias created for the Tumbleweed distribution. As Li-f-e is primarily a live distribution we would not be able to create any more medias without live-installer. So unless this situation changes we may not have Li-f-e based on Leap 42.2.

In the meantime I’ve had a look at Ubuntu to create Li-f-e based on the latest LTS release of Ubuntu-Mate, check it out here. Software selection available is kept identical to the Li-f-e based on openSUSE, however there is always a room for improvement, suggestions to enhance it are always welcome.

As part of my work on rootless containers, I found that many tools try to drop privileges. This makes those tools break inside rootless containers, so I spent a week or two working on a tool that allows users to shim out all of the "drop privileges" syscalls. Here is documented the pain that I went through while figuring out how ptrace(2) is meant to work.

The second day was for me the one with best talks and workshops. First, I attended the keynote from Frank Karlitschek, founder of Nextcloud. After that, I went to Ancor González Sosa workshop, openSUSE wants you: the software portal. I downloaded the software-o-o project and started seeing how it works. At lunch time I had some strange food.

Then, I attended the Teaching opensource talk, by Craig Gardner. It was mainly focused on how to turn students into contributors, but Craig also talked about the benefits to schools, the fact that most big companies loves open source and why it is important to teach open source. I really recommend you to see the slides he used, specially if you do not agree that teaching open source in schools and universities is that important, as I think the slides will make that you change your opinion.You can find them here: Teaching open source 2016.

After that, it was Henne Vogelsang talk about openSUSE 101, the openSUSE mentoring program which has been used in GSoC. I found the slides and the presentation really fun. I would like you to see it but unfortunately there is no video of the talk. Although you can see the video that he played when talking about the fact that variety is needed in open source. I had seen it before Henne talk but it was still funny:

https://www.youtube.com/watch?v=vXeF6Uot8pk

Lastly, I went to the end of the Ruby on Rails 101 workshop and to the 20.000 Leagues Under SUSE Studio workshop, both of them by Christian Bruckmayer. I liked a lot the slides of the second workshop which you can find here: 20.000 Leagues Under SUSE Studio

Cellar tour

In the evening I went to the cellar tour, which lasted around 75 minutes (the same of the city tour more or less) and where I also learnt a lot of things. It is astonishing that Beer used to be healthier than water in Nuremberg hahaha.

After the cellar tour we went to eat Schnitzel, a huge steak with a strange cover. As you should have already noticed in my previous post all dishes are tooo big in Germany. But not only dishes, drinks and even ketchup packets are too big. The German ketchup packet has 20ml, while in Spain it usually has only 10g. That means that you have to open around 4 ketchup packet in Spain to get the amount of ketchup that you get in Germany in only one packet.  

 

And that is most of what I did the second day of the conference. I have a lot of nice pictures with Geeko of the third day which I will include in the next post.  

 

After taking two planes I arrived to Nuremberg on Tuesday 21 to attend openSUSE Conference 2016, which took place from June 22 to June 26.

 

Pre-conference party

That night it was the pre-conference party, where I had the chance to try openSUSE beer and to meet a lot of people. I met some openSUSE workers from Canarias, such as Moises, entertainment manager Senior Rails Web Developer at SUSE, the GSoC students Joaquín and Rishabh, my mentor Chris and some others that I won’t mention to avoid doing the post too long.

 

First day of the conference – Wednesday 22

In the morning I helped in the registration desk. After that I attended the last part of the SaltStack is more than just configuration management talk, by Thomas Hatch, and the Introduction to the Linux Block I/O Layer and Hawk 2.0 and Beyond talks, by Johannes Thumshin and Kristoffer Grönlund respectively. I found interesting the Hawk talk. You can see the video of these talks and some other in the openSUSE youtube channel. I also met Matheus, the last GSoC student that was coming to the conference.

 

After that, I had a pulled pork bbq sandwich for lunch taken from Ribwich Food Truck. Ñaam.

In the afternoon, I attended the The type C connector and USB 3.1 talk, by Oliver Neukum, while being in charge of giving the people who wanted to ask questions the microphone. It is funny because I appear in the last part of video of this talk hahaha.

Lastly, I went to the How to Contribute to an Open Source Project workshop, by Lasse Schuirmann. I found the workshop really useful: I learnt some things about Python data structures and git that I didn’t know, I learnt what Coala is and I made my first contribution to the coala-bears project. What Lasse told us about Coala in the workshop was similar to what he said in his Static Code Analysis for All Languages – coala! talk. I couldn’t go to that talk, but I’ve seen the video and I recommend you to see it. I think that Lasse is a really good speaker and the talk lasts only 15 minutes. You can find it here: Lasse Schuirmann: Static Code Analysis for All Languages – coala!

 

City tour

On Wednesday 22 evening I also went to the city tour organized for the conference. The tour lasted around 75 minutes and I learnt many things. I had already seen pictures of Nuremberg in Google, but I was really impressed by how beautiful the city is! Here there are some of the picture I took:

Click to view slideshow.

And my favourite one, which I prefer to include separately:

After that, we went to have dinner to a Thai restaurant where I ate a delicious duck and to the Nuremberg “beach”.

 

That’s all from now, I’ll continue writing about the conference in the next post.  

 

The Taste of Avocado

Mr. Viktor Avocado

Viktor and Zdenek have been trying the Avocado Framework to be used for our automatic regression tests instead of Autotest. They were quite successful in breaking the stuff first to actually succeed at the end. They have also subscribed for giving the presentation about the project on Friday.

Avocado provides the framework for running tests written in any programming language, but it additionally provides useful API for tests written in Python. For those, who want to try Avocado themselves, there is an RPM built for openSUSE at our build service.

Windows 10 in openQA

Happy Jozef and his Windows

Jozef's project was to install and use Windows 10 in openQA because we, of course, support dual-boot openSUSE/Windows scenario and want to make sure that we don't break it in the future.

Jozef was mainly struggling with the fact that openQA (KVM) uses SCSI disks, but Windows did not support them by default. There are several ways how to overcome this issue. Some solutions can be found either here or there.

At the end, Jozef has succeeded and this new automated regression test will be added to our openQA - a great continuous integration framework. Well done!

Jenkins Dashboard - Putting The Pieces Together

Tomas doing a small talk with Slenkins

Tomas worked on a Dashboard for showing the current state of our Jenkins/Slenkins instance used for running package regression tests. The UI should be similar to what we are getting from openQA nowadays.

The project itself already has a working prototype and uses as much as possible from other libraries and frameworks (Pharo, Seaside, Bootstrap) and also uses the Jenkins XML API for getting the data to show.

Gordon: Automagic Testsuite for Crowbar

Evgeny making Gordon green

What does not need to be done manually, should not be done manually. If you have a set of tests that you always need to run before you release a maintenance update, automate it. This saves you time for the cool stuff.

Evgeny's HackWeek project is to automate various crowbar tests using Splinter - a powerful, easy-to-use library, written in Python, for testing web-based applications. There is an animation demonstrating how it flies in action at the GitHub project page.

The plan is to integrate this project into the official QA Maintenance testsuite and speed-up the process of releasing updates while still being sure that everything works as expected.

Deploying Testing HA Cluster in VMs Easily

Screenshot from the video

Another great example of saving a lot of time is Antoine's project for deploying a testing HA cluster using several virtual machines. All is written in Bash and it's easy to understand thanks to a well-commented code and help.

You can find an extensive documentation and explanation at the respective GitHub project. Including three YouTube videos [video #1], [video #2], [video #3] showing the beast in action!

If you ever wanted to explore how HA works, this is the right project to start with. Antoine is looking for your feedback.

YaST Code Closer to the Ruby World

Yast team brainstorming

There is a long-running YaST project, driven by Imobach, that should bring YaST code (which is written in Ruby) closer to expectations and conventions of any common Ruby project. There are several reasons for that. For instance, we'd like to enable Yast classes to be packaged as Ruby Gems and to lower the entry barrier for any Ruby developer in general. So, files should be in directories where you expect them and their names and class names should match.

Fragments of the project output

As there is a HackWeek at SUSE and Imo, Knut and Ancor were visiting the Prague office, we took the chance to discuss this in person and we have a plan how this should look like in the future. During our discussion, we have found out that we might need yet another course in handwriting (after leaving the primary school years ago).

Let's have some beer now :)

Now it's time to document our plan and start working on the proof of concept, but the ship has already started moving to the right direction. This will be particularly challenging with the number of Yast libraries we currently maintain.

Static Ruby Code Analysis with ruby-lint

Martin works on an interesting project that should help Yast to identify unused and misused variables and methods (and more). See an example of badly-used code and the output of ruby-lint in the project itself.

Orca: an Intelligent Ceph Testing

SUSE has already released a version 3 of SUSE Enterprise Storage based on Ceph which is highly-scalable, fault-tolerant and self-healing by definition, but we'd like to enhance it even more by finding the bottlenecks, by being as mean and cruel as possible to find it's limits. Then we'd like to focus on what we will find and make it even more robust in the future.

This all needs an intelligent creature (or even a herd of creatures attacking together and having fun of that). A creature that is able to inspect, learn and attack and also learn from its failure. All this (and even more) should be the result of five brave developers lead by Lars working on project Orca: Hunting Cephalopods for Fun and Dinner.

The ESP8266 lacks any hardware support for PWM. Any ATtiny, PIC or any ARM Cortex M0 based SoC fares better in this regard, although the smallest SoCs may have only one or two channels.

As an alternative to hardware PWM it is possible to do PWM purely in software, typically assisted by interrupts from a hardware counter. For the ESP8266 a software PWM implementation is available in the SDK provided by Espressif, but it comes with several strings attached:

1. It has a quite awkward API, the documentation lacks several important points open
2. As any interrupt based implementation it is susceptible for glitches
3. The duty cycle is limited to 90% maximum

The missing manual parts

The API has four important functions to control the PWM, as follows:

void pwm_set_duty(uint32 duty, uint8 channel)

Set the duty for a logical channel. One duty unit corresponds to 40ns. The maximum should be period / 40ns, but due to the implementation there is a fixed dead time of 100μs which limits the maximum duty to 90% when using a period of 1ms (i.e. a frequency of 1kHz).

void pwm_set_period(uint32 period)
Set the PWM period to period microseconds.

void pwm_start(void)
Needs to be called before any pwm_set_duty, pwm_set_period calls take any effect. Does some preparatory work needed for the interupts handler to do its job of toggling the GPIOs.

void pwm_init(uint32 period, uint32 *duty,
uint32 pwm_channel_num, uint32 (*pin_info_list)[3])

duty points to an array of duty cycles, the number of array elements depends on the number of used channels. From the documentation it is not obvious if this is only needed for initial settings, if this is also accessed after the pwm_init call (e.g. ownership of the array is transfered) and if is save to pass NULL here.

pin_info_list points to an array of arrays. It better had been declared as an array of structs, each struct storing the configuration of a GPIO pin. As is, each 3-tuple stores:

1. the name of the MUX configuration register as documented in the GPIO chapter of the SDK, see the PIN_FUNC_SELECT macro
2. the name of the MUX setting, see GPIO SDK documentation
3. the number of the GPIO from 0 to 15

One 3-tuple is needed for each PWM channel/GPIO pin. Ownership transfer is not documented.

The „90% maximum duty“ limitation

The maximum duty limit is an implementation artifact. To understand where this limitation is coming from, it is necessary how the the software PWM works. The following two scope traces both show the same signals, 2 PWM channels with a duty of 1467 (58.7μs) and 399 counts (15.9μs), with a specified period of 1000μs, but different timebases (500μs/div resp. 20μs/div).

As can be seen, in each period typically two pulses are generated, a short and a long one. To calculate the length of the pulses, divide the duty count by (400/3). The integral part is the length of the longer pulse in units of 5.32μs, the remainder is the length of the short pulse. For the given traces:

PWM channel 1
long:  [1467 × 3 / 400] × 5.32μs = 11 × 5.32μs = 58.52μs
short: (1467 – 11 × 400 / 3) × 40ns = (1467 – 1466) × 40ns = 40ns

PWM channel 2
long:  [399 × 3 / 400] × 5.32μs = 2 × 5.32μs = 10.64μs
short: (399 – 2 × 400 / 3) × 40ns = (399 – 266) × 40ns = 5.32μs

From the first trace one can also see that the long pulses run in parallel during the set period of 1000μs, but the short pulses are generated in a fixed size timeslot of 100μs sequentially, i.e. the actual period is 1100μs. Thus the maximum duty cycle is 1000μs (long pulse) + 5.32μs (short pulse) / 1100μs = 91.4%.

For higher PWM frequencies this can be a real problem. When the period is set to 100μs, e.g. 10kHz, the PWM actually runs with 5kHz and the duty cycle is limited to ~50% (Channel 1):

A PWM from scratch

For the reasons stated above, I thought about a new PWM implementation. Requirements were:

1. Opensource, to be hackable
2. Usable for 1 to 8 PWM channels
3. Full 0% to 100% duty cycle
4. Drop-in replacement for SDK PWM

First thing I learned during the implementation is the quite high interrupt overhead of the NON-OS SDK (same may apply for the xtensa FreeRTOS port) [1]. The interrupt handler which has to be provided to the SDK interrupt attach function is just a normal function (ABI wise), while the lowlevel interupt handler doing the housekeeping, like register saving and dispatching, is hidden somewhere in the ROM. This housekeeping adds about 2.5μs of overhead, which limits the maximum rate for doing timer based interrupts to about 3μs.

So to get a resolution better than 3μs at least part of the GPIO pin toggling has to done with busy loops inbetween. While busy waiting is normally frowned upon, in this case is no worse than interrupts – either way the CPU is busy, either by spinning or by completing the interrupt handler.

Another limiting factor is the access time of the ESP8266 peripheral registers. As others have noted, a write to these registers take about 6 CPU cycles, i.e. 75ns.

Design choices

1. Mixed interrupt/busy loop concept with single pulse per period
2. Base interval of 200ns
3. Phase mirroring for duty cycles above 50%

The third point is the most important one, the one that needs some explanation. A software driven PWM typically enables all active channels at the beginning of the period (t=0) and then one after the other switches the channels off again, depending on the respective pulse width.

For channels with a duty cycle above 50%, these can also be interpreted as having a duty cycle of 100% – duty, but an inverted
polarity. This interpretation allows to remove any switching from the second half of the period, and in turn enables using this timeframe for a more fine granular pulse width generation.

So, how does it look like? Here are 4 PWM chanels, 25kHz PWM period, duty cycle of 45%, 50%, 90% and 2.5% from top to bottom:

Implementation details

The important parts are the actual interrupt handler and the setup routine for the PWM control. Both deal with an array of sequential PWM phases. Each phase switches some GPIOs on and off, and then delays execution until the next phase starts:

struct pwm_phase {
int32_t ticks;
uint16_t on_mask;
uint16_t off_mask;
}

For the 4 channel PWM above, there are 5 phases.

1.  T= 0us: Enable channel 1, disable channel 3 and 4
2.  T= 4us: Enable channel 3
3.  T=18us: Disable channel 1 and 2
4.  T=38us: Enable channel 2
5.  T=39us: Enable channel 4

After the first three phases, the timer interrupt is set up for the delay, the last two phases are done with busy waiting inbetween.

The heavy lifting is done in the setup routine called by pwm_start. It sorts channels by duty cycle, aligns PWM pulses to satisfy interrupt rate constraints (as done for channel 1 and 2 here) and transforms the absolut switching times to delays.

The interrupt handler is designed to be as lightweight as possible – it has to be able to switch arbitrary GPIOs every 200ns. To reach this goal, it uses several tricks to minimize instruction count:

1. Use a struct for related data. This allows the compiler to use relative load with a single base offset for multiple variables.
2. Use a struct for the GPIO and timer registers. The SDK defines these as independent memory offsets, again combining these into a struct allows to use relative stores.
3. Do not use the SDK GPIO manipulation macros. These insert a „memw“ (memory wait) instruction, costing two extra cycles (thats 25 precious nanoseconds out of 200 available).

But enough words, code is available here:

https://github.com/StefanBruens/ESP8266_new_pwm

Last Friday, at openSUSE Conference 2016, I was giving a talk together with Christian Schneemann about KIWI and OBS (the events.opensuse.org software is not able to manage "two speakers for one talk", this is why I am not listed in the schedule).

The slides from that talk are now available from the B1-Systems website.

There has been a lot of work within the runC community recently to get proper "rootless containers". I've been working on this for a couple of months now, and it looks like it's ready. This will be the topic of my talk at ContainerCon Japan 2016.