SystemReady ES support for MacchiatoBin

I’ve had a MacchiatoBin Double Shot board for some time. It runs various services for my local network and generally just works. I run a TianoCore EDK2 firmware on it using ACPI. It’s purely a network device so I don’t bother with any form of graphics and in the very few occasions I need to access it locally I do so via the built in USB serial TTL.

Recently Solid Run announced the MacciatoBin is now SystemReady ES certified. Excellent news! I’ve worked with Arm for some time on both the SytemReady ES (Embedded Server) and SystemReady IR (IoT Ready) standards and recently the certification program has been finalised so it’s nice to start to see the fruits from all the hard work myself, and may others, have done over a number of years appear.

The EDK2 firmware I was running was coming up to two years old and there’s been a number of enhancements to the various components of the firmwares that make up a complete update so I decided to download the latest firmware and update it. Eventually I am sure Solid Run will have these published to LVFS to make the process even easier but I know that to get to this stage has been a LOT of effort so it’s still a great step forward.

The first step of updating a EDK2 firmware is to download it and put it on the EFI partition:

peter@macbin:~ $ wget https://github.com/Semihalf/edk2-platforms/wiki/releases/flash-image-a8k-mcbin.bin_r20210630
peter@macbin:~ $ sudo mv flash-image-a8k-mcbin.bin_r20210630 /boot/efi
peter@macbin:~ $ sudo reboot

On reboot you’re given a prompt to interrupt the boot process. From the menu select the option for the shell:

Shell> fs0:
FS0:\> ls
Directory of: FS0:\
04/06/2021  19:08          4,096  EFI
07/25/2021  17:01           2,855,040  flash-image-a8k-mcbin.bin_r20210630
          1 File(s)   2,855,040 bytes
          1 Dir(s)

FS0:\> fupdate flash-image-a8k-mcbin.bin_r20210630
Detected w25q32bv SPI NOR flash with page size 256 B, erase size 4 KB, total 4 MB
Updating, 99%
fupdate: Update 2855040 bytes at offset 0x0 succeeded!
FS0:\> reset

It then reboots and we’re done, you see a very similar output to previously with some updated versions of various firmware and before long you’re back through grub and running Fedora again. Painless!

I’m really happy to see this is such a straightforward process, and I’m looking forward to seeing more features, enhancements and fixes to the firmware including capsule updates and the associated LVFS/fwupdmgr support, and improvements around firmware security (fwupdmgr –force security). Top marks to the Solid Run team!

Fedora on the Pinebook Pro

First thing to note here is that this is not limited to the Pinebook Pro, I’m just using it as the example for 64 bit Rockchip devices with SPI flash on Fedora. This post is focused on devices with SPI but I’ll do a separate follow-up post for other devices including details for writing to eMMC over USB.

The story of Fedora on the Pinebook Pro, and other Rockchip devices, has been a sordid story of a lack of time, bugs, rabbit holes, more bugs and various other things. Not at all sordid at all really, mostly just a lack of time on my behalf, and nobody else stepping up to assist in a way to benefit all Fedora users, mostly they do one time hacks to sort themselves. Overall the support in Fedora for Rockchip devices has been quite solid for a number of releases. The problem has been with the early boot firmware, notable because without SPI flash it wants to splat itself across the first 8Mb of the disk, and if there was SPI flash it generally wasn’t overly stable/straight forward.

Anyway we’re now in a place where devices with SPI flash should mostly work just fine, those devices without it will work with a little manual intervention, and while the support isn’t complete, and will need more polish, they’re all details we can polish with little interruption to users by standard package updates. By default users will have accelerated graphics and from my testing on GNOME 40 it’s by all accounts a pretty decent experience!

Setting up the firmware

First step is to get the firmware written to SPI flash. This is a two step process, the first is to write out a micro SD card from another device, the second is to boot that mSD card on the Pinebook Pro, or another device like the Rockpro64, and write the firmware to the SPI flash.

There’s some nuances to this process, and the way the early boot firmware works, if another version of U-Boot takes precedence that is likely OK as it should still be able to work, the fall back is to use the internal switch to turn off the eMMC temporarily. I also have no idea if the Pine64 shipped U-Boot has any display output, the Fedora build does, if not you’ll need to use the option to disable eMMC or use a serial console cable. Anyway on to the steps:

Set up the mSD card
Use a mSD card that has no data you wish to keep, this process will wipe it out. You want at least U-Boot build 2021.04-3.fc34, you can adjust the umount to be more specific, and you need to substitute XXX for the media, otherwise it’s a relatively quick and straightforward process:

sudo dnf install --enablerepo=updates-testing -y arm-image-installer uboot-images-armv8
sudo umount /run/media//*
sudo spi-flashing-disk --target=pinebook-pro-rk3399 --media=/dev/XXX

Write the firmware to flash
Now remove the mSD card from your host and put it into the Pinebook Pro. Press the power button, from experience you likely need to press and momentarily hold and in a second or two the display will light up with text output. Interrupt the boot by pressing space. Next up we write out the flash:

Hit any key to stop autoboot:  0 
=> ls mmc 1:1
   167509   idbloader.img
   335872   idbloader.spi
   975872   u-boot.itb
  9331712   u-boot-rockchip.bin

4 file(s), 0 dir(s)

=> sf probe
SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB

=> load mmc 1:1 ${fdt_addr_r} idbloader.spi
335872 bytes read in 39 ms (8.2 MiB/s)

=> sf update ${fdt_addr_r} 0 ${filesize}
device 0 offset 0x0, size 0x52000
61440 bytes written, 274432 bytes skipped in 0.803s, speed 427777 B/s

=> load mmc 1:1 ${fdt_addr_r} u-boot.itb
975872 bytes read in 107 ms (8.7 MiB/s)

=> sf update ${fdt_addr_r} 60000 ${filesize}
device 0 offset 0x60000, size 0xee400
914432 bytes written, 61440 bytes skipped in 9.415s, speed 106127 B/s

Once the last command above has completed eject the mSD card and type reset at the => prompt and the device should reboot and you should see output similar to before but running from the SPI flash!

If you had to turn off the eMMC you can now turn it back on.

Installing Fedora

The nice thing with the firmware on SPI flash it should now work mostly like any other laptop and you can use either the pre canned desktop images (Workstation, KDE, XFCE, Sugar), the Workstation LiveCD iso or the standard everything network installer.

To run the arm Workstation image off a micro SD card or USB stick you can do the following:

arm-image-installer --media=/dev/XXX --resizefs --target=none --image=Fedora-Workstation-34-1.2.aarch64.raw.xz

Note ATM you’ll need to use the USB port on the right hand side, I need to investigate the USB/USB-C port on the left as it appears not to currently work in firmware, but works fine once Fedora is running.

Next steps and improvements

The two biggest issues remaining for the Pinebook Pro is enabling PCIe support and the lack of the brcmfmac firmware, both WiFi and bluetooth, being upstream. For the later issue if there’s anyone from Synaptics that can assist in resolving that problem please reach out to me! A interim WiFi firmware to use is here.

Some things at the Fedora level I’ve not really tested and will do so more, and likely polish with OS updates, in the coming weeks include sound, USB-C port (charging and display output). On the firmware level there’s still some more improvements to be done, tweaks to improve the USB support, turning on the power LED as early as possible to give an indicator, improvements to the EFI framebuffer to ensure consistent early boot output, support for UEFI BGRT to enable smooth boot etc.

For support please email the Fedora Arm mailing list or reach out on IRC via #fedora-arm on Libera.Chat.

Setting the wireless regulatory domain

Different regions around the world use slightly different frequencies for the various wireless interfaces available on your average Linux portable device such as WiFi, Bluetooth and other such interfaces. Overall they fit into larger categories such as 2.4Ghz, 5Ghz etc, but within each of these larger buckets countries have a subset of the frequencies, generally referred to as channels available. For example the 2.4Ghz range used by most WiFi and Bluetooth interfaces has potentially up to 14 channels available, the default is a generic “world” region which uses 11 channels that are available in all regions, but a lot of regions have 13 available for use, and some even have 14. The situation is similar on the 5Ghz range, and no doubt on the higher frequencies now becoming available too.

