Tag: IoT

Getting started with Fedora on the 96boards Dragonboard

Support for this board has been a long time coming, it was originally announced in March 2015 and shipped later that summer. Two years on we can finally add support for it to Fedora. The enablement here will also assist us with supporting the newly announced 600c and 820c boards more quickly. We’re not all the way there yet, there’s still some firmwares that needs to go upstream into linux-firmware, but the improvement is fantastic and it’s been a pleasure working with the 96boards and Qualcomm teams getting to where we are today.

At the moment we support running Fedora off either an micro SD card or a USB stick. We don’t currently support running off the eMMC and currently basically treat that as the location of the firmware. Anyway lets get started!

Updating the firmware

You’ll want to update to the latest firmwares, my board originally had an old firmware without support for PSCI and so it didn’t bring up all four cores or support reboot. OOPS! You’ll need the latest linux rescue images from the 96boards download site. As I write this the latest is the 17.09 release (version 88). Create a directory for this file before you unzip it because it’ll expand all into the current directory. While there we also need a u-boot build that’s prepared for flashing, the upstream support isn’t quite complete, we add a few patches to the Fedora build to get everything working nicely. You can grab a pre-built version here and also get LK firmware build which enables display output.

You’ll need a host with the fastboot utility, in Fedora this is found in the android-tools package, and a micro USB cable. This process is very similar to flashing a phone with a new image, not surprising given the chipset really. If you have a serial console on the board you can follow along on the console but it’s not required for this board.

To put the board into fastboot mode we hold down the volume down button, labeled as ‘(-)’ near the middle USB port and then power it on. Wait around 30 seconds to ensure it’s booted to fastboot. You can test this with the fastboot devices command. You’ll likely want to run the next commands as root, or use sudo, and be in the directory you created with the extracted firmware and u-boot build:

sudo ./flashall
sudo fastboot flash aboot emmc_appsboot.mbn
sudo fastboot flash boot u-boot.img
sudo fastboot oem select-display-panel adv7533_1080p

The flashall command runs a series of fastboot command to write out various early boot firmware to the eMMC, then we write u-boot out to the boot partition, and finally ensure that output is configured to appear on the HDMI port. Assuming you don’t get any errors from fastboot that should be all the firmware done and in place.

Fedora image and further setup

Next up is the Fedora image. I chose the Workstation image, but we also have a Minimal Image and a traditional Server image. GNOME not the fastest in the world as 1Gb of RAM isn’t really enough for GNOME-3 anymore, but it works well enough. On a USB stick or Micro-SD card (I’ve tried both). We need to write out the image, then expand the rootfs (Note: update XXX for the device you’re writing to):

xzcat Fedora-Workstation-27-1.6.aarch64.raw.xz | sudo dd status=progress bs=4M of=/dev/XXX
sudo gparted /dev/XXX (expand the last partition)
partprobe

Next up we need to adjust the kernel command line slightly, mount up the first partition and edit /EFI/fedora/grub.cfg and search for the string cma=256MB and delete it, then add in it’s place the following console=tty1 console=ttyMSM0,115200n8. Next mount the boot partition (partition 2) and create a sym link 

ln -s dtb-4.13.9-300.fc27.aarch64 dtb

. Unmount the partitions and we should be good to go on the Dragonboard.

Plug in a keyboard, mouse (and/or a usb cable for the serial console if you’re going that route) and a HDMI cable, plug in the USB stick or SD card and power it up. If you’re following along on the serial console you should see output straight away, screen might take a little longer.

Once you’ve booted you should be able to complete initial-setup (text or the one from Workstation) and login. To get the WiFI and Bluetooth working you need to install a Radio (WiFi and friends) firmware package which I’ve made into a rpm you can grab from here until it lands into linux-firmware.

What next?

The DragonBoard 410c is pretty functional. I’ve not widely tested sound, the Venus media offload components (we have all the firmware and kernel bits for this), the GPS or some of the other more advanced components but I’ll have more details about those soon. I’ll be documenting the above plus other bits on the Fedora ARM wiki so keep an eye on that or get involved and help out 😛

Securing home networks and IoT for family at holiday time

