Announcing libperipha and cortex-uni-startup projects

More and more ARM Cortex based boards appear for use by OpenSource/OpenHardware/Maker communities, and
frequently asked question in response to a new announcement is often "Is this supported by open-source toolchain?". Many people know that gcc supports ARM, including Cortex-M, very well, and many projects now lean towards using https://launchpad.net/gcc-arm-embedded as the package of their choice.

But compiler is only part of the toolchain - there should be also at
least basic hardware definition headers which would allow to access peripherals of particular chip. There was big step in that direction done by ARM Ltd, itself, by releasing CMSIS library for the Cortex-M CPU cores under open-source license, though that didn't go without controversy, see comments to that post and followup.

That's great step, but again, it's only part of the story - while it allows to access Cortex-M core registers which are common across all MCUs, there're more to MCU than just CPU - it's all the peripheral blocks. Even basic things as GPIO and timers are vendor- and model-specific, and periphery is what differentiates one vendor's  offering from another's.

And other vendors don't rush to follow ARM's example, so few vendor-specific CMSIS packages are under OpenSource license (one great example of the contrary is Energy Micro EFM32 CMSIS - it's great because they open-sourced it even before ARM). One  good approach to use OpenSource-friendly MCUs for your projects, and everyone is encouraged to do so. Unfortunately, that may not be practical or even possible (I wish I could by EFM32 chips in my part of the world).

So, the idea is to provide open-source MCU headers for use in OpenSource projects - until all vendors get smart to provide them. That's how libperipha project was born. Note that it's not limited to ARM Cortex-M MCUs, though support for them was a primary motivation.

There's final, small, but just as important piece which construes MCU toolchain - startup code. Without it, your application simply won't run. Another project, cortex-uni-startup (unified Cortex startup) was created to cover that. As excellent article by Ivan Sergeev explains, Cortex-M was specifically re-engineered to allow startup code to be written without any single line of assembly! cortex-uni-startup explands on this to provide easily reusable Cortex-M core startup code (usable on any Cortex-M device, but without support for peripheral-specific interrupts), then extends it to cover interrupts of particular MCU model.

These two projects are separate to cover differences in scope (cortex-uni-startup is Cortex-M specific, libperipha is unbound), licensing (cortex-uni-startup core is public domain, libperipha is BSD and others), and usage (libperipha is gross database which you probably will just want to use, then hack, cortex-uni-startup is nice learning tool of beauty of Cortex-M architecture, which you welcome to glance over before using - you won't be overwhelmed, as it's small).

Last final note - while these projects are conceived to be comprehensive, I don't have an aim to sit and add each and every possible bit of every MCU there. Instead, it is intended to be easy do add missing pieces to it on demand - right while you're working on some applied project and find such missing pieces. Then, if people find this to be indeed so, and project overall useful and contribute, then they indeed will acquire comprehensive coverage of MCUs. So, have a look, give it a try, shared feedback, spread the word, contribute patches, and overall, enjoy ;-).

Growing GPL/FOSS Loyalty Among Chinese ARM SoC Vendors

There are visible changes in how Chinese ARM SoC vendors deal with Open Source license compliance (words) and Open Source software at all (spirit) during this year. Not only western resellers of devices based on Chinese SoCs release GPL compliance packages, but many popular SoC companies themselves established GPL compliance/loyalty/support pages. Few go beyond just adhering to word of GPL by releasing kernel source blobs (by blobs I means large tarballs devoid of any development history and support files), but also establish git repositories, release Android trees, set up public bugtrackers.

Of course, they are still not exactly GPL compliant - scrutiny of any releases would likely show missing parts, binary objects for drivers, etc. But there's definitely a difference between plucking out WiFi driver out of flash image you have on you device and downloading "official binary" from a SoC vendors. It's also a good start, and there's a hope the situation with complete source availability will improve. And as everyone watching the area knows, the industry at the whole needs to improve - Western companies may comply with GPL by providing source for kernel shims, but that doesn't help users to support vendors' hardware if they just move binary blobs to userspace.

The changes discussed didn't come by themselves and at once. Lot of people paved the road to this via gpl-violations.org, via various leaks, etc. But critical change came with emergence of Open Hardware startups. They are led by people who strongly believe in Open paradigm, but also to do their ODM-like business, they need to provide sufficient documentation/sources to the customers. So they have little choice but request that from upstream SoC vendors, in redistributable form. So, thanks Rhombus-Tech, Olimex, Cubitech!

Anyway, here're the links to Chinese companies' GPL loyalty pages I know so far. Additions and corrections are welcome.

• Telechips 
• Rockhip
• Allwinner
• Amlogic
• VIA/Wondermedia

And as extra, community projects to support some of vendor SoCs from above list:

• Rockchip 
• Allwinner 
• VIA/Wondermedia