Free Electrons contributes to KernelCI.org

The Linux kernel is well-known for its ability to run on thousands of different hardware platforms. However, it is obviously impossible for the kernel developers to test their changes on all those platforms to check that no regressions are introduced. To address this problem, the KernelCI.org project was started: it tests the latest versions of the Linux kernel from various branches on a large number of hardware plaforms and provides a centralized interface to browse the results.

KernelCI.org project

KernelCI.org project

From a physical point of view, KernelCI.org relies on labs containing a number of hardware platforms that can be remotely controlled. Those labs are provided by various organizations or individuals. When a commit in one of the Linux kernel Git branches monitored by KernelCI is detected, numerous kernel configurations are built, tests are sent to all labs and results are collected on the KernelCI.org website. This allows kernel developers and maintainers to detect and fix bugs and regressions before they reach users. As of May, 10th 2016, KernelCI stats show a pool of 185 different boards and around 1900 daily boots.

Free Electrons is a significant contributor to the Linux kernel, especially in the area of ARM hardware platform support. Several of our engineers are maintainers or co-maintainers of ARM platforms (Grégory Clement for Marvell EBU, Maxime Ripard for Allwinner, Alexandre Belloni for Atmel and Antoine Ténart for Annapurna Labs). Therefore, we have a specific interest in participating to an initiative like KernelCI, to make sure that the platforms that we maintain continue to work well, and a number of the platforms we care about were not tested by the KernelCI project.

Over the last few months, we have been building our boards lab in our offices, and we have joined the KernelCI project since April 25th. Our lab currently consists of 15 boards:

  • Atmel SAMA5D2 Xplained
  • Atmel SAMA5D3 Xplained
  • Atmel AT91SAM9X25EK
  • Atmel AT91SAM9X35EK
  • Atmel AT91SAMA5D36EK
  • Atmel AT91SAM9M10G45EK
  • Atmel AT91SAM9261EK
  • BeagleBone Black
  • Beagleboard-xM
  • Marvell Armada XP based Plathome Openblocks AX3
  • Marvell Armada 38x Solidrun ClearFog,
  • Marvell Armada 38x DB-88F6820-GP
  • Allwinner A13 Nextthing Co. C.H.I.P
  • Allwinner A33 Sinlinx SinA33
  • Freescale i.MX6 Boundary Devices Nitrogen6x

We will very soon be adding 4 more boards:

  • Atmel SAMA5D4 Xplained
  • Atmel SAMA5D34EK
  • Marvell Armada 7K 7040-DB (ARM64)
  • Marvell Armada 39x DB

Free Electrons board farm

Three of the boards we have were already tested thanks to other KernelCI labs, but the other sixteen boards were not tested at all. In total, we plan to have about 50 boards in our lab, mainly for the ARM platforms that we maintain in the official Linux kernel. The results of all boots we performed are visible on the KernelCI site. We are proud to be part of this unique effort to perform automated testing and validation of the Linux kernel!

In the coming weeks, we will publish additional articles to present the software and physical architecture of our lab and the program we developed to remotely control boards that are in our lab, so stay tuned!

Posted in News | Tagged , , , , , | Leave a comment

Buildroot training updated to Buildroot 2016.05

Buildroot LogoAlmost exactly one year ago, we announced the availability of our training course on Buildroot. This course received very good feedback, both from our customers, and from the community.

In our effort to continuously improve and update our training materials, we have recently updated our Buildroot training course to Buildroot 2016.05, which was released at the end of May. In addition to adapting our practical labs to use this new Buildroot version, we have also improved the training materials to cover some of the new features that have been added over the last year in Buildroot. The most important changes are:

  • Cover the graph-size functionality, which allows to generate a pie chart of the filesystem size, per package. This is a very nice feature to analyze the size of your root filesystem and see how to reduce it.
  • Improve the description about the local site method and the override source directory functionalities, that are very useful when doing active application/library development in Buildroot, or to package custom application/library code.
  • Add explanations about using genimage to create complete SD card images that are ready to be flashed.
  • Add explanations about the hash file that can be added to packages to verify the integrity of the source code that is downloaded before it gets built.