Many people head home to family at some point over the holiday season, whether that be like today for Thanksgiving in the US, Christian Christmas at the end of December or one of the many and varied holidays. During that time most people that are technical will be asked to help fix or setup various computer or internet related devices that family members that are not so technical have acquired or broken since the last time they ventured home. For me it use to be the regular upgrade/replacement of the Virus Scan and anti malware software. These days it tends to be patching of phones and tablets and all sorts of other devices.

So what can the average technical person do to help minimise risks to family members, or stop them from being part of a large botnet sometime in the future, without making the technology hard or even impossible for family to use, or to minimise the calls throughout the year.

Router

The first port of call should always be the router. Often these just get stuffed in the corner, on a bookshelf or somewhere out of site and forgotten. From a security point of view they are the most important, they are the thing that primarily protects everything else as they’re the ingress/egress point of the network. So what to do and change on these devices:

  • Upgrade the firmware to the latest supported version, and configure it to auto-upgrade if it’s an option. If the last firmware is ancient consider moving to a third party firmware like LEDE Project or an OpenWRT dirivative. Worst case scenario throw it away and give them a new one as their present.
  • Change the admin password.
  • Change the SSID and set a reasonable password.
  • Ensure that the admin interface isn’t available on the WAN link, do a port scan.
  • Turn off port forwarding and UPnP on the router.
  • Switch it to OpenDNS (208.67.222.222 208.67.220.220), Google Public DNS (8.8.8.8 4.4.4.4), the new Quad9, or even better a combination of them so if one service goes down or disappears their internet will still work.

Phones and Tablets

Ensure the phone is set to auto install new OS firmware releases, also ensure that apps are set to auto update and that if the provider, such as Google Play, has a malware scan option in their App store ensure that’s turned on so it’ll clean up any apps that are discovered to be problematic.

TVs, Bluerays and other Media Players

It’s surprising the number of these devices that have network connections and never get updated. In some cases the network functionality is rarely, if ever used, I know I’ve pretty much disconnected all Blu-ray players from networks, turned off the wireless if it has it, and not ever had a complaint. Often it’s better to replace some of old network media devices with ones that are actively maintained such as Google Chromecast, Amazon Fire, Roku etc. It’s also worth checking if any of these devices have the ability to connect to via ad-hoc means and disable that to limit connections to only those that are on the standard home network.

Various IoT devices

IoT devices should generally, if at all possible, be isolated on their own network. This is easy if as part of securing the router you moved it to LEDE or something similar above, and configure it to have a strict deny-by-default policy. Check the existing network for devices that are connected to it. In some cases there may have been a device connected to it some time ago that have long been forgotten about and are no longer in use, or the manufacturer has ceased to exist and they’re just a compromise waiting to happen masquerading as an expensive paperweight. Those that are in use might not be using the IoT/network functionality, if so turn the network off. Those that remain obviously ensure they’re running the latest firmware, set for auto update, and if possible move them to the IoT network. In some cases it might be possible or better to replace connected lighting if it’s some terrible WiFi/Bluetooth globe with something like the IKEA TRÅDFRI system as it has reasonable security, is of good quality and is affordable. Also don’t forget to check for things like doorbells, locks, cameras and other such devices.

Conslusion

Securing the router and associated DNS is by far and large the most important thing to do, it will help mitigate/protect most of the other problems that loom on the inside. But disconnecting, throwing away, replacement of old devices is sometimes the easiest way to fix them too, or else isolating them.

Let me know what else people do, and what I missed.

Overview of aarch64 SBC support in Fedora 27

Support for ARM 64 bit (aarch64) Single Board Computers (SBCs) has been one of the most highly requested features along side the Raspberry Pi. It’s something I’ve been working towards almost as long too. Finally with Fedora 27 I felt we would have enough of the bits in place for a Minimum Viable Product (MVP).

You’ll note from the Fedora change linked above I was very cautious with what we planned to achieve. The change has a very focused list of images: Server, Workstation and Minimal and a limited list of devices: basically the Raspberry Pi 3, the 96boards Dragonboard 410c and HiKey, and a handful of AllWinner devices with a focus on the Pine64 series of boards. The reason for this was I knew there was going to be a lot of low level boot and kernel bits that needed focus and polish and the Fedora 27 cycle was severely limited time and resource wise so the plan was to focus on getting all the core bits into place for Fedora 27 and have a couple of well polished devices and then expand that rapidly for Fedora 28.