So to make best use of these while operating in the legal ranges for a country the regulatory domain needs to be set for the device. Linux handles this with three components, the kernel CRDA interface, a signed regulatory DB, which in Fedora is a package called wireless-regdb, but may also be called crda, and the iw tool. In some cases if an access point is using channels outside of the default “world” range you may not even be able to see/connect to the network.

There’s a two ways you can fix this. Firstly straight on the command line with the following command line options. The first shows you the current settings, the next sets the domain for the UK, but setting it this way isn’t persistent, but it’s useful for testing:

iw reg get
iw reg set GB

To make the setting persistent on every boot you just need to set a country in the /etc/sysconfig/regdomain file with a line that looks like this:

COUNTRY=GB

Of course use the code for your country of location based on the standard two letter country codes.

Installing Fedora on the NVIDIA Jetson nano

Update
You need to use the L4T R32.4.4 release, not a later version, with this patch applied for newer Python3 releases.

Overview
Nvidia launched the Jetson Nano Developer Kit in March 2019, since there there’s been a few minor refreshes including a just announced cheaper 2Gb model. I received the original 4Gb rev A device shortly after they were launched.

Over the last year or so as part of my role at Red Hat I started working with some of the NVidia Tegra team to improve support for the Jetson devices. This work has been wide ranging and though it’s taken awhile, with Fedora 33 we’re starting to see the fruits of that collaboration. The first is improved support for the Jetson Nano. The official L4T (Linux 4 Tegra) Jetson Nano images look a lot like an Android phone with numerous partitions across the mSD card. This makes it harder to support a generic Linux distribution like Fedora as there are assumptions by distributions of control they can have over the storage, so while it was certainly possible to get Fedora to run on these devices it generally wasn’t for the faint of heart. As of the recent L4T releases, you definitely want R32.4.4, it’s now a supported option to flash all the firmware to the onboard SPI flash enabling the use of the entire mSD card for the OS of your choice, which as we all know will be Fedora 😉 but the instructions here should be adaptable to work for any distribution.

Before we begin
We do it in two stages, first is to flash the new firmware to the SPI over the micro USB port, second we’ll prepare the Fedora OS for the mSD card. For the first stage you’ll need the latest L4T Release R32.4.4 and the Fedora U-Boot builds installed locally.

Before we get started you’ll need the following:

  • A USB-A to micro USB cable for flashing
  • A HDMI monitor and a USB keyboard
  • A jumper, a jumper wire or something to close the connection on the FRC pins for recovery mode
  • A 3.3v USB Serial TTY (optional)
  • An appropriate 5v barrel PSU (optional)

If you wish to use a serial TTY there’s a good guide here for connecting it to the RevA nano, the RevB has two camera connectors so they’ve moved the serial console headers to near the mSD card slot. The command to see serial output is:

screen /dev/ttyUSB0 115200

Flashing the Jetson Nano
So let’s get started with flashing the firmware. This step with the firmware on the SPI doesn’t have to be done often. First we’ll extract the L4T release and get all the bits installed that we need to flash the firmware:

sudo dnf install -y usbutils uboot-images-armv8 arm-image-installer
tar xvf ~/Downloads/Tegra210_Linux_R32.4.4_aarch64.tbz2
cd Linux_for_Tegra
cp /usr/share/uboot/p3450-0000/u-boot.bin bootloader/t210ref/p3450-porg/

Next, based on instructions from the NVidia Jetson Nano Quick Start Guide, we need to put the Jetson Nano into Force Recovery Mode (FRC) to prepare for flashing the firmware:

  1. Ensure that your Jetson Nano Developer Kit is powered off. There’s no need for a mSD card ATM, we’re just writing to the SPI flash.
  2. Connect the Micro-USB OTG cable to the Micro USB port on the Nano. Don’t plug it into the host computer just yet.
  3. Enable Force Recovery mode by placing a jumper across the FRC pins of the Button Header on the carrier board.
    a. For carrier board revision A02, these are pins 3 and 4 of Button Header (J40) which is located near the camera header.
    b. For carrier board revision B01, these are pins 9 and 10 of Button Header (J50), which is located on the edge of the carrier board under the Jetson module.
  4. Only if you wish to use a separate PSU place a jumper across J48 to enable use of a DC power adapter.
  5. Connect a DC power adapter to J25. The developer kit powers on automatically and enters Force Recovery mode. Note it may be possible to do this with USB power but I’ve not tested it.
  6. Remove the jumper from the FRC pins of the Button Header.
  7. See if you can see the Jetson Nano is in recovery mode by running:
    lsusb | grep -i nvidia