The updated training materials are available on the training page: agenda (PDF), slides (PDF) and practical labs (PDF).

Contact us if you would like to organize this training session in your company: we are available to deliver it worldwide.

Posted in Technical | Tagged , | Leave a comment

Free seat in Android training session

Student penguinsAt Free Electrons, we owe a lot to the Free Software community, and we’re doing our best to give back as much as we can.

One way of doing that is welcoming community contributors in our public training sessions about embedded Linux, Linux kernel and Android system development organized in France. We’ve done that multiple times in the past, and this allowed us to meet very interesting people (who even had very valuable experience and points of view to share with the other course participants), while of course giving them extra knowledge that they can use for further contributions.

The next session in which we can offer a free seat is about Android system development, and will take place on June 20-23 in Toulouse, France. The session has a value of 1890 EUR (without V.A.T.) and includes lunch and breaks, as well as a free Beaglebone Black board with its 4.3″ LCD touchscreen cape.

This course will teach you how to modify Android to support a new embedded board (assuming that it is already supported by the Linux kernel), and how to build a real system through accessing specific hardware, customizing the filesystem and using debugging techniques.

How to apply?

  • You need to be a student or a contributor to a free software project, which doesn’t have to be related to the embedded field, and even if your contributions are modest.
  • Write to award@free-electrons.com before May. 30 and tell us about your contributions and your interest in the session.
  • Thomas Petazzoni and Michael Opdenacker will review all the proposals and will select the candidate who best stands out in terms of past contributions and/or in potential for further ones after taking the course. Free Electrons reserves the right not to select any candidate if nobody actually makes a sufficiently interesting application.
  • The winner will be notified by June 2, and will have to be ready to travel to Toulouse and stay there the whole 4 days at her/his own expense.

Don’t hesitate to apply to this free seat. In past editions, we didn’t have so many people applying, and therefore you have a real chance to get selected!

Posted in Technical, training | Tagged , , , | 2 Comments

Linux 4.6 released, with Free Electrons contributions

Adelie PenguinThe 4.6 version of the Linux kernel was released last Sunday by Linus Torvalds. As usual, LWN.net had a very nice coverage of this development cycle merge window, highlighting the most significant changes and improvements: part 1, part 2 and part 3. KernelNewbies is now active again, and has a very detailed page about this release.

On a total of 13517 non-merge commits, Free Electrons contributed for this release a total of 107 non-merge commits, a number slightly lower than our past contributions for previous kernel releases. That being said, there are still a few interesting contributions in those 107 patches. We are particular happy to see patches from all our eight engineers in this release, including from Mylène Josserand and Romain Perier, who just joined us mid-March! We also already have 194 patches lined-up for the next 4.7 release.

