Archive

Posts Tagged ‘gpl’

Raspberry Pi Bootloader License Precludes it to Run on Competing Broadcom BCM283x Boards

July 19th, 2016 17 comments

Yesterday I wrote about ArduCAM Raspberry Pi compatible module, that packs most of the features of Raspberry Pi Zero or Pi Compute module into a 24x24mm board, and is based on Broadcom BCM2835 processor. One person also started a thread on Raspberry Pi forums about the tiny module, and one of the Raspberry Pi engineer and forum moderator replied that will would breach the bootloader license.

Raspberry_Pi_Bootloader_LicenseThe important part is the sentence highlighted above:

This software may only be used for the purpose of developing for, running or using a Raspberry Pi device.

ArduCAM module is only Raspberry Pi compatible, so it would indeed breach the license, and you can get into troubles if you planned to use that module in a commercial project, especially in countries where IP protection is taking seriously.

This raises a few questions. First why did the Raspberry Pi foundation chose that restrictive license? The obvious answer would be to protect there investment, but it’s also possible that since the bootloader and firmware is related to the GPU, video codec license may also have been a part of the decision.

The other issues is that after ordering 5K Broadcom BCM2835 processors for the first run of their ODROID-W module, Broadcom decided not to sell the processor anymore to Hardkernel subsequently. The exact reason is not known, but there are speculations that it was because of the Raspberry Pi foundation, and the license above may have been a reason for it. So could this also happen to ArduCAM? In theory yes, but If I’m not mistaken the company is based in China, and there are multiple smaller distributors, but it may not be quite as easy for Broadcom to block them.

The final question I has is whether it could possible to legally use the board without using the bootloader. Maybe… thanks to Kristina Brooks work on an open source bootloader for Raspberry Pi, released under BSD and GPLv2+, and not including any “Raspberry Pi only” conditions. There are some serious caveats such as no support for video codecs (licenses are part of it too), and while it can boot Linux, some things are broken.

If you are based in mainland China, and your customers are all based there, you probably don’t have to care about any of this, but in the western world, commercial projects should probably keep using official Raspberry Pi parts, or other solutions not involving Broadcom processors, nor official Raspberry Pi OS images.

Zidoo Releases Kodi Source Code Modifications for Rockchip RK3368 and Allwinner H3

September 17th, 2015 31 comments

Kodi is a popular open source media center, but many companies will not simply install the version released on Kodi.org, and instead modify the source code to bring their own improvements. However most companies never release the source as they ought to as per the GPL license used by Kodi. The good news is that Zidoo released their modifications for Rockchip RK3368 and Allwinner H3.

Zidoo_Kodi_Atmos_PassthroughTheir modifications include support for 3D MVC,7.1 Channel HD Audio pass through, and HW decoding for Rockchip RK3368, and 5.1 audio pass-through, 4K @ 30 fps, and H.265 hardware video decoding for Allwinner H3.  You can read the announcement on Kodi forums for RK3368 (Kodi 15.1) and H3 (Kodi 14.2).

Kodi 15.1 source code for Rockchip RK3368 can be found on github (make sure to use zidoo-15.1 branch, and not master). In order to build Kodi yourself, you’ll however need the latest version of Rockchip RK3368 SDK, which Zidoo is not allowed to release themselves [Update: Based on Koying’s comment below, you don’t really need the SDK, but only rkffplayer.so].  You’ll also need to apply “kodi-ffmpeg-patch-20150910.patch” to ffmpeg library, before building Kodi. They recommend their own Zidoo X6 to run the apk, as it has not been tested on other devices yet. Some Kodi developers already had a quick look at the code, and they seem OK with it.

There’s been less interest in Allwinner H3’s source code, but you can also get it on github.

ESP8266 SDK 1.1.0 is Now Released Under an MIT License

May 29th, 2015 7 comments

ESP8266 is the now famous dirt-cheap Wi-Fi SoC used for IoT applications. It can be used by hobbyists and companies alike. But for the later, there was a licensing issue as Espressif ESP8266 SDK was initially released under the GPLv3 license. GPL code is great and lots of open source projects are released under the most common open source license. But since proprietary, closed source software has still its place in the market place, some other more permissive licenses such as LGPL are used for library, and Android for example has an Apache License 2.0.

ESP8266_MIT_License

So previously, if you developed an application using ESP8266 SDK, you’re code would have to be GPL too, since the license is viral. It would also cause issues if you had released your application under an Apache or MIT license.