The key functionality we were aiming for was a well polished uEFI implementation in u-boot to enable a single install/boot path in Fedora on aarch64 using uEFI/shim/grub2 to boot Fedora on both SBCs and SBSA compliant aarch64 platforms. We now have that platform in place, primarily due to Herculean efforts of Rob Clark and Peter Jones, as well as many others who have provided insight into the deep dark details of the uEFI specification. Fedora 27 will ship with a quite heavily patched, well by Fedora’s standards anyway, u-boot 2017.09 which provides us the core of this functionality enabling us to use a vanilla upstream shim and grub2 to boot a standard Fedora. All this work is already upstream, or making it’s way there in 2017.11. In Fedora 28 there will be even more improvements that will enable us to do a bunch of other cool stuff (that’ll be a post for later!) and also enable much quicker upstream board enablement now all the core bits are in place.

So what do we actually support? Well all the usual bits that you would expect on a standard Fedora install, whether it be x86_64, ARMv7 or aarch64, like SELinux, containers, desktops and all the other bits. There’s a few bits and pieces that are a little rough around the edges but overall the feature is pretty robust. On a board by board feature set lets break the this down across the boards:

Raspberry Pi 3

The support for the Raspberry Pi3 is the equivalent to the ARMv7 support but with boot via uEFI/grub2. The memory isn’t quite as good as on 32-bit but that’s to be expected, overall it’s pretty reasonable for a device of the specs and cost. Like on 32 bit support we’re seeing regular improvements each release and throughout the releases. The aarch64 support for the RPi3 is just an evolution to this.

DragonBoard 410c

The support for the DragonBoard 410c is looking pretty decent. Qualcomm has been doing a pretty decent effort to get stuff upstream, we have firmwares for the GPU and for video decode/encode upstream as well, along with kernel drivers and the open freedreno 3D drivers, HDMI audio should work as well. The WiFi firmware isn’t yet upstream but I’ll document how/where to get that and hopefully that should be in linux-firmware soon as well. Overall I’m quite happy with the status of this device, although like all devices with 1Gb RAM it’s a little constrained, but that should make the newly announced 820c with 3Gb of RAM a decent device ;-). All the details for getting it running will soon be in the Fedora 96boards wiki page.

HiKey

Most features and functionality of the HiKey are supported, note this isn’t the HiKey960 (look to F-28 for support for that), except accelerated graphics due to the use of a MALI GPU. Other than that the functionality is pretty decent. You’ll likely want the latest tianocore firmware and the details for that can be found on the Fedora 96boards wiki page.

Pine64 (AllWinner A64 SoC)

We actually should have a number of devices based on the AllWinner A64 SoC working here but we’ve only tested the 3, 2Gb/1Gb/512Mb, Pine64 device sizes. The support for these devices is headless and you will need a serial console else you’re on your own as none of the display bits in the kernel have made it upstream, and of course the GPU is a MALI 400 series so when it does it won’t be fast. The support for the rest of the device is basic, it’s usable for a headless server style device, we support network, USB, KVM, RTC and a few other bits. Other than display we don’t yet support the SDIO attached wireless, sound, crypto offload or any of the other media interfaces. A lot of this is under review upstream so I think Fedora 28 should look much better for this series of devices and 4.15 might even bring very basic console output. Speaking of series of devices which ones should actually work other than the three Pine64 devices? Well the following A64 SoC devices have a Fedora built u-boot and kernel DT support so should work as well as the Pine64: BananaPi-m64, OrangePi Win, SoPine baseboard (PineBook boots if you’re happy with serial console), NanoPi-A64 and the A64-OLinuXino. We had some troubles with the AllWinner H5 SoC devices earlier in the cycle but I’ve had a couple of reports that it seems to be resolved so they should work too and that adds the Orange Pi PC2, Prime and Zero+ 2 as well as the NanoPi NEO2. So that’s around a dozen or so devices! 🙂

Other ARM64 SBCs