Here are the highlights of our contributions to the 4.6 release:

  • Atmel ARM processors support
    • Alexandre Belloni and Boris Brezillon contributed a number of patches to improve and cleanup the support for the PMC (Power Management and Clocks) hardware block. As expected, this involved patching both clock drivers and power management code for the Atmel platforms.
  • Annapurna Labs Alpine platforms support
    • As a newly appointed maintainer of the Annapurna Labs ARM/ARM64 Alpine platforms, Antoine Ténart contributed the base support for the ARM64 Alpine v2 platform: base platform support and Device Tree, and an interrupt controller driver to support MSI-X
  • Marvell ARM processors support
    • Grégory Clement added initial support for the Armada 3700, a new Cortex-A53 based ARM64 SoC from Marvell, as well as a first development board using this SoC. So far, the supported features are: UART, USB and SATA (as well as of course timers and interrupts).
    • Thomas Petazzoni added initial support for the Armada 7K/8K, a new Cortex-A72 based ARM64 SoC from Marvell, as well as a first development board using this SoC. So far, UART, I2C, SPI are supported. However, due to the lack of clock drivers, this initial support can’t be booted yet, the clock drivers and additional support is on its way to 4.7.
    • Thomas Petazzoni contributed an interrupt controller driver for the ODMI interrupt controller found in the Armada 7K/8K SoC.
    • Grégory Clement and Thomas Petazzoni did a few improvements to the support of Armada 38x. Thomas added support for the NAND flash used on Armada 370 DB and Armada XP DB.
    • Boris Brezillon contributed a number of fixes to the Marvell CESA driver, which is used to control the cryptographic engine found in most Marvell EBU processors.
    • Thomas Petazzoni contributed improvements to the irq-armada-370-xp interrupt controller driver, to use the new generic MSI infrastructure.
  • Allwinner ARM processors support
    • Maxime Ripard contributed a few improvements to Allwinner clock drivers, and a few other fixes.
  • MTD and NAND flash subsystem
    • As a maintainer of the NAND subsystem, Boris Brezillon did a number of contributions in this area. Most notably, he added support for the randomizer feature to the Allwinner NAND driver as well as related core NAND subsystem changes. This change is needed to support MLC NANDs on Allwinner platforms. He also contributed several patches to continue clean up and improve the NAND subsystem.
    • Thomas Petazzoni fixed an issue in the pxa3xx_nand driver used on Marvell EBU platforms that prevented using some of the ECC configurations (such as 8 bits BCH ECC on 4 KB pages). He also contributed minor improvements to the generic NAND code.
  • Networking subsystem
    • Grégory Clement contributed an extension to the core networking subsystem that allows to take advantage of hardware capable of doing HW-controlled buffer management. This new extension is used by the mvneta network driver, useful for several Marvell EBU platforms. We expect to extend this mechanism further in the future, in order to take advantage of additional hardware capabilities.
  • RTC subsystem
    • As a maintainer of the RTC subsystem, Alexandre Belloni did a number of fixes and improvements in various RTC drivers.
    • Mylène Josserand contributed a few improvements to the abx80x RTC driver.
  • Altera NIOSII support
    • Romain Perier contributed two patches to fix issues in the kernel running on the Altera NIOSII architecture. The first one, covered in a previous blog post, fixed the NIOSII-specific memset() implementation. The other patch fixes a problem in the generic futex code.

In addition, several our of engineers are maintainers of various platforms or subsystems, so they do a lot of work reviewing and merging the contributions from other kernel developers. This effort can be measured by looking at the number of patches on which they Signed-off-by, but for which they are not the author. Here are the number of patches that our engineered Signed-off-by, but for which they were not the author:

  • Alexandre Belloni, as the RTC subsystem maintainer and the Atmel ARM co-maintainer: 91 patches
  • Maxime Ripard, as the Allwinner ARM co-maintainer: 65 patches
  • Grégory Clement, as the Marvell EBU ARM co-maintainer: 45 patches
  • Thomas Petazzoni, simply resubmitting patches from others: 2 patches

Here is the detailed list of our contributions to the 4.6 kernel release:

Posted in Technical | Tagged , | Leave a comment

Linux kernel support for Microcrystal RTCs

micro-crystalThanks to Microcrystal, a Switzerland-based real-time clock vendor, Free-Electrons has contributed support for a number of new I2C and SPI based real-time clocks to the Linux kernel over the last few months. More specifically, we added or improved support for the Microcrystal RV-1805, RV-4162, RV-3029 and RV-3049. In this blog post, we detail the contributions we have done to support those real-time clocks.

RV-1805

The RV-1805 RTC is similar to the Abracon 1805 one, for which a driver already existed in the Linux kernel. Therefore, the support for the RV-1805 RTC was added in the same driver, rtc-abx80x.c. The patch which adds the support of this RTC is already upstream since v4.5 (see Free-Electrons contributions to linux 4.5). In this kernel version, the support of the alarm has also been added. In the 4.6 kernel release, the support for two additional functionalities has been contributed: oscillator selection and handling of oscillator failure.

The oscillator selection functionality allows to select between the two oscillators available in this RTC:

  • The XT oscillator, a more stable, but also more power-hungy oscillator
  • The RC oscillator, a less accurate, but also more power-efficient oscillator

This patch adds the possibility to select which oscillator the RTC should use and also, a way to configure the auto-calibration (auto-calibration is a feature to calibrate the RC oscillator using the digital XT oscillator).

To select the oscillator, a sysfs entry has been added:

cat /sys/class/rtc/rtc0/device/oscillator