But now, all is well, as Espressif released ESP8266 SDK 1.10 under an MIT license, and also fixed various bugs in the process. That means that to make sure you don’t have licensing issues in your project, you should probably update to the latest version of the SDK.

Thanks to Paul and Jon for having brought up the issue, and help convince Espressif to change the license.

ARM: “Microcontrollers Are Better Because There’s No GPL”

April 30th, 2015 6 comments

[Update: ARM has pulled down the video and issued a statement]

ARM has uploaded a video today entitled “Microcontrollers for Makers” showing the benefits of using micro-controller boards instead of processor based development boards such as Raspberry Pi or ODROID-C1, and their four first points are right on target, but the last one, as mentioned by Olimex, is completely wrong, and already made several people upset.

ARM_No_GPLLet’s go through the first four points:

  • Micro-controllers are more energy efficient, so if your project is requires years on a cell-coin battery, MCUs are the way to go.
  • MCU are cheaper too, now you can even get an MCU board for $1.
  • They are smaller. The chip shown on the golf ball is Kinetis KL03
  • If you need real-time I/O, processors can’t beat micro-controller, that why people decide to connect an Arduino board to their Raspberry Pi, or products like UDOO Neo are brought to market.

And now the last point: “No GPL”, “as you can keep your source code closed”. What?

First, there’s nothing that forces you to write your application with GPL code, so you can still run and release proprietary apps on Linux. Second, running code on an MCU does not systematically mean you don’t have to care of open source licenses, as for instance, ARM’s very own mbed TLS is licensed under a dual license including GPL. Finally, if they really aim to target hobbyists in that video, most of them don’t really need to care about licenses, as long as they only use their project internally, but I think many will still want to release their source code, simply because sharing your work is the default behavior for many in the makers’ community, and GPL’ed source code or other open source code is what allowed the makers’ community to prosper and grow.

Categories: Hardware, Video Tags: arm, gpl, mcu

Allwinner CedarX Media Codec Library GPL/LGPL Compliance Update

March 23rd, 2015 29 comments

Last month, I wrote about potential open source licenses and VP6 copyright infringement by Allwinner with their CedarX media codec library, and then since there’s been a few developments.
Allwinner_GPL_LGPL

First, Allwinner sent me an email saying they’ve now updated Cedarx library and referring my previous article. Here’s an extract:

Here, I have some update of the Allwinner’s open-source status.

We have done a lot of discussion with the developers from the linux-sunxi communication about the software license of CedarX. For each question or requirement asked by the developers, Allwinner has identify and try to give the best solution.

Now, we believe Allwinner’s CedarX license is fully compliant and resolves concerns from the community. And you can take the announcement https:[email protected]/msg10597.html as a reference.

Allwinner is always supporting the open-source, and try to do better and better. You can see some update on the github https://github.com/allwinner-zh, and some feedback from developers: https://github.com/allwinner-zh/bootloader/issues/5.

It’s difficult to make everyone happy, but we believe Allwinner will do better and better, and give more and more help to the developers, and we believe Allwinner will be accepted by more and more developers.

The announcement claims “the CedarX media codec framework is now released with full open source code under the LGPL license”. That actually means there’s an open source API to access the closed source binaries that’s released under the LGPL license. The good news is the VP6 code that could infringe on On2/Google copyrights has now been removed and they are using ffmpeg instead.

So I asked on linux-sunxi IRC channel to find out if there was real progress made, and soon after some more details were released on linux-sunxi mailing list, and the part that looks really bad is:

264FillDefaultRefList() and a lot of code around it is straight out of the libavcodec h264 decoder. The original name for that function is ff_h264_fill_default_ref_list() in libavcodec/h264_refs.c: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264_refs.c#L115 This is new, as some totally different code for h264 was available in the previous versions of the cedarx binaries.

This looks like Allwinner reached a new low, as it would mean Allwinner purposely renamed some function from LGPL code to make it look like it was their own. However, another email on arm-netbook mailing list by a soon-to-be Allwinner’s software engineer gives some more light to what actually happened here:

I can explain the whole process in a whole detail, because I was directly involved in the process of this decision and I can tell where this is going right now:

The rename was done to fix the LGPL violations by adding a wrapper for the GPLed libraries which will be LGPLed and published. This way we have Binary<->LGPLed open source code<->GPL libraries

Next step will be to drop the whole “we ship our own SDK”-thing and move over to stream our code into the existing open source alternatives.