I’ve had reports that other aarch64 SBCs boot on Fedora just fine. I’ve not listed those where I can’t verify whether they boot with our uEFI enabled u-boot. Looking around on my desk I do have a number of devices that I expect us to be supporting in Fedora 28, or maybe even just enabling u-boot bits in a F-27 update.

Overall I’m pretty happy with the state of Aarch64 SBCs for Fedora 27 and what we’ve managed to achieve is such a short cycle!

Raspberry Pi improvements in Fedora 26

So since I landed support for the Raspberry Pi 2 and 3 just in time for Fedora 25 Beta it’s been a bit of a fun ride. The support for Raspberry Pi is mostly done in my spare time along side all the other responsibilities I have and it’s been interesting to see people’s feedback. Going into Fedora 25 I knew it wasn’t going to be perfect but the experience was going to be reasonable for newbies to get going without generally needing serial consoles and it met Fedora’s (and mine) exacting standards on free drivers. I think we achieved that quite well but I also learned a lot in the Fedora 25 cycle and what’s coming in Fedora 26 is quite a substantial jump forward.

Hardware for a good experience

So what have I learned about the first six months or so of Raspberry Pi in Fedora? Well there’s a couple of things that the user can do to ensure a decent starting experience themselves. The biggest FAQs I’ve dealt with on the various support forums are generally fixed by these three things:

  • A proper spec power supply. For the RPi2 this means at least 2 AMPs and for the RPi3 at least 2.5 AMPs. If you want to plug in USB WiFi dongle and a USB HDD you’ll likely want to add a little more! In most cases an old phone charger will not suffice.
  • A good quality Class 10 micro SD card. I generally use Samsung EVO or SanDisk Ultra cards.
  • A Raspberry Pi 2 or 3. Yes, it’s surprising how many people hope to run it on something else. SORRY (actually, I’m not!)!

What’s in Fedora 26 Final

So enough of what to do! Everyone wants to know what improvements arrived in the Fedora 26 Final with the 4.11.x kernels:

  • Pi3 WiFi: It’s been working in F-26 since Alpha and is surprisingly stable. There’s a file you need to grab to enable it. See details in the wiki here.
  • Performance: In the process of dealing with wifi I worked out one of the reasons we were seeing poor performance on the SD card. We’ve had some minor improvements in F-25 but this fix over doubles the performance for me on the SD card.
  • HDMI video: There’s been issues around certain monitors crashing the video (vc4) driver and people getting black screens during boot. While this isn’t perfect yet (ain’t hardware great!!) it’s greatly improved across numerous devices.
  • Composite video: We’ve had support for the composite video since 4.10 but I need people to help test this.
  • Sound: HDMI audio is supported, I’ve done minor testing with the one HDMI audio capable device I have. Analogue audio out isn’t upstream yet.
  • HAT support: We now have all the support needed to do overlays in the kernel/bootloader and dtc stack. I just need to test it some more, document it and work out how we can best distribute pre built overlays to ease consumption. There’s still no consensus on an Overlay Manager from upstream to auto load overlays based on EEPROM on the HATs. In a lot of cases you want to load the overlays from u-boot anyway for things like display. Look out for docs and blog posts on this soon!

What arrived with the 4.12 kernel rebase

  • Thermal support: so if the RPi runs too hot it’ll slow it down
  • More performance improvements and tweaks.

What’s coming in the 4.13 kernel rebase

  • Bluetooth support: upstream finally tracked down the issues here. It’s been a much requested features and I should have the bits in place soon!
  • More performance, stability and graphics improvements and tweaks.

What about Fedora 25?

Some of the above pieces will be coming to Fedora 25 with the 4.12 rebase. The focus of my spare time is Fedora 27 mostly now, with the above coming to F-26. Some components are a lot harder to back port without issues or a complex series of package updates to ensure smooth upgrade. The WiFi and performance improvements were the hardest as part of that change moves around the use of hardware blocks and drivers. I managed to stop both the RPi2 and RPi3 booting numerous times in testing before I properly realised the implications of the change. Getting these changes for users back into a stable release without issues is hard and time consuming to do across all the various use cases. I tried this with some fixes in 4.9 and ended up making the RPi3 very unstable. This cost me a lot of time to debug and fix and I don’t really want a repeat of that!!

Graphics device