To configure and activate the autocalibration, another sysfs entry has been added:

cat /sys/class/rtc/rtc0/device/autocalibration

Here is an example of using RC oscillator and an autocalibration of 512 seconds cycle.

echo rc > /sys/class/rtc/rtc0/device/oscillator
echo 512 > /sys/class/rtc/rtc0/device/autocalibration

The other functionality that was added is handling the Oscillator Failure situation (see this patch). The Oscillator Failure is detected when the XT oscillator generates ticks at less than 8 kHz for more than 32 ms. In this case, the date and time can be wrong so an error is returned when an attempt to read the date from the RTC is made. This Oscillator Failure condition is cleared when a new date/time is set into the RTC.

RV-4162

The RV-4162 RTC is similar to ST M41T80 RTC family, so the existing driver has been used as well. However, as this driver was quite old, eight patches have been contributed to update the driver to newer APIs and to add new functionalities such as oscillator failure and alarm. The patches have already been merged by RTC maintainer Alexandre Belloni and should therefore find their way into the 4.7 Linux kernel release:

See [PATCH 0/8] rtc: m41t80: update and add functionalities for the entire patch series. Thanks to this project, the RV-4162 is now supported in the Linux Kernel and the entire family of I2C-based M41T80 RTCs will benefit from these improvements.

RV-3029 / RV-3049

The RV-3029 RTC driver already existed in the Linux kernel, and the the RV-3049 is the same reference than the RV-3029 but it is an SPI-based interface instead of an I2C one. This is a typical case where the regmap mechanism of the Linux kernel is useful: it allows to abstract the register accesses, regardless of the bus being used to communicate with the hardware. Thanks to this, a single driver can easily handle two devices that are interfaced over different busses, but offering the same register set, which is the case with RV-3029 on I2C and RV-3049 on SPI.

For this driver, some updates were needed to prepare the switch to using the regmap mechanism. Once the driver had been converted to regmap and worked as before, the RV-3049 support has been added. Finally, the alarm functionality has been added and fixed. The corresponding patches have already been merged by the RTC maintainer, and should therefore also be part of Linux 4.7:

Conclusion

It is great to see hardware vendors actively engaged in having support for their hardware in the upstream Linux kernel. This way, their users can immediately use the kernel version of their choice on their platform, without having to mess with outdated out-of-tree drivers. Thanks to Microcrystal for supporting this work!

Do not hesitate to contact us if you would like to see your hardware supported in the official Linux kernel. Read more about our Linux kernel upstreaming services.

Posted in Technical | Leave a comment

How we found that the Linux nios2 memset() implementation had a bug!

NIOS II processorNiosII is a 32-bit RISC embedded processor architecture designed by Altera, for its family of FPGAs: Cyclone III, Cyclone IV, etc. Being a soft-core architecture, by using Altera’s Quartus Prime design software, you can adjust the CPU configuration to your needs and instantiate it into the FPGA. You can customize various parameters like the instruction or the data cache size, enable/disable the MMU, enable/disable an FPU, and so on. And for us embedded Linux engineers, a very interesting aspect is that both the Linux kernel and the U-Boot bootloader, in their official versions, support the NIOS II architecture.

Recently, one of our customers designed a custom NIOS II platform, and we are working on porting the mainline U-Boot bootloader and the mainline Linux kernel to this platform. The U-Boot porting went fine, and quickly allowed us to load and start a Linux kernel. However, the Linux kernel was crashing very early with:

[    0.000000] Linux version 4.5.0-00007-g1717be9-dirty (rperier@archy) (gcc version 4.9.2 (Altera 15.1 Build 185) ) #74 PREEMPT Fri Apr 22 17:43:22 CEST 2016
[    0.000000] bootconsole [early0] enabled
[    0.000000] early_console initialized at 0xe3080000
[    0.000000] BUG: failure at mm/bootmem.c:307/__free()!
[    0.000000] Kernel panic - not syncing: BUG!