But until the FOSS libraries have all the functionality from the shipped SDK we can not just stop supporting our customers in China. Also we can not suddenly make it open source for the following reasons:

  • Some engineers and managers do not fully comply with the GPLing of their code yet.
  • The code has awful coding style and my armcc refuses to compile at least 2/3 of the code because of the Chinese comments.
  • Also some of the engineers obviously have never heard the term “revision control” which makes it even harder to locate the actual version of the source code from which the binary was compiled from… -.-‘

So Allwinner has not make it right just yet, but at least they are trying, and even hiring western engineers to try fixing the licensing issues. I’m just not sure the current plan for binary<->LGPL wrapper<->GPL is actually valid, but at least they have longer term plan to upstream changes to open source project, at least that’s the way to understand the email above. Beside legal and technical work, moving from closed source “license infringing” code to properly licensed code is also a social engineering task, as all stakeholders in the company and possibly their customers must be convinced proper licensing is the way to go, and not the business as usual “just copy code from the net” and ignore licensing terms as Allwinner and many other companies have done in the past.

Allwinner’s New Media Codec Library (CedarX) May Infringe on Open Source Licenses and Copyrights

February 26th, 2015 8 comments

Allwinner has had to good idea to open allwinner-zh github account last September in order to release source code, binary libraries, and documentation for these ARM processors. Yesterday, the company released a new version of their closed source CedarX library used to decode and encode video streams. But Luc Verhaegen (libv), known for his reverse-engineering work on ARM Mali-400 (lima driver) and now Mali-Txxx GPU (Tamil driver), analyzed the binary and claimed  the library is not compliant with LGPL licenses, and may also infringe on On2 copyrights.

Allwinner_GPL_LGPLLuc wrote his concerns on sunxi-linux mailing list, and Allwinner promised to look into it.

Two libraries are involved:

  • ffmpeg which includes both LGPL and GPL licenses, but the contention seems to be about the LGPL part, since only optional features are GPL’ed in ffmpeg. It’s perfectly fine to include LGPL libraries into your binaries, as long as you don’t modify the open source libraries, but if you do, the source code modifications must be released under an LGPL license.
  • libvp62 an open source implementation of On2 VP6 codec released in 2006 that was taken down due to copyright infringements since it was allegedly “anti-compiled from Java”

I can imagine the timeline for the latter happened that way:

  1. Management to customer: “OK, we’ll get you a VP6 demo next week”
  2. Management to engineering team: “I need VP6 for next week to show to our most important customer”
  3. Engineering team: Open jaw first, then look for code on Baidu, and find it on pudn (Sight of relief)
  4. VP6 demo is implemented and successfully demo’ed to customer
  5. Management, customer and engineers are all happy! Mission accomplished.

On2 is now owned by Google, so Allwinner could have a problem or two if the copyright infringement is confirmed, and Google takes action. Luckily VP6 video decoding is also supported by ffmpeg, so they may be able to sort this out.

It’s also interesting to read the full thread on sunxi-linux mailing, as people explains what kind of issues they had with closed source project, including a canceled project using Allwinner A20, and potential security issues.

Via Phoronix

Embedded Linux Conference 2014 Schedule

April 19th, 2014 1 comment

The Tenth Embedded Linux Conference (ELC 2014) will take place on April 29 – May 1, 2014 at the San Jose Marriott in San Jose, California. The event will feature 90+ sessions on embedded Linux, Android and IoT with over 450 attendees expected to attend. It will also be co-located with Android Builders Summit and the AllSeen Alliance Hackfest. Even if you can’t attend it’s still interesting to see what will be discussed at the event to get a grasp of on-going developments, learn a few things about different optimization techniques, and so on. So I’ve gone through the sessions’ description, and I’ve designed my own virtual schedule with sessions that could be of interest.

Embedded_Linux_Conference_2014April 29

Linux has taken the embedded world by storm.  Billions (with a ‘B’) of devices have now shipped with a Linux kernel, and it seems unstoppable.  But will the next 10 billion devices ship with Linux or with something else?  How can Linux be specialized for deeply embedded projects, as characterized by the Internet of Things, while still maintaining the network effects of community cooperation and sharing?  Is this possible or even desirable?  The startling truth might be revealed at this keynote. Or, Tim might just rant a bit about device-tree… who knows?

The past year has seen a remarkable growth of interest in super-low-power and super-low-form-factor computing, in the form of ‘wearables’, the ‘Internet of Things’, and the release of exciting new hardware such as Intel’s Quark and Edison SoCs. Taking advantage of this super-small hardware also implies the need for super-small operating systems and applications to match. This talk will describe a super-small-footprint Linux distribution called ‘microYocto”. The main focus will be the kernel and how we achieved what we think is close to the minimal possible kernel footprint, both in terms of static text size and dynamic memory usage. We’ll talk about the tools and methodologies we used and developed to analyze the problem, such as tracing and machine simulation, and will describe the various technologies developed and applied to achieving this minimalistic system.

