Hi all,

Yes, the Atmel | Linux newsletter for July 2015 is ready!

This time we've tried another diffusion technique by using our Linux4SAM.org website storing the bulk of the newsletter while just displaying the titles in the email. This way, you are be able to quickly have an overview then pick whatever you like and directly access the information you need. So, please give us feedback about what you prefer and the form that you enjoy the most.

The June 2015 edition is also stored on-line so that you can reference it and share it with your colleagues or your social network: LinuxNewsletter2015June

---

Table of contents:

---

How do we prepare the launch of a future product

There's no doubt about it, something is going on with the Linux4SAM git trees. All the components of a Linux-based solution are being marked with obscure linux4sam_5.0-alphaX tags (AT91Bootstrap as v3.8-alpha3 and U-Boot, the Linux kernel plus meta-atmel Yocto Project layer as linux4sam_5.0-alpha3)...
Well, as we are preparing the launch of a future product, we've anticipated the development on all our components and publishing, then releasing early deliveries in public. Why? simply because we are using Open Source and we follow one of its motto "*release early, release often*".

This strategy allows us to build only one branch of each component without having to maintain synchronization with an hidden repository.
Writing all this new code in public gives us the possibility to post the sources for reviews on each project's mailing-list and benefit from the feedback of experienced community maintainers.
When the new product is released, well, we only have to announce it louder but the code is already there, already discussed and used intensively for several months: this is how we manage to have a Linux4SAM git branch ready on product launch day-1 and the majority of patches already accepted in project's mainlines in parallel.

Yocto Project meta-atmel layer officially listed and moving to "fido"

Refining a Linux distribution suited to your needs is an unavoidable step when building a custom embedded Linux system. Last month, we noticed the progress that were made for Atmel's board support in the buildroot environment. This month, we'd like to tell you more about our activities with the Yocto Project.
For a long time, our Linux4SAM demos are built using Open Embedded recipes and evolved with the different revisions of the Yocto Project and its reference distribution named Poky.
As a well organized project, Yocto defines the notion of layers. These layers define configurations for machines, new ways to build applications (recipes) or overload existing recipes to adapt them to a specific hardware.
Atmel provides its own layer officially listed here meta-atmel:
http://layers.openembedded.org/layerindex/branch/master/layer/meta-atmel/

As you can see, we recently moved to the latest release of this project 1.8 named "fido" and our master branch now points to this revision.
https://github.com/linux4sam/meta-atmel

The latest enhancements for this layer are:

• obviously, all the latests Linux4SAM component versions are handled by this layer (AT91Bootstrap v3.8-alpha3, u-boot-2015.01-at91 and linux-3.18-at91).
• adaptation to newer LCD driver using DRM
• addition of useful components to current demos: devmem2, evtest, benchmark applications and the qtserialport library
• addition of the firmware for out-of-the-box WiFi with Atmel's wilc1000 SD pro modules
• use of tslib for resistive touchscreens and adapt demos for capacitive touchscreens
• use of git trees for QT5 demo applications: application-launcher, atmel-video-player
• use of git trees for the GStreamer hardware video decoder plug-in: gst1-hantro-g1

Try it and you'll be convinced that such a built distribution is worth the compiling time and disk space!

GStreamer plug-in for hardware video decoder published on github

As you certainly know, the venerable at91sam9m10 and the newest sama5d4 SoCs embed an hardware video decoder. This peripheral is managed by two Linux kernel drivers (memalloc.c and vdec_g1.c) and a user-space GStreamer plug-in. This plug-in uses a binary library to access some IP features (libdecx170*.a) but its core is available as source code and is now published on github:
https://github.com/linux4sam/gst1-hantro-g1

This move from an archive distribution model to a dedicated public git tree will certainly ease its maintenance and open the development process to more interested people.

This plug-in is now used by the Yocto Project's meta-atmel layer. So everything is in sync to allow a better experience with this peripheral.

Graphical libraries on sama5d3: use case with EFL

Emtrion is one of our partners building embedded solutions around our products. Their Single Board Computer the SBC-SAMA5D36 has recently been used in one of their blog post talking about Enlightenment Foundation Libraries also know as EFL.
In our Linux4SAM demos, we tend to use the QT libraries as this environment, used for graphical applications (but not only), is now greatly appreciated by embedded developers.
This situation mustn't hide the wide diversity of graphical environments available for embedded Linux and EFL with all it's components is a nice alternative, as demonstrated by this detailed article:
http://blog.emtrion.com/index.php/enlightenment-foundation-libraries-on-sbc

Upcoming module focusing on low power with sama5d3 and WiFi / BLE

Shiratech is designing a nice little System-On-Module that will focus low power and connectivity with its sama5d3 core LP-DDR2 memory eMMC for storage and a WiFi / BLE module.
The Spark-501 is said to be available this fall:
http://www.shiratech.com/products/spark-501/

Activity on linux-arm-kernel mailing-list + discussion preparing the Kernel Summit

As promised, here is our monthly summary of our activity posting on the Linux ARM kernel mailing-list. This month has been contrasted: on the one hand, we developed new features for the support of a future Atmel MPU. On the other hand, as all this work is mainly located in the /drivers directory, we end up with very few patches related to the core of AT91 to queue for 4.3.
Yes, we are approaching the end of the development period for 4.3 and Alexandre and I are preparing our "Pull requests" that we need to send to the arm-soc maintainers. Unlike the past three or four previous development cycles, this one is very calm as all the cleanup have been made and code has been moved to the proper /drivers locations, integrated with the proper kernel subsystem: Think about the Common Clock Framework, the power/reset drivers or the clocksource infrastructure to name a few.

Finally, here are some items to highlight :

• enhancement or creation of several drivers for upcoming product: watchdog by Wenyou, reset & shutdown controller
• discussions ongoing and agreement nearly reached for the QSPI driver by Cyrille
• the Flexcom is a little wrapper around a SPI a USART and a I2C: so the Multi-Function-Device (MFD) subsystem was the good candidate for this hardware: we are currently discussing details of the Device Tree binding
• the upcoming product will provide some new clocks: so new Common Clock Framework (CCF) drivers are being developed

Oh, and if you are interested by the Linux core topic and about what will happen in the next Linux Kernel Summit to be held in Seoul this fall, you can follow the technical and in-depth discussion by the main kernel developers on the ksummit mailing-list:
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2015-July/thread.html

The main topics for the moment are:

• dev / maintainer workflow security
• Recruitment (Reviewers, Testers, Maintainers, Hobbyists)
• Issues with stable process
• Testing and documentation
• System-wide Power Management (what a kernel summit would be without a Power Management track?
• Mainline kernel on a cellphone

Other technical discussions popped up about Firmware signing to increase security or IRQ affinity. If you want to see the future of Linux, have a look at what core developers are preparing...

We hope that you enjoyed this newsletter. Bye,

---

Nicolas Ferre and the whole OS team