This BUG() comes from the __free() function in mm/bootmem.c. The bootmem allocator is a simple page-based allocator used very early in the Linux kernel initialization for the very first allocations, even before the regular buddy page allocator and other allocators such as kmalloc are available. We were slightly surprised to hit a BUG in a generic part of the kernel, and immediately suspected some platform-specific issue, like an invalid load address for our kernel, or invalid link address, or other ideas like this. But we quickly came to the conclusion that everything was looking good on that side, and so we went on to actually understand what this BUG was all about.

The NIOS II memory initialization code in arch/nios2/kernel/setup.c does the following:

bootmap_size = init_bootmem_node(NODE_DATA(0),
                                 min_low_pfn, PFN_DOWN(PHYS_OFFSET),
                                 max_low_pfn);
[...]
free_bootmem(memory_start, memory_end - memory_start);

The first call init_bootmem_node() initializes the bootmem allocator, which primarily consists in allocating a bitmap, with one bit per page. The entire bootmem bitmap is set to 0xff via a memset() during this initialization:

static unsigned long __init init_bootmem_core(bootmem_data_t *bdata,
        unsigned long mapstart, unsigned long start, unsigned long end)
{
        [...]
        mapsize = bootmap_bytes(end - start);
        memset(bdata->node_bootmem_map, 0xff, mapsize);
        [...]
}

After doing the bootmem initialization, the NIOS II architecture code calls free_bootmem() to mark all the memory pages as available, except the ones that contain the kernel itself. To achieve this, the __free() function (which is the one triggering the BUG) clears the bits corresponding to the page to be marked as free. When clearing those bits, the function checks that the bit was previously set, and if it’s not the case, fires the BUG:

static void __init __free(bootmem_data_t *bdata,
                        unsigned long sidx, unsigned long eidx)
{
        [...]
        for (idx = sidx; idx < eidx; idx++)
                if (!test_and_clear_bit(idx, bdata->node_bootmem_map))
                        BUG();
}

So to summarize, we were in a situation where a bitmap is memset to 0xff, but almost immediately afterwards, a function that clears some bits finds that some of the bits are already cleared. Sounds odd, doesn’t it?

We started by double checking that the address of the bitmap was the same between the initialization function and the __free function, verifying that the code was not overwriting the bitmap, and other obvious issues. But everything looked alright. So we simply dumped the bitmap after it was initialized by memset to 0xff, and to our great surprise, we found that the bitmap was in fact initialized with the pattern 0xff00ff00 and not 0xffffffff. This obviously explained why we were hitting this BUG(): simply because the buffer was not properly initialized. At first, we really couldn’t believe this: how it is possible that something as essential as memset() in Linux was not doing its job properly?

On the NIOS II platform, memset() has an architecture-specific implementation, available in arch/nios2/lib/memset.c. For buffers smaller than 8 bytes, this memset implementation uses a simple naive loop, iterating byte by byte. For larger buffers, it uses a more optimized implementation, using inline assembly. This implementation copies data per blocks of 4-bytes rather than 1 byte to speed-up the memset.

We quickly tested a workaround that consisted in using the naive implementation for all buffer sizes, and it solved the problem: we had a booting kernel, all the way to the point where it mounts a root filesystem! So clearly, it’s the optimized implementation in assembly that had a bug.

After some investigation, we found out that the bug was in the very first instructions of the assembly code. The following piece of assembly is supposed to create a 4-byte value that repeats 4 times the 1-byte pattern passed as an argument to memset:

/* fill8 %3, %5 (c & 0xff) */
"       slli    %4, %5, 8\n"
"       or      %4, %4, %5\n"
"       slli    %3, %4, 16\n"
"       or      %3, %3, %4\n"

This code takes as input in %5 the one-byte pattern, and is supposed to return in %3 the 4-byte pattern. It goes through the following logic:

  • Stores in %4 the initial pattern shifted left by 8 bits. Provided an initial pattern of 0xff, %4 should now contain 0xff00
  • Does a logical or between %4 and %5, which leads to %4 containing 0xffff
  • Stores in %3 the 2-byte pattern shifted left by 16 bits. %3 should now contain 0xffff0000.
  • Does a logical or between code>%3 and %4, i.e between 0xffff0000 and 0xffff, which gives the expected 4-byte pattern 0xffffffff