Many community resources exist about boot time reduction. However, few of them are up to date and share the exact time savings that can be achieved on recent systems. This talk will detail today’s most efficient techniques to reduce boot time. For each of them, figures will be shared, obtained from recent boot time reduction projects and from the preparation of Free Electrons new workshop on this topic. If you attend this talk, you will know which optimization techniques are worth using first, and will save time not exploring techniques that won’t make a significant difference in your project. Don’t tell your boss, and this will leave your more time to contribute to community projects!

In this talk, Chris will describe the internal workings of the Android graphics stack from the Application layer down through the stack to pixels on the screen. It is a fairly complex journey, taking in two different 2D rendering engines, applications calling OpenGL ES directory, passing buffers on to the system compositor, Surface Flinger, and then down to the display controller or frame buffer. All this requires careful synchronisation so that what appears on the screen is smooth, without jitter, and makes efficient use of memory, CPU, GPU and power resources.

Linux-based platforms such as the Beaglebone and Raspberry Pi are inexpensive powerhouses. But, beyond being cool on their own, what else can you do with them? This presentation will step you through the process of building a Wi-Fi enabled, Linux-based robot that you can build without breaking the bank and without special knowledge of robotics and robotic controls.

Since last year, we have been working on supporting the SoCs from Allwinner, a Chinese SoC vendor, in the mainline kernel. These SoCs are cheap, wide-spread, backed by a strong community and, until last year, only supported by an out-of-tree kernel. Through this talk, we would like to share the status of this effort: where we were a year ago, what solutions were in place, where we are currently, and what to expect from the future. We will also focus on the community around these SoCs, the work that is done there, etc.

April 30

GCC is an optimizing compiler, currently most common compiler to build software for Embedded Linux systems like Android, Yocto Project etc. This tutorial will introduce specific optimizations and features of GCC which are less known but could benefit optimizing software especially for embedded use while highlight the effect of common optimizations. While it will focus on squeezing most out of GCC, it will also cover some of “pessimizations” to avoid and will tip the developer to write code thats more conducive (compiler friendly) for general optimizations. They will also get some contrast with other compilers when needed.

Throughout the last two years, a team of engineers at Free Electrons has been involved in mainlining the support for several ARM processors from Marvell, converting the not-so-great vendor-specific BSP into mainline quality code progressively merged upstream. This effort of several hundreds working days, has led to the integration of hundreds of patches in the kernel. Through this talk we would like to share some lessons learned regarding this mainlining effort, which could be useful to other engineers involved in ARM SoC support, as well as detail the steps we have gone through, the mistakes we’ve made and how we solved them, and generally our experience on this project.

This BoFs is intended to bring together anybody that tests the Linux kernel to share best practices and brainstorm new ideas. Topics may range from .config testing, module/built-in drivers, test methods and tools for testing specific driver subsystems, VM/scheduler/interrupt stress testing, and beyond. The discussion is targeted at Linux kernel developers, test engineers, and embedded Linux product teams/consultants with the common task of testing Linux kernel integrity. Attendees should have a firm grasp of building and deploying the kernel as well as kernel/userspace kernel APIs.

Several vendors are getting ready to start enabling the upstream kernel for their upcoming 64-bit ARM platforms, and it opens up a few questions on things that are not quite sorted out yet, especially on the embedded and mobile platforms. This is an open discussion on the issues these maintainers are anticipating, and what we should do about it.

Communication between components is necessary for effective power management in mobile devices. The System Power Management Interface, also known as SPMI, is a standardized bus interface intended to provide power-management related connectivity between components. Josh Cartwright will provide a high-level architectural overview of SPMI and discuss how to leverage the Linux Kernel software interfaces (expected to land in 3.15) to communicate with devices on the bus.

May 1

While Android has been created for mobile devices — phones first and now tablets — it can, nonetheless, be used as the basis of any touch-screen system, whether it be mobile or not. Essentially, Android is a custom-built embedded Linux distribution with a very elaborate and rich set of user-space abstractions, APIs, services and virtual machine. This one-day workshop is aimed at embedded developers wanting to build embedded systems using Android. It will cover Android from the ground up, enabling developers to get a firm hold on the components that make up Android and how they need to be adapted to an embedded system. Specifically, we will start by introducing Android’s overall architecture and then proceed to peel Android’s layer one-by-one.