One of the surprising side effects was the discovery of a device that is five years old is that Fedora suffered from early adopters issues. We were one of the first distributions to adopt a fully upstream open kernel and graphics stack and with that came a number of issues around monitor detection, especially older/cheaper models that aren’t 1920/1080 “Full HD” or via HDMI to VGA adapters. We’re still working through these with upstream and have improved the situation quite a bit in Fedora 26 overall but it takes time and reproducible use cases which with random hardware isn’t easy or quick! 🙁

Next up?

I’ll leave Fedora 27 features and functionality for another, this post has been sitting in my drafts folder since June so it’s time to get it out and like my development move on to Fedora 27!

Getting started with Zephyr on Fedora

So while Fedora is great for a lot of IoT use cases it can’t be used everywhere, such as on tiny micro controllers such as an ARM Cortex-M series or Intel Quark micro controllers, but that doesn’t mean that Fedora doesn’t make a fantastic developer platform for working with these devices.

I have a handful of Zephyr capable devices (BBC Micro:bit, NXP FRDM-K64F, 96Boards Carbon, TI CC3200 LaunchPad) so how can you get a build environment up and running quickly so you can start doing real development as quickly as possible.

In testing this I used a Digital Ocean cloud instance for a build host. Wherever you choose to build it make sure you have at least 2GB of RAM available as from my experience you need at least 2GB for building a Zephyr image.

From there we diverge a little from the upstream notes by installing the Fedora ARM cross compiler (only tested with ARM, not sure of state of other targets) and developer tools:

sudo dnf install git-core gcc gcc-arm-linux-gnu glibc-static libstdc++-static make dfu-util dtc python3-PyYAML

Next up we clone the upstream Zephyr git repository:

git clone https://gerrit.zephyrproject.org/r/zephyr zephyr-project

If we want to use a particular stable branch we now switch to the chosen branch. I’m using the latest stable release branch:

cd zephyr-project; git checkout v1.7-branch

Set up the cross compiler variables:

export GCCARMEMB_TOOLCHAIN_PATH="/usr"
source zephyr-env.sh
cd $ZEPHYR_BASE/samples/hello_world

Select and build our target:

make CROSS_COMPILE="/usr/bin/arm-linux-gnu-" DTC=/usr/bin/dtc BOARD=96b_carbon

If we’re developing this on our local machine we can now just directly flash the new build straight to the device. To do this we connect a micro USB cable to the USB OTG port on the Carbon and to your computer. The board should power on. Force the board into DFU mode by keeping the BOOT0 switch pressed while pressing and releasing the RST switch.

Confirm DFU can see the device:

$ sudo dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [0483:df11] ver=2200, devnum=8, cfg=1, intf=0, path="2-1", alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="123456789"
Found DFU: [0483:df11] ver=2200, devnum=8, cfg=1, intf=0, path="2-1", alt=2, name="@OTP Memory /0x1FFF7800/01*512 e,01*016 e", serial="123456789"
Found DFU: [0483:df11] ver=2200, devnum=8, cfg=1, intf=0, path="2-1", alt=1, name="@Option Bytes  /0x1FFFC000/01*016 e", serial="123456789"
Found DFU: [0483:df11] ver=2200, devnum=8, cfg=1, intf=0, path="2-1", alt=0, name="@Internal Flash  /0x08000000/04*016Kg,01*064Kg,03*128Kg", serial="123456789"

Flash our build onto the device:

sudo dfu-util -d [0483:df11] -a 0 -D outdir/96b_carbon/zephyr.bin -s 0x08000000

Now connect another micro USB cable to the UART port and run a console:

sudo screen /dev/ttyUSB0 115200

Hit the reset button and you should see the following output:

***** BOOTING ZEPHYR OS v1.7.1 - BUILD: Jun  6 2017 14:07:24 *****
Hello World! arm

Now we have a basic development environment setup, know we can build, flash and run a release on the 96boards Carbon next time we can do something more advanced 😉

Update (2017-06-13): Minor updates to dependency installs and make command

WiFi on Raspberry Pi 3 for Fedora 26 Alpha

So I managed to land just about everything needed for the WiFi on the Raspberry Pi 3 for Fedora 26 Alpha (around 4.11 rc3). There’s one thing missing, because we can’t currently redistribute it, but it’s straight forward for the end user to do themselves once they’ve done the initial setup:

sudo curl https://raw.githubusercontent.com/RPi-Distro/firmware-nonfree/master/brcm80211/brcm/brcmfmac43430-sdio.txt -o /lib/firmware/brcm/brcmfmac43430-sdio.txt

Or you can also do it when you’re flashing the image if you mount the root filesystem but the above is likely easier. It’s been surprisingly stable in my testing.

Before you all ask, at the moment I don’t plan on pushing this to earlier Fedora releases, as the upgrade path is not trivial. I will also soon publish more details of some of the other new features coming for the Raspberry Pi to Fedora 26 but I thought you’d all like the WiFi details now. The wiki has also been updated to reflect the status of the WiFi.

PS: No this is not an April Fool’s joke (it’s well past midday in UK).

Connect to a wireless network using command line nmcli

I use a lot of minimal installs on various ARM devices. They’re good because they’re quick to download and you can test most of the functionality of the device to ensure it’s working or to quickly test specific functionality but of course it doesn’t have a GUI to use the nice graphical tools which are useful to quickly connect to a wifi network or other things.

This where nmcli comes in handy to quickly do anything you can do with the GUI. To connect to a wireless network I do:

Check you can see the wireless NIC and that the radio is enabled (basically “Airplane” mode):

# nmcli radio
WIFI-HW  WIFI     WWAN-HW  WWAN    
enabled  enabled  enabled  enabled 
# nmcli device
DEVICE  TYPE      STATE         CONNECTION 
wlan0   wifi      disconnected  --         
eth0    ethernet  unavailable   --         
lo      loopback  unmanaged     --

Then to actually connect to a wireless AP:

# nmcli device wifi rescan
# nmcli device wifi list
# nmcli device wifi connect SSID-Name --ask

And that should be enough to get you connected. You can list the connection with nmcli connection and various other options. It’s pretty straight forward.

Getting started with MQTT using the Mosquitto broker on Fedora

MQTT is a lightweight publish/subscribe messaging transport designed for machine-to-machine “Internet of Things” connectivity. It’s been used in all sorts of industries from home automation and Facebook Messenger mobile app to health care and remote monitoring over satellite links. Its ideal for mobile apps and IoT because of it’s small footprint, low power usage and small data packets. You can connect to a MQTT Broker over standard TCP/IP ports with or without TLS or over Web Sockets. There are many cloud based MQTT services such as OpenSensors, CloudMQTT, HiveMQ, AWS IoT or Azure IoT Hub but where is the fun in that?

There’s a few message brokers that support MQTT in Fedora including RabbitMQ or ActiveMQ (the version in Fedora is old but it would be nice if someone did update it to the latest version!) but for this I’ll be using Mosquitto as it’s small and relatively straight forward for home and demo usage.

Initial Install
I’ve tested this on a Digital Ocean Fedora 23 VM but for this I’ll be using a Beagle Bone Black with a Fedora 24 Beta minimal image but of course you can run it on any recent Fedora release on any supported device, ARM or otherwise.

After installing Fedora and getting it running on the network install and configure mosquitto:

  dnf install -y mosquitto screen
  mv /etc/mosquitto/mosquitto.conf.example /etc/mosquitto/mosquitto.conf
  firewall-cmd --permanent --add-port=1883/tcp
  firewall-cmd --permanent --add-port=1883/udp
  firewall-cmd --permanent --add-port=8883/tcp
  firewall-cmd --permanent --add-port=8883/udp
  systemctl enable mosquitto.service
  systemctl start mosquitto.service

By default the default settings are relatively straight forward, it runs under the mosquitto user, listens on all interfaces, with config options in /etc/mosquitto. In there is a well documented example config file called mosquitto.conf.example which contains all the default settings. Above we rename it to mosquitto.conf to use as a base config for us to modify. There’s details on using the Let’s Encrypt service on the mosquitto site. If you’re using it on the public internet I’d strongly suggest you configure TLS.

Testing it works
Now that we have a basic install done lets make sure it works and get a basic idea of how MQTT works. Included in the mosquitto package is a couple of client utilities useful for testing the MQTT broker pub/sub functionality. Start up a screen session and in a window run the following commands which subscribes us to the “test/topic” topic to the MQTT broker running on localhost:

  mosquitto_sub -h localhost -t "test/topic"