When you look at the source code, it looks perfectly fine, so our source code review didn’t spot the problem. However, when looking at the actual compiled code disassembled, we got:

34:	280a923a 	slli	r5,r5,8
38:	294ab03a 	or	r5,r5,r5
3c:	2808943a 	slli	r4,r5,16
40:	2148b03a 	or	r4,r4,r5

Here r5 gets used for both %4 and %5. Due to this, the final pattern stored in r4 is 0xff00ff00 instead of the expected 0xffffffff.

Now, if we take a look at the output operands, %4 is defined with the "=r" constraint, i.e an output operand. How to prevent the compiler from re-using the corresponding register for another operand? As explained in this document, "=r" does not prevent gcc from using the same register for an output operand (%4) and input operand (%5). By adding the constrainst & (in addition to "=r"), we tell the compiler that the register associated with the given operand is an output-only register, and so, cannot be used with an input operand.

With this change, we get the following assembly output:

34:	2810923a 	slli	r8,r5,8
38:	4150b03a 	or	r8,r8,r5
3c:	400e943a 	slli	r7,r8,16
40:	3a0eb03a 	or	r7,r7,r8

Which is much better, and correctly produces the 0xffffffff pattern when 0xff is provided as the initial 1-byte pattern to memset.

In the end, the final patch only adds one character to adjust the inline assembly constraint and gets the proper behavior from gcc:

diff --git a/arch/nios2/lib/memset.c b/arch/nios2/lib/memset.c
index c2cfcb1..2fcefe7 100644
--- a/arch/nios2/lib/memset.c
+++ b/arch/nios2/lib/memset.c
@@ -68,7 +68,7 @@ void *memset(void *s, int c, size_t count)
 		  "=r" (charcnt),	/* %1  Output */
 		  "=r" (dwordcnt),	/* %2  Output */
 		  "=r" (fill8reg),	/* %3  Output */
-		  "=r" (wrkrega)	/* %4  Output */
+		  "=&r" (wrkrega)	/* %4  Output only */
 		: "r" (c),		/* %5  Input */
 		  "0" (s),		/* %0  Input/Output */
 		  "1" (count)		/* %1  Input/Output */

This patch was sent upstream to the NIOS II kernel maintainers:
[PATCH v2] nios2: memset: use the right constraint modifier for the %4 output operand, and has already been applied by the NIOS II maintainer.

We were quite surprised to find a bug in some common code for the NIOS II architecture: we were assuming it would have already been tested on enough platforms and with enough compilers/situations to not have such issues. But all in all, it was a fun debugging experience!

It is worth mentioning that in addition to this bug, we found another bug affecting NIOS II platforms, in the asm-generic implementation of the futex_atomic_cmpxchg_inatomic() function, which was causing some preemption imbalance warnings during the futex subsystem initialization. We also sent a patch for this problem, which has also been applied already.

Posted in Technical | Tagged , , | 6 Comments

Article on the CHIP in French Linux magazine

Free Electrons engineer and Allwinner platform maintainer Maxime Ripard has written a long article presenting the Nextthing C.H.I.P platform in issue #18 of French magazine OpenSilicium, dedicated to open source in embedded systems. The C.H.I.P has even been used for the front cover of the magazine!

OpenSilicium #18

In this article, Maxime presents the C.H.I.P platform, its history and the choice of the Allwinner SoC. He then details how to set up a developer-friendly environment to use the board, building and flashing from scratch U-Boot, the kernel and a Debian-based root filesystem. Finally, he describes how to use Device Tree overlays to describe additional peripherals connected to the board, with the traditional example of the LED.

OpenSilicium #18 CHIP article

In the same issue, OpenSilicium also covers numerous other topics:

  • A feedback on the FOSDEM 2016 conference
  • Uploading code to STM32 microcontrollers: the case of STM32-F401RE
  • Kernel and userspace debugging with ftrace
  • IoT prototyping with Buildroot
  • RIOT, the free operating system for the IoT world
  • Interview of Cedric Bail, working on the Enligthenment Foundation Libraries for Samsung
  • Setup of Xenomai on the Zynq Zedboard
  • Decompression of 3R data stream using a VHDL-described circuit
  • Write a userspace device driver for a FPGA using UIO