This half-day workshop is aimed at embedded developers that want to use Android in their embedded designs.

The MIPS processor cores are widely used in embedded platforms, including TVs and set-top-boxes. In most of those platforms dedicated graphics hardware exists but it may be specialized for its use in audio and video signal processing: rendering of web content has to be done in software. We implemented optimizations for the software-based QPainter renderer to improve the performance of Qt —including QtWebKit— in MIPS processors. The target platform was the modern 74kf cores, which include new SIMD instructions suitable for graphics operations (alpha blending, color space conversion and JPEG image decoding), and also for non-graphics operations: string functions were also improved. Our figures estimate that web pages are rendered up to 30% faster using hand-coded assembler fast-paths for those operations.

Software Freedom Conservancy announced last year a renewed effort for cross-project collaborative GPL compliance efforts, including copyright holders from BusyBox, Linux, and Samba. Conservancy uses an internal system of communication and collaboration to take input from stakeholders to discuss and engage in compliance activity to ensure compliance with the GPL throughout the technology industry and particularly in the embedded device market. Compliance with the GPL is the responsibility of copyright holders of the software, and Conservancy helps those copyright holders pursue the work, so those developers can focus on coding. In this talk, the President of Conservancy will discuss how Conservancy handles compliance matters, what matters it focuses on, and how the copyright holders that work with Conservancy engage in a collaborative effort to ensure compliance with the GPL.

Ubuntu Touch is the new Ubuntu-based OS for phones and tablets. Announced at the beginning of 2013, it gives a new UI and design proposal, but also a new way of developing and supporting many different devices, using either the Android HAL or the traditional Linux stack to build the platform. This talk will go over the Ubuntu Touch internals, presenting the technical decisions and also the work that was done to bootstrap this new platform (camera, radio, video decode, GLES and etc) and the future challenges to support a single stack across mobile and the traditional desktop.

These are just a few sessions out of the 90+ sessions available at the Embedded Linux Conference and Android Builder Summit. You can check the full schedule to find out which sessions are most interesting to you.

If you’d like to attend the event, you’ll need to register online.

The attendance fees have significantly gone up compared to last year, at least for hobbyists, but include entrance for both ELC and Android Builder Summit:

  • Professional Registration Fee US$600 (Was US$500 until March 29, 2014)
  • Hobbyist Fee – US$150
  • Student FeeUS$150

After the events, many videos are usually uploaded by the Linux Foundation, and you should be able to find the list of talks with links to presentation slides oneLinux.org.

Mediatek MT6589 Linux Source Code, CyanogenMod 11 Image for Wiko Stairway Smartphone

March 13th, 2014 8 comments

Mediatek and their customers have still not gotten into the habit of complying with the GPL license, and releasing the relevant source code such as the Linux kernel. There appears to be at least one smartphone, Wiko Stairway, where the Linux kernel has been released, and chrmhoffmann, a members of XDA developers forums, has even released on unofficial CyanogenMod 11 ROM (Android 4.4.2 Kit Kat) for the device.

Mediatek_Linux_Kernel_Menuconfig

There are three source repositories for the Linux kernel, “android device“, and Android.

I’ve only looked into the kernel which is version 3.4.5. Mediatek has apparently messed up the Linux kernel quite a bit, and you’ll have to do some funny things to build the kernel, and all Mediatek options in menuconfig are in a sub-section called “Mediatek Properitary Configuration” (sic.), and it’s not possible to simply go to System Type menu to change the processor type for instance.

Let’s get the source first:

So together with the kernel, we’ve got the bionic library, and the modifications done by Mediatek in the mediatek directory. The Makefile is this Linux kernel is set to use the Android gcc toolchain (arm-linux-androideabi-gcc), but I tried to build the kernel with CROSS_COMPILE=arm-linux-gnueabihf- instead, and it failed along the way with the following error:

This is from code added by Mediatek, and at first I just disabled it, but a similar problem occurred in the wlan drivers. Some research indicated in may be a toolchain problem, so I’ve installed the latest Linaro Android toolchain and added it to my path:

And started the build:

Same error. So I gave a last try with an older Linaro Android toolchain using gcc 4.6, and this did the trick:

As for the current CM11 ROM, phone calls, SMS, data (2G, 3G), Wi-Fi, audio, and most sensors are working fine, but there’s still more work to do as the second SIM card, the camera, hardware video decoding, GPS, Bluetooth, FM radio and some MTK specific features are not supported yet. It may not be wise to try it on MT6589 hardware other than Wiko Stairway, as you may brick your device.