Now lets publish some data to that topic. In another screen tab run the following command which will publish a string of text to the topic:

  mosquitto_pub -h localhost -t "test/topic" -m "Hello World!"

You can run multiple subscribers either from the screen session or remote from a different host but remember to change the “-h localhost” to appropriate hostname/IP if you’re testing remotely.

MQTT can also use two types of wild cards when subscribing to topic names. So to be able to read all temperature sensors publishing to a root topic you could use “home/+/temp” which would provide “home/bedroom/temp” and “home/livingroom/temp”. The “+” will match one hierarchical level where as “#” stands for everything deeper so “home/garden/#” would provide all sensors from the garden. When using wild cards you’ll need to know which topic is reporting so use mosquitto_sub in verbose mode:

  mosquitto_sub -h localhost -v -t "test/#"

Quality of Service
One of the killer features of MQTT for low power IoT sensor networks is that it’s a “store and forward” protocol with a couple of options for quality of service (QoS) guarantees. Once the node has registered with the broker any time it sleeps the broker will queue messages and take care of delivering that message to the node as soon as it reconnects. This means the node can sleep as long as needed to preserve battery life and just wake up and connect when it has data to send or at a predetermined interval without ever missing a message.

There’s three things needed to support QoS: 1) The subscriber needs to be registered by ID with the broker 2) The subscriber needs to disable clean-slate behavior (the default is enabled) 3) Both the publisher and subscriber need to be using quality-of-service level one or two so the broker knows it needs to store the messages. More details on QoS levels are covered here.

Here’s a small demo to play with QoS basics. First connect a subscriber to the broker supplying an ID, disable clean slate and enabling QoS level 1:

  mosquitto_sub -h localhost -v -t "test/#" -c -q 1 -i "PotPlant"

Then send the following two messages, one each with and without QoS. You should see them both show up on the subscriber:

  mosquitto_pub -h localhost -t "test/topic" -m "foo" -q 1
  mosquitto_pub -h localhost -t "test/topic" -m "bar"

Now stop the subscriber (Ctrl+c) and while it’s stopped send both of the messages again before restarting the subscriber. When it reconnects you should just receive the “foo” message because it’s the only one specifying a QoS level.

Further Reading
There’s a lot of information about MQTT on the web. The MQTT Essentials page from HiveMQ is a good place to start for further information and Awesome-MQTT is a curated list of MQTT related stuff with everything from language bindings to gateways/plugins for integration with various projects whether they be home audio or enterprise products.

Lipstick on a Pig AKA the Raspberry Pi 3

So while waiting for local scratch kernel builds for much more interesting devices I started looking around to see if I could find details of the kernel sources for the new BCM2837 SoC that is centre stage in the Raspberry Pi 3.

The problem is I couldn’t. What I did find is the hack the Raspberry Pi Foundation uses to boot the RPi3 on github.

So there is no source code release for the new BCM2837 SoC, just a device tree file. Someone said to me “They’re violating the GPL” and before people get out their pitch forks… they’re NOT because this is the code they ship, they are meeting their obligations there.

So for the lay person (yes, I know there’s a lot of deep level tech details I’m glossing over deep ARM architecturey people!!) basically what they are doing is booting this device as a ARMv7 device, and because the code isn’t built for ARMv8 (32 or 64 bit) they really just get the speed bump of a ARMv7 device running a bit faster, and possibly some better memory speeds and other general improvements.

So what does this mean for other distributions that wish to actually to support the Raspberry Pi 3 as a aarch64 device? You currently can NOT do so!. Why? Basically it boils down to two things:

  • Source code release for the kernel: To be honest I don’t think this should be large. People with low level knowledge of ARMv7 and the BCM283x could probably hack this up
  • Firmware support: I suspect there will need to be a new firmware that supports booting this as a aarch64 device. I obviously don’t know for sure but I’m guessing the firmware will need changes to actually properly boot this as a aarch64 device. I’ve little doubt there’s a bunch of hackery going on in there!