Posted in Technical | Tagged , | Leave a comment

Slides from the Embedded Linux Conference

Two weeks ago, the entire Free Electrons engineering team (9 persons) attended the Embedded Linux Conference in San Diego. We had some really good time there, with lots of interesting talks and useful meetings and discussions.

Tim Bird opening the conferenceDiscussion between Linus Torvalds and Dirk Hohndel

In addition to attending the event, we also participated by giving 5 different talks on various topics, for which we are publishing the slides:

Boris Brezillon, the new NAND Linux subsystem maintainer, presented on Modernizing the NAND framework: The big picture.

Boris Brezillon's talk on the NAND subsystem

Antoine Ténart presented on Using DT overlays to support the C.H.I.P’s capes.

Antoine Tenart's talk on using DT overlays for the CHIP

Maxime Ripard, maintainer of the Allwinner platform support in Linux, presented on Bringing display and 3D to the C.H.I.P computer.

Maxime Ripard's talk on display and 3D for the CHIP

Alexandre Belloni and Thomas Petazzoni presented Buildroot vs. OpenEmbedded/Yocto Project: a four hands discussion.

Belloni and Petazzoni's talk on OpenEmbedded vs. Buildroot

Thomas Petazzoni presented GNU Autotools: a tutorial.

Petazzoni's tutorial on the autotools

All the other slides from the conference are available from the event page as well as from eLinux.org Wiki. All conferences have been recorded, and the videos will hopefully be posted soon by the Linux Foundation.

Posted in Conference | Tagged , | Leave a comment

Free Electrons engineer Boris Brezillon becomes Linux NAND subsystem maintainer

Free Electrons engineer Boris Brezillon has been involved in the support for NAND flashes in the Linux kernel for quite some time. He is the author of the NAND driver for the Allwinner ARM processors, did several improvements to the NAND GPMI controller driver, has initiated a significant rework of the NAND subsystem, and is working on supporting MLC NANDs. Boris is also very active on the linux-mtd mailing list by reviewing patches from others, and making suggestions.

Hynix NAND flash

For those reasons, Boris was recently appointed by the MTD maintainer Brian Norris as a new maintainer of the NAND subsystem. NAND is considered a sub-subsystem of the MTD subsystem, and as such, Boris will be sending pull requests to Brian, who in turn is sending pull requests to Linus Torvalds. See this commit for the addition of Boris as a NAND maintainer in the MAINTAINERS file. Boris will therefore be in charge of reviewing and merging all the patches touching drivers/mtd/nand/, which consist mainly of NAND drivers. Boris has created a nand/next on Github, where he has already merged a number of patches that will be pushed to Brian Norris during the 4.7 merge window.

We are happy to see one of our engineers taking another position as a maintainer in the kernel community. Maxime Ripard was already a co-maintainer of the Allwinner ARM platform support, Alexandre Belloni a co-maintainer of the RTC subsystem and Atmel ARM platform support, Grégory Clement a co-maintainer of the Marvell EBU platform support, and Antoine Ténart a co-maintainer of the Annapurna Labs platform support.

Posted in Technical | Tagged , , , , | Leave a comment

Slides from Collaboration Summit talk on Linux kernel upstreaming

As we announced in a previous blog post, Free Electrons CTO Thomas Petazzoni gave a talk at the Collaboration Summit 2016 covering the topic of “Upstreaming hardware support in the Linux kernel: why and how?“.

The slides of the talk are now available in PDF format.

Upstreaming hardware support in the Linux kernel: why and how?

Upstreaming hardware support in the Linux kernel: why and how?

Upstreaming hardware support in the Linux kernel: why and how?

Through this talk, we identified a number of major reasons that should encourage hardware vendors to contribute the support for their hardware to the upstream Linux kernel, and some hints on how to achieve that. Of course, within a 25 minutes time slot, it was not possible to get into the details, but hopefully the general hints we have shared, based on our significant Linux kernel upstreaming experience, have been useful for the audience.

Unfortunately, none of the talks at the Collaboration Summit were recorded, so no video will be available for this talk.

Posted in Conference | Tagged , , | 1 Comment