Now we can actually flash the firmware (make sure you’re still in the Linux_for_Tegra directory):

sudo ./flash.sh p3448-0000-max-spi external

You will see a lot of output as the command runs, and if you have a serial TTY you’ll see some output there but eventually you’ll be returned to the command prompt and the system will reset. If you have a HDMI monitor attached you’ll see the NVidia logo pop up, if you have a serial console you’ll see a bunch of output and eventually the output of U-Boot and the associated U-Boot prompt.

Jetson TX1 and TX2
You can basically follow the same instructions above for the older TX1/TX2 devices except for two things. For the TX1 you can use the same L4T release, for the TX2 you need to download a different L4T release.

For the U-Boot copy there’s a different U-Boot for each device which needs to be copied to a different location. For the firmware copy I treat the eMMC as if it was the SPI flash, and run the OS off a SD card, it’s not the most efficient but it keeps things more straight forward:

TX1:

cp /usr/share/uboot/p2371-2180/u-boot* bootloader/t210ref/p2371-2180/
sudo ./flash.sh jetson-tx1 mmcblk0p1

TX2:

cp /usr/share/uboot/p2771-0000-500/* bootloader/t186ref/p2771-0000/500/
sudo ./flash.sh jetson-tx2 mmcblk0p1

Getting Fedora running
Now we have the firmware flashed we can prepare Fedora for the mSD card. Download the Fedora Workstation for aarch64 raw image. You can of course also use XFCE, Minimal or Server images. Put the mSD card in reader and after unmounting any filesystem run the following command (look at the help for other options around users/ssh-keys):

sudo arm-image-installer --media=/dev/XXX --resizefs --target=none --image=~/Downloads/Fedora-Workstation-33-1.3.aarch64.raw.xz

Note you need to replace XXX with the right device, and you don’t need a target option as we’re not writing the firmware to the mSD card.

Once that completes you should be able to pop the mSD card into your Jetson Nano and reset the device and see it boot. You will see all the output if you have a serial console attached. If you’re using HDMI it may take a little while once the NVidia logo disappears for the GNOME first user setup to appear.

Also note that while a lot of things work on this device, like the nouveau driver for display, it’s not perfect yet and we’re actively working to fix and improve the support for the Jetson Nano, most of these will come via the standard Fedora update mechanism. If you have queries please engage in the usual ways via the mailing list or #fedora-arm on Libera.Chat.

Documenting my various arm and IoT devices: quick overview

It’s been around ten years since I got my first arm single board computer, a Beagle-xM, which started me down the route of playing with Fedora on ARM and ultimately to my role in device edge/IoT at Red Hat. Shortly after that time I also moved into my current flat, almost ten years later I finally made the decision to move to a new place.

In the process of unpacking the contents of boxes from the flat into my new home office I thought I would document all my devices. This is mostly for my own reference, but I have little doubt others are interested from previous conversations. I’ve broken the list down into a few broad categories, mostly so the blog post isn’t unwieldy, there’s certainly cross overs between the categories, like some generations of the Raspberry Pi can run in either 32 or 64 bit mode, some Arm SBCs also have an integrated micro controller etc. For simplicity I’m putting those cross over devices in a single list, that of which they’re most capable, I’m also not putting devices on the list that aren’t easily able to run an open source OS such as Linux or Zephyr RTOS as I have numerous micro controllers/phones etc I can’t be bothered with and hence they’re not seen as useful for this list.

The lists, I will update with links as I post them, are going to be as follows:

  • Part one: Arm 64 bit devices (aarch64)
  • Part two: Arm 32 bit devices (ARMv7)
  • Part three: Micro controllers
  • Part four: x86 and other devices

Three ways to speed up dnf on arm devices

I have a large bunch of Arm Single Board Computers I use for testing a lot. Most of the testing ends up being pretty basic stuff like firmware, kernels, and the various bits of hardware peripherals that people use like storage, network, display and sound output, plus things like sensors and HAT support.

The problem is that these devices often aren’t the fastest in the world for various reasons so I want to be able to apply updates to the basic system as quickly as possible to find out the results. Over time I’ve worked out that these three things speed up dnf quite a bit for the sort of testing I wish to do are as follows:

  1. Disable modularity:
    sed -i 's/enabled=1/enabled=0/' /etc/yum.repos.d/fe*mod*
  2. Don’t install weak dependencies:
    echo "install_weak_deps=False" >> /etc/dnf/dnf.conf
  3. Disable dnf makecache. It never seems to be up to date when you need it anyway:
    systemctl disable dnf-makecache; systemctl mask dnf-makecache

You may need to re-do some of these each major update as they seem to want to force you to have them every time.

Fedora package spring cleaning

So it’s meteorological spring, at least in the Northern Hemisphere, and I’m preparing to move house for the first time in almost a decade so of course it’s time to procrastinate and have a spring clean of the packages I maintain!

A number of these I’ve maintained longer than I’ve been in my current flat and like a lot of the contents of my flat I’m not sure why I still have them! A bunch of them I packaged when MeeGo was the coolest thing to run on your Netbook and before GNOME-3 was stable and packaged and I wanted to run MeeGo on Fedora on my ASUS EeePC 901! Then a bunch I’ve acquired over the years because various things I was interested in depended on them. There’s others I actually have no idea why I own them! Anyway, with my day job doing “Device Edge” or “IoT” and with less spare non work time (why yes, apparently I do have a life outside of Fedora, who knew!) I decided it’s high time I relinquished the maintainership of these packages and let someone else love them or allow them to sail off into the sunset of their, probably long overdue, retirement!

So without further ado the list of packages I relinquishing is as follows…. Please reply to the list message or message me on IRC/email (if you know the Fedora packaging process) to (co)maintain something in this list:

* GNOME related:
clutter
clutter-gtk
clutter-gst
cogl
libchamplain
rest

* A UPnP stack, used (or at least used to be) by GNOME and others:
gssdp
gupnp
gupnp-av
gupnp-tools
gupnp-dlna
gupnp-igd
rygel

* Ancient gnome related (please retire or move the deps to copr already):
gamin
libglade2
libgnomecanvas
gnome-themes
ORBit2

* GTK VoIP client. Mostly dead upstream. Has explicit deps/tightly coupled with opal/ptlib:
ekiga
opal
ptlib

* iOS/iMobiledevice - Apple iDevice support:
ifuse
libplist
libusbmuxd
libimobiledevice
usbmuxd

* Random / no idea TBH:
libfakekey (kde-connect-libs)
icon-slicer
telepathy-mission-control
loudmouth

A list of packages that I still have an interest in but would appreciate a co-maintainer:
dotconf
festival-freebsoft-utils
speech-dispatcher
flite
csound

Thoughts on Project Connected Home over IP (CHIP)

In late December 2019 Google, Amazon, Apple and a number of other companies announced Project Connected Home over IP. Like all Internet of Things I thought I would dig into it and see what it’s made up of.

First thoughts before I even began to dig were basically “well they got there eventually!” as I’ve long believed that for IoT in the home to be successful as a whole there needs to be a single set of open standards that all devices speak so that the things can intercommunicate…. you know, just like the internet! But like so many of these things the big companies always attempt to see if they can control the entire market first, then realise they need to “compromise” and work with the other players on standards, which is when the market starts to actually mature and consumers start to win out!

If you look at the project’s web site there’s, at least at the time of writing, 16 company logos on the page, of which around six or seven I would consider household names. A standard such as this was always going to happen. If you look at the “Home IoT Market” it’s a mish-mash of competing and incompatible standards, none of which really have a lead and some of the big names, such as Apple with their HomeKit interface (I refuse to use the term “standard”), have been struggling to get any real level of foot hold in the market. Some of the more popular off the shelf devices have been things like Samsung’s “SmartThings” which implement a number of different radios etc as bridge/gateway devices to make other things work together, which in and of itself speaks volumes. If the companies themselves didn’t get themselves sorted out it would have ended up in governments mandating something. In short the whole category is a big mess!

So reading through the FAQ and various bits in the media about it what does it appear to do? It puts IP over stuff! Shocking right!? To quote the FAQ:

The goal of the first specification release will be Wi-Fi, up to and including 802.11ax (aka Wi-Fi 6), that is 802.11a/b/g/n/ac/ax; Thread over 802.15.4-2006 at 2.4 GHz; and IP implementations for Bluetooth Low Energy, versions 4.1, 4.2, and 5.0 for the network and physical wireless protocols.

So the technologies they’re using are WiFi, no real shock there, although there’s no mention of Wi-Fi HaLow AKA 802.11ah but for home use that’s nothing of note. Next up in Bluetooth LE, 4.1 – 5.0, again no real surprises here, there’s already a standard for IP over Bluetooth LE/mesh in the form of 6LoWPAN, the same as used by Thread and vanilla 802.15.4, slightly interesting they mentioned explicitly 3 versions of BT-LE and just didn’t say BT-LE in general as all versions support IP. The final option mentioned was 802.15.4, the bit that I find particularly interesting here is that Zigbee Alliance was one of the four companies in the original announcement, 802.15.4 is an open radio standard used by Zigbee, Thread, 6LoWPAN directly and a number of other protocols, Zigbee has their own Zigbee IP standard, which competes with Thread and others yet Thread, originally out of Google/Nest is the chosen one. I’ve also found Thread to not really be a completely open standard like TCP/IP, as while there is the OpenThread implementation, you need to be a paying member of the Thread Group organisation to have it certified!

So what else does the project offer? They mention the following but note the term “may include”.:

This may include a proposed standard for lifecycle events such as provisioning/onboarding, removal, error recovery, and software update.

I feel that the lifecycle events they mention are actually extremely important here, and standards in this area are just as important as connectivity standards such as IP for layer 3. If you look at components such as provisioning/onboarding there’s fairly new standards evolving such as the Intel/Arm FIDO secure device onboarding collaboration which are still quite new so I suspect they’re going to wait and watch these before making a decision which is actively a good thing in my opinion if it means one less new standard!

Overall there’s currently nothing actually new on offer here in terms of standards, what is new is a number of large companies committing to focusing on a single Layer 3 connectivity protocol. There’s already widely available hardware across WiFi/Bluetooth/802.15.4 as well as standard IP implementations for them all. This should actively replace Zigbee, Z-Wave and a number of other proprietary Layer 2/3 protocols and should be straight forward for adoption as there’s not actually a lot for anyone else to do.

I feel this is a move in the right direction and will make life easier for a lot of third parties who want their products to work with “the big three of Apple/Google/Amazon”, the move to more open standards is obviously good, but overall there’s really nothing particularly new other than another mechanism for closed companies to work together. I don’t think it’ll ultimately make much difference in general to the open source community as those companies will have their proprietary protocols/APIs sitting on top of IP, just like in other parts of the internet now. It’ll be interesting to see how open the process is once they release code and start to work on it.

Basically it’s a wait and watch so really I’m ¯\_(ツ)_/¯

Zephyr RTOS 2.x on Fedora: Configure the build environment

It’s been a while since I’ve had time to play with the Zephyr RTOS project and the project has evolved greatly since so I thought I’d document the process I went through while playing with Zephyr 2.1 on Fedora using the Fedora native cross toolchains rather than the various ones suggested by the Zephyr Project docs.

I’m going to do a couple of posts in this series to break it up a little. This first one will be getting a generic build environment setup. I’ll go into more detail on the specific devices I’m playing with but the ones I have handy are ARM Cortex-M based so that’s what I’ll be focusing on even though Zephyr RTOS supports numerous architectures.

As before it’s worth reading the latest Zephyr Getting Started guide. This time around I’m using a AWS aarch64 a1.medium instance running a Fedora 31 cloud instance but I’ve also tested that a DigitalOcean Droplet with 2Gb RAM works with the later ZephyrRTOS releases too.

Once you have a Fedora instance up and running install the required dependencies:

# disable modularity, mostly just slows things down.
$ sudo sed -i 's/enabled=1/enabled=0/' /etc/yum.repos.d/fe*mod*

# install core utils, git and cross compilers
$ sudo dnf install git-core cmake ninja-build gperf dfu-util dtc \
xz file python3-pyelftools arm-none-eabi-gcc-cs python3-pip

# requirements for the west (Zephyr meta build tool)
$ sudo dnf install python3-colorama python3-configobj \
python3-configobj python3-docopt python3-pykwalify \
python3-dateutil python3-colorama python3-docopt \
python3-pykwalify python3-packaging

We now install west:

$ pip3 install --user --upgrade west

We now have key build dependencies installed so we can initialise west and clone key repos using west (this will take a little while to do an initial clone run):

$ west init zephyr
$ cd zephyr
$ west update

Setup the Zephyr environment for cross compiling with the distribution tools:

$ export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
$ export CROSS_COMPILE=/usr/bin/arm-none-eabi-
$ source zephyr-env.sh
$ mkdir builds

By default the above uses the git master branch of the Zephyr git repo. If you wish to use a stable branch you can just check it out. The latest stable release is, currently, 2.1 so to use this you can check out the stable branch:

$ git checkout v2.1-branch

With this we now have a Zephyr RTOS development environment setup for building for Arm Cortex-M based devices on Fedora using the distribution’s cross toolchains.

The state of open source GPU drivers on Arm in 2019

I first blogged about the state of open source drivers for Arm GPUs 7 years ago, in January 2012, and then again in September 2017. I’ve had a few requests since then to provide an update but I’ve not bothered because there’s really been no real change in the last few years, that is until now!

The good news

So the big positive change is that there’s two new open drivers om the scene with the panfrost and lima drivers. Panfrost is a reverse engineered driver for the newer Midguard and Bitfrost series of Mali GPUs designed/licensed by Arm, whereas Lima is aimed at the older Utguard series Mali 4xx series of devices. Panfrost, started by Alyssa Rosenzweig, and now has quite a large contributor base, has over the last few months has been coming along leaps and bounds and by the time Mesa 19.2 is out I suspect it should be able to run gnome-shell on an initial set of devices. I’m less certain the state of Lima. The drivers landed in the kernel in the 5.2 development cycle, which Linus just released. On the userspace side they landed in the mesa 19.1 development cycle, but they’ve greatly improving in mesa 19.2 cycle. Of course they’re all enabled in Fedora rawhide, although I don’t expect them to be really testable until later in the 19.2 cycle, but it makes it easy for early adopters who know they’re doing to be able to start to play.

A decent open source driver for the MALI GPUs from Arm had been the last biggest hold out from the Arm ecosystem we’ve been waiting for and it covers a lot of the cheaper end of the SBC market with a lot of AllWinner and some Rockchip SoCs having the MALI 4xx series of hardware, which will use the Lima driver and other lower to midrange hardware shipping with the newer Mali midguard GPUs like in the Rockchip 3399 SoC.

Other general updates

Since I last wrote the freedreno (QCom Ardreno) and etnaviv (Vivante GCxxx series) have continued to improve and add support for newer hardware. The vc4 open drivers for the Raspberry Pi 0-3 generations have seen gradual improvement over time, and there’s a new open v3d driver for the Raspberry Pi 4 which they use from the outset.

The last driver is one that seems to have transitioned to be in limbo is the driver for the Nvidia Tegra Arm platform. While it has an open driver for the display controller, and the GPU mostly works with the nouveau driver, at least on the 32 bit TegraK1 (the upstream state of the Tegra X-series is definitely for another post) they appear to have yet another driver, not their closer x86 driver, but another one (not the latest rev, which is 4.9 based, but the only linkable version I could find) which is needed to do anything fun from an CUDA/AI/ML point of view, I wonder how it will fit with their commitment to support Arm64 for their HPC stack or will that only be interesting to them for PCIe/fabric attached discrete cards for HPC super computer deals?

That brings me to OpenCL and Vulkan for all the drivers above, for the vast majority of the open drivers support for either is basically non existent or in the very early stages of development so for the time being I’m going to leave that for another follow up in this long winded series, probably when there’s something of note to report. The other thing that is looking quite good, but one for another post, is video acceleration offload, there’s been quite a bit of recent movement there too.