Of the above two, if my theory is correct, the firmware is the problematic one because it relies on the Raspberry Pi Foundation to do the work. This work for something that they feel, at the moment, gives them no particular gain but only confusion about multiple OSes. They are of course correct for their use case, basically like old school enterprise where you buy a bigger server to scale vertically because your app won’t scale horizontally, but this is another kick in the guts of the Open Source community they so heavily rely on! Oh well, it’s about as much as I expected from the Raspberry Pi Foundation as after all their devices are only just now becoming usable with upstream kernels and open userspace GPU drivers…. after a mere four years.

So what does this mean for Fedora? Basically the only way we’ll be able to support it in the short, possibly medium, term is like it’s sibling the Raspberry Pi 2 as an ARMv7 device but with added shitty wifi. Really, this device isn’t a cheap aarch64 device, it’s just like lipstick on a pig! If a cheap aarch64 device is what you want one of those go and buy a PINE64.

On the plus side the work needed to support it as a ARMv7 device at the same time as it’s sibling should just be some minor u-boot and kernel device tree patches on top of what I previously documented . Note I’ve not looked closely at this as yet, I’m still waiting for mine to arrive (YAY day 3 of 1 day shipping)! Frankly I’d sooner support it this way, an aarch64 device with terrible USB2 IO and 1GB of RAM won’t provide much, if any, of a perf bump over ARMv7, and then have the Raspberry Pi Foundation spend their time working with Broadcom on fixing the wifi and enabling distribution of the wifi firmware in linux-firmware as proper opensource broadcom wifi support would have a wider impact on the Open Source community the Foundation relies upon!

My ARM grab bag device list

They say the first step of coming to terms with addiction is admitting you have a problem… I have a problem with collecting ARM devices… there I said it! How big is this problem you ask? How about I list them out and let you decide!

I’ll break the list down into categories as I believe it’s big enough to do so :-/

The aarch64 set of devices currently stands at:

  • 2x Applied Mustang (different x-gene SoC revs)
  • AMD Seattle
  • 96boards HiKey (hi6220)

The ARMv7 boards list is currently:

  • Compulabs Trimslice (tegra-2)
  • Toshiba AC100 (tegra-2)
  • nVidia Jetson TK1 (tegra-124)
  • Acer Chromebook (tegra-124)
  • BeagleBoard xM (omap3)
  • Nokia n900 (omap3)
  • Nokia n950 prototype (omap3)
  • BeagleBone (am33xx)
  • BeagleBone Black (am33xx) x3
  • BeagleBone Green (am33xx)
  • PandaBoard ES Prototype (omap4)
  • PandaBoard ES B2 (omap4)
  • CubieBoard (allwinner-a10)
  • CubieTruck (allwinner-a20)
  • Banana Pi (allwinner-a20)
  • C.H.I.P. Alpha x2 (allwinner-r8)
  • Snowball (u8500)
  • Compulabs Utilite (imx6q)
  • WandBoard Quad revb (imx6q)
  • novena board (imx6q)
  • RIoTboard (imx6s)
  • UDOO Neo (imx6sx)
  • Origen (exynos-4)
  • OLPC XO 1.75 – a number of variants (mmp2) xNumerous
  • OLPC XO-4 including XO-Touch (mmp3) xNumerous
  • Linksys WRT1900AC (armada-xp)
  • Mirabox (armada-370)
  • ifc6410 (qcom)
  • Parallella Board (zynq7000)
  • Raspberry Pi 2 x3

The Cortex-M series for IoT sensors is currently:

  • TI SensorTag 2015
  • ARM mBed IoT starter kit
  • BeeWi SmartClim

Other random related bits:

  • BeagleBone Breadboard Prototyping Cape x2
  • BeagleBone CryptoCape
  • Original 256Mb Raspberry Pi model B
  • Grove starter kit for BeagleBone Green
  • Explorer HAT
  • PiGlo HAT
  • TI CC2531 802.15.4 USB dongle x3
  • numerous random sensors

So the list above is the devices that I use for hacking on. I count 41 without listing out the dozen or so ARM based XOs I have (various prototypes and models). I also don’t have in that list phones, tablets and two drones as I don’t really hack on those as it’s not like with the list above I don’t already have enough toys! So do I have a problem?