Nerves systems provide the operating system, libraries and other tools for building firmware for specific hardware. The Nerves Core Team maintains a set of ports to widely available hardware. Nerves runs on many other boards as well and those ports are frequently derived from the official systems.
Nerves systems releases had previously been announced as part of the core Nerves tooling releases, but they change more frequently, so my plan is to announce to this topic instead.
FAQ on Nerves Releases
How often are Nerves system releases made?
We follow the release cadence of the Buildroot project. Buildroot makes a release every 3 months. This allows us to keep up with security and bug fixes for the non-Elixir infrastructure in Nerves without being overly burdensome. Sometimes Buildroot makes a patch release to fix a particularly bad security issue or bug. We follow suit even if that issue is unlikely to affect Nerves users.
Why don’t Nerves systems follow semantic versioning?
Given that Buildroot contains 1000s of packages, its near impossible to know whether a version bump in one is breaking or not and probably not helpful. We’ve settled on the following approach and admit that it is imperfect:
Major version updates result in firmware incompatibilities that make over-the-air updates difficult or impossible. Examples include big changes to filesystem layout or changing bootloaders.
Minor version updates are made for each Buildroot release. Buildroot version numbers have the form yyyy.mm and don’t convey any information about release compatibility. It is good practice to review the Buildroot release notes especially for changes to C libraries and packages that you use. We also schedule Erlang major version bumps and Linux kernel minor version bumps to coincide with these releases.
Patch version updates include all of the other changes we make between Buildroot releases. We try to keep these minor so that it’s not risky to upgrade patch versions, but they may exceed the normal scope of semantic version patches.
Because of this, many people lock their Nerves System dependency down very tightly in their mix.exs deps. We recommend this practice. Please do follow updates to your system to capture security fixes.
How does the core team decide which boards to support?
It’s our policy to make official releases for widely available hardware that has large open-source communities providing support. People have ported Nerves to many other platforms and some have made their ports public. It is a non-trivial task to maintain a port over the long term. If you are in need of a port for a board that the core team does not support, it’s worth posting to the forum to see if someone has made one and is willing to share.
New versions of the official Nerves systems are out. The main update is to use Buildroot 2019.08. Specific versions are:
nerves_system_bbb v2.4.0
nerves_system_rpi* v1.9.0
nerves_system_x86_64 v1.9.0
Per popular request, the Raspberry Pi and Beaglebone systems now have common USB->UART drivers built-in. The hope is that most or all Arduinos and other USB-based microcontroller devices work out of the box with Circuits.UART now.
If you’re a Raspberry Pi 4 user who has customized the fwup.conf, please note that the bootcode.bin file is no longer included in releases. It is not used by the Raspberry Pi 4 and has been removed. See the nerves_system_rpi4CHANGELOG.md for details.
It’s that time again for more security and bug fix updates to the official Nerves systems. We are now shipping with Buildroot 2019.08.2 and Erlang/OTP 22.1.7. None of these updates should break existing projects and we recommend moving to this release.
PocketBeagle users (nerves_system_bbb) can now use the pinmux helper for changing pin modes at runtime. We inadvertantly had this disabled. Hopefully this will reduce the number of people needing to delve into the depths of device trees and overlays to get their projects working.
Raspberry Pi 4 users: we still do not have a solution for video output. If you are making kiosks, please continue to use the Raspberry Pi 3 B/B+. The 3D accelerator software and hardware is different on the RPi 4. Partial work has been done, but it is on the backburner due to me being busy with other work.
A new version of the Nerves systems is now available that uses nerves_system_br v1.10.1. We recommend upgrading or reviewing the changes for your projects to pull in the latest security and bug fixes from Buildroot.
This update has one potentially breaking change for Raspberry Pi Zero, 3 A+ and Beaglebone users. We’ve had a growing number of issues being reported by people using the USB “gadget” port for communicating with those boards. It seems that users with Linux laptops have had the most trouble. The fix was to switch the current gadget Ethernet driver with the g_ether driver. This changes low level details on the virtual Ethernet connection to one that is more compatible across OSX, Linux, and Windows. Unfortunately, the straightforward way of enabling this new driver means that we lose the virtual console port over USB. The debug console is now on the UART pins of those boards.
Here’s a list of the most visible updates:
Buildroot 2019.11.1
Erlang/OTP 22.2.3
boardid 1.6.0 - Support serial numbers stored in DMI/BIOS on x86
mesa3d - Experimental update to support the Raspberry Pi 4’s V3D driver
Specific versions for the releases:
nerves_system_bbb v2.5.1
nerves_system_rpi* v1.10.1
nerves_system_x86_64 v1.10.1
Also, since many people might be updating to Elixir 1.10, please continue to use Elixir 1.8 or 1.9 with your Nerves projects. We’ll be making a nerves release soon that supports it.
New official Nerves systems are available that use nerves_system_br v1.12.0 . We recommend upgrading and reviewing the change logs for the upgraded constituent projects.
Qt 5.14.2 - This is an update from 5.14.1 that may affect webengine kiosk
users
Raspberry Pi Linux and firmware tagged as 1.20200601
bb.org device tree overlays updated to support new Beagleboard devices
As you can see above, we’re using OTP 23. We’ve had a really good experience with it so far. Please make sure that you’re using OTP 23.0.1 or later on CI and your host when building Nerves projects. Also, we still run into libraries that put build products in their source directories instead of under _build. It’s much better now than in the past, but it’s safest if you build clean after making this update just in case.
If you have made a custom system for a Raspberry Pi, please update the Linux kernel version that it uses it to match tag 1.20200601. This is still a Linux 4.19 kernel. Here’s an example of how to change your system.
Specific versions for the releases:
nerves_system_bbb v2.7.1
nerves_system_rpi* v1.12.1
nerves_system_x86_64 v1.12.1
nerves_system_osd32mp1 v0.3.1
As always, let us know either here or the Elixir Slack if you have questions and GitHub issues for bugs.
Hello, and thanks for all your work on Nerves! I’m new to Nerves and trying to get a project working on a Raspberry Pi Zero W.
I have a couple of these boards at hand (v1.2, from 2016 I think) and when trying to install any of the example apps using rpi0 as a target, I get a system that won’t boot. Appears to hang right at startup (I get the Raspberry logo and nothing else on display) and I also get two flashes repeating on the led. I infer from google this means it can’t read from the SD card. But, same SD card burned with rpi as target and it boots. I also have an rpi3, and that boots just fine with the same cards. Any idea what might be the issue? Are these boards too old for the current nerves rpi0 system?
The Nerves system for the Raspberry Pi Zero boots headless. The logos come from the Linux kernel, but after Linux puts them there, nothing uses HDMI by default. This makes it look it’s not working, but it really is.
There are a couple ways of accessing the IEx prompt on the RPi Zero. I think that the easiest is by using the virtual Ethernet interface that goes over the USB port. This only works on the data USB connector which is close to the middle of the board. The other connector is power only. On your computer, you should see a new network device show up when you plug the RPi Zero into it. After it boots and the LED starts blinking like a heart beat, you should be able to ping nerves.local and ssh nerves.local to get to the prompt.
The other option for the Raspberry Pi Zero W is to set up networking so that it connects to a nearby WiFi access point. This can be hardcoded in your application’s target.exs in the vintage_net section, manually set over USB once, or by adding a dependency to vintage_net_wizard. The cookbook has some examples.
If all else fails and you’re getting frustrated with Nerves, the Elixir Circuits project has pre-built firmware and a guide that may help too. See Elixir Circuits Quickstart.
Thank you! I realized the headless nature after I posted I did get it to boot by going back to otp-22 and v1.11 on nerves_system_rpi0 so I can continue to learn. On the latest release, I get timeouts trying to ping nerves.local and the blinky leds don’t flash as they do with firmware built on the earlier release. Once I can debug things a bit better I’ll report back. I’ll check the links you provided and appreciate your help!
Interesting. That would definitely be something we want to fix. I don’t see anything obvious that might cause that to happen between v1.11.x and v1.12.x. However, we have certainly seen USB regressions on the RPi in the past. I’ll keep a look out for it was well. When you get back to v1.12.x and if it’s still happening, please open a GitHub issue with some details about your setup and one of us will try to reproduce and fix.
New official Nerves systems are available that use nerves_system_br v1.12.4. We did not make official systems with nerves_system_br v1.12.2 and v1.12.3. While this is a bug fix release, we still recommend perusing change logs and release notes.
One change that may affect C code in Elixir libraries is that we fix inconsistent C optimization flags. Everything is now -O2 by default. We have had reports of libraries failing to build due to missing -fPIC options. The fix is to add -fPIC to the gcc options in the library.
A second change is that we’re starting a migration from storing application data in the /root directory to /data. Currently, /data is a symlink to /root. It would be great if everyone could start updating absolute paths in their programs to save to /data instead.
We are planning a minor update to the Nerves systems in the next month since Buildroot 2020.08 was just released.
Note: I haven’t published Nerves System release announcements to the forum in a while. There are starting to be updates pertinent to Nerves Nx/Axon users with the latest releases so I’m going to try posting here more often for a broader audience.
New official Nerves systems are available that use nerves_system_br v1.18.3. If you’re using a v1.18.x system already, this is a straightforward update. If you have made a custom Nerves system from a previous release, please see the v1.18.0 release notes for upgrading.
Here are the most visible updates from v1.18.0 to v1.18.3:
CMake support. Pass -D CMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE} when configuring your project that uses CMake and CMake will find the right libraries and crosscompilers.
OpenMP support. See the cvt_color project for an example Elixir library that uses both CMake and OpenMP.
Raspberry Pi WiFi firmware updates. This brings in numerous bug fixes to the built-in WiFi modules and has the side effect of reducing a simple Raspberry Pi firmware image by almost 1/3 due to some cleanup of unused firmware blobs.
Lastly, the Nerves project has started a backup download site at dl.nerves-project.org. Nerves’ Buildroot integration downloads quite a few projects’ source code tarballs when building. There was a GitHub change in late November (now reverted) that broke CI builds. This backup download site is automatically updated with tarballs downloaded by official Nerves system builds and will be used automatically if the primary download site does not work. See the CircleCI scripts for details. You can implement a corporate backup download site for your custom Nerves systems using the same logic.
New official Nerves systems are available that use nerves_system_br v1.18.4 . If you’re using a v1.18.x system already, this is a straightforward update. If you have made a custom Nerves system from a previous release, please see the v1.18.0 release notes for upgrading.
Here are the most visible updates from v1.18.3 to v1.18.4:
Processor-specific GCC options are now passed to NIFs and ports. This makes some more optimizations possible and enables features like NEON on some ARM processors.
As part of the Buildroot patch release, Nerves now uses OpenSSL 1.1.1m. This OpenSSL update detects redundant OpenSSL Engine loads which were possible if you were using the NervesKey PKCS#11 library. This is a subtle issue that affects many AWS IoT, Google Cloud, and NervesHub users.
Raspberry Pi and Beaglebone users: WireGuard is available now in your systems. The plan is to include WireGuard on other Nerves systems once their Linux kernel is updated to 5.10. This only includes the small kernel device driver. Userland WireGuard tools should be brought in with your projects. This enables remote access to Nerves devices via a private VPN. Currently this feature requires low-level networking and VPN knowledge to configure.
I did get it to boot by going back to otp-22 and v1.11 on nerves_system_rpi0 so I can continue to learn. On the latest release, I get timeouts trying to ping nerves.local and the blinky leds don’t flash as they do with firmware built on the earlier release. Once I can debug things a bit better I’ll report back. I’ll check the links you provided and appreciate your help!
.
