Category: Fedora

Installing Fedora on the NVIDIA Jetson nano

Updated – Aug 2021
You now used the latest R32.6.1 release and it now works with the latest Python releases. Some minor edits below.

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.6.1 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/Jetson-210_Linux_R32.6.1_aarch64.tbz2
cd Linux_for_Tegra
cp /usr/share/uboot/p3450-0000/u-boot.bin bootloader/t210ref/p3450-0000/

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

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.

Raspberry Pi improvements in Fedora 29

So Fedora 29 is probably going to account for the largest single improvement to support on the Raspberry Pi support in Fedora since we added initial support in Fedora 25. It certainly wasn’t without issue, but after quite a bit of debug we’ve got the post release issues with the WiFi back to being stable!

WiFi improvements
The support for upstream NVRAM files and the ability to add those files to linux-firmware means we get WiFi support for the Raspberry Pi 3 Series of devices out of the box! No need to grab anything, it just works! Well mostly, we had some issues with WiFi being very intermittent, as well as a missed bug around aarch64 but now with the 4.19.10 kernel everything appears to be working and stable. This makes me very happy and it took longer than I had hoped but we’re there. This device specific NVRAM driver support will also help another bunch of cheap Arm and x86 based devices that ship with Broadcom/Cyprus based WiFi support moving forward.

ZRAM enabled by default
By supporting and enabling ZRAM swap by default we get a more responsive device and less wear on the MicroSD storage. Over all we’ve seen reasonable performance improvements and to no date no major issues.

GNOME performance improvements
In May 2018 the Raspberry Pi Foundation kindly hosted a GNOME Performance Hackfest in the lovely Cambridge. Over a couple of days we managed to fix a number of issues seen, review and document a number of issues and work on a number of ways of reducing the memory usage of GNOME. Of course this improvement is primarily seen constrained devices like the Raspberry Pi but ultimately less memory utilisation by GNOME even helps devices with decent amounts of RAM and CPUs too. The fixes didn’t arrive in time for Fedora 28, but a bunch have landed in Fedora 29 providing noticeable improvements, and the GNOME team is by no means done and there will be more coming in Fedora 30 and beyond! It was an excellent start and I expect there will be ongoing enhancements here into the future especially with devices like the Purism Phone which will have similar constraints.

Initial CPU frequency support
Another of the largest issues around the Raspberry Pi is complaints it was slow, part of the issue here is that there’s no upstream CPU Frequency driver which means all models of the Raspberry Pi run at a glacial, but safe, 600Mhz out of the box compared to the highest speed, which on the 3B+ is 1400Mhz. With Fedora 29 we’ve landed an experimental cpufreq driver which allows us to run the Raspberry Pi 3-Series at much closer to optimal speeds. While this is experimental it might not stay around if we find out it causes issues or ends up being a maintenance burden but to date it hasn’t yet appeared to have caused any issues.

HWmon Voltage Sensor
There’s a new driver that reports when the voltage supplied by the PSU drops below the required voltage. It can be a bit noisy in dmesg but one of the biggest support problems we have with the Raspberry Pis is people using a power supply that’s not powerful enough, this issue is more of a problem with Fedora 29 because with the support for running at faster frequencies due to the cpufreq driver it means we also draw more power and some PSUs that were previously fine now cause issues because they can’t supply enough current.

Enhanced support for config.txt
A lot of the hardware addons are supported in Raspbian are done by enabling things in the config.txt file, this in turn does things like loading DT overlays and merging them with the base DT to enable extra hardware like HAT support. We have enhanced the way Fedora works with this which enables us to be much closer to the way Raspbian handles these things. The advantage this has is that the documentation that’s written for Raspbian is then usable by Fedora in the wider Raspberry Pi ecosystem which in turn makes it easier for end users to get HW up and running due to less differences in process. There’s further enhancements to make here but every step closer is easier for everyone to enable and use their favourite HATs.

Improved bcm283x firmware support
In preparation for grub2 support we enhanced how we deal with the firmware that the Raspberry Pi uses for booting. This deals with the early startup. We never use to upgrade it by default to ensure things didn’t break, but it also meant most users also didn’t by default get the fixes and enhancements. Now we do. The config.txt is also handled directly which means if you never edit the file you now automatically get any changes we make, because rpm handles the file as a config file, if we change it you get a .rpmnew file so you won’t lose your changes.

Camera support
This wasn’t available in the Fedora 29 4.18 kernels, but with the rebase to the 4.19 kernel the support for the camera on the Raspberry Pi CSI Camera interface improved enough we could enable this in Fedora. The early 4.19 kernels don’t automatically detect and load support if the camera module is attached. There’s some patches in 4.20 in rawhide for this, and we’ll bring some of this to 4.19 soon, and we’re working with upstream to further improve the camera support. You’ll also want the latest bcm283x firmware which tweaks some of the config.txt and updates to a firmware with ISP fixes.

Another improvements
There was also a number of general Arm improvements which sped up crypto on the Raspberry Pi, improved the USB, fixed up some issues with the wired ethernet on the 3B+, power and a number of other fixes. As always there’s more coming. The 4.20 kernel rebase should also bring with it analog sound support early in the new year.

Conclusion
Overall I was pleased with the work that landed in Fedora over 2018 for the Raspberry Pi. The WiFi regression was disappointing, but now with that fixed in 4.19.10 we have WiFi support out of the box without users needing to download anything which moving forward will make things a lot more straight forward. The initial support for the camera makes it much more useful in numerous use cases and we’ll really polish up the HAT support in Fedora 30 which for me is the last remaining big ticket item for Raspberry Pi support. There’s still some annoying bits around the EDID detection in the display, but there’s work to improve that upstream, and also there’s work to land the media decode offloading upstream too which will also one of the few remaining bits.

Using ZRAM as swap on Fedora

One of the changes I did for Fedora 29 adding using ZRAM as swap on ARM. The use of compressed RAM for swap on constrained single board computer devices has performance advantages because the RAM is an order of faster than most of the attached storage and in the case of SD/emmc and related flash storage it also saves on the wear and tear of the flash there extending the life of the storage device.

The use of ZRAM as swap isn’t limited to constrained SBCs though, I also use it on my x86 laptop to great effect. It’s also very simple to setup.

# dnf install zram
# systemctl enable zram-swap.service
# reboot

And that’s it! Simple right? To see how it’s being used there are three commands that are useful:

# systemctl status zram-swap.service
● zram-swap.service - Enable compressed swap in memory using zram
   Loaded: loaded (/usr/lib/systemd/system/zram-swap.service; enabled; vendor preset: disabled)
   Active: active (exited) since Tue 2018-10-09 22:13:24 BST; 3 days ago
 Main PID: 1177 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   Memory: 0B
   CGroup: /system.slice/zram-swap.service

Oct 09 22:13:24 localhost zramstart[1177]: Setting up swapspace version 1, size = 7.4 GiB (7960997888 bytes)
Oct 09 22:13:24 localhost zramstart[1177]: no label, UUID=d79b7cf6-41e7-4065-90a9-000811c654b4
Oct 09 22:13:24 localhost zramstart[1177]: Activated ZRAM swap device of 7961 MB
Oct 09 22:13:24 localhost systemd[1]: Started Enable compressed swap in memory using zram.
# swapon
NAME       TYPE      SIZE   USED PRIO
/dev/zram0 partition 7.4G 851.8M   -2
# zramctl
NAME       ALGORITHM DISKSIZE   DATA  COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 lz4           7.4G 848.3M 378.4M 389.9M       8 [SWAP]
#

When I was researching the use of ZRAM there was a lot of information online. A lot of implementations sliced up the zram into multiple slices to enable the balancing of the slices across CPUs, but this is outdated information as the zram support in recent kernels is now multi threaded so there’s no performance advantage to having multiple smaller swap devices any longer, and having a single larger swap space allows the kernel to be more effective in using it.

In Fedora all the pieces of the Fedora implementation are stored in the package source repo. So those that are interested in using zram for other use cases are free to test it. Bugs and RFEs can be reported as issues in pagure or in RHBZ like any other package.

Increasing a libvirt/KVM virtual machine disk capacity

There’s a bunch of howto’s on the internet for increasing the size of a virtual disk of a VM. Of course the best is to use the very useful libguestfs-tools options but there’s been some improvement in tools like sfdisk so I thought I’d document what I did for reference using tools I already had installed.

First shutdown the VM. Once it’s shutdown you need to work out where the disk is located. As this VM is running from my local machine and is just using a raw disk this is straight forward. You can get the details from the virt-manager GUI or virsh dumpxml VM-Name.

Next up we use qemu-img, it’s installed by default with the libvirt stack, to add the extra space we need, in theory this can be done with the VM online, this is a random test VM so online time doesn’t matter, and of course if the VM matters to you there should be a proper backup done first! The fdisk isn’t necessary, it just allows you to see that the extra space is there.

# qemu-img resize /var/lib/libvirt/images/VM-Name.raw +4G
# fdisk -l /var/lib/libvirt/images/VM-Name.raw
Disk /var/lib/libvirt/images/VM-Name.raw: 8 GiB, 8589934592 bytes, 16777216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe8b201aa

Device                                            Boot   Start     End Sectors Size Id Type
/var/lib/libvirt/images/VM-Name.raw1 *       2048 2099199 2097152   1G 83 Linux
/var/lib/libvirt/images/VM-Name.raw2      2099200 8388607 6289408   3G 83 Linux
#

Now power up the VM, login as root (or use sudo) for the next bits on the VM. The sfdisk tool has had a bunch of improvements over the last few years for partitioning. If you’ve not used it or looked at it recently I recommend checking the well written man page. Here I’m just expanding last partition (partition 2) on the disk to the maximum size the disk offers. For all the other possibilities “man sfdisk” is your friend!

# echo ", +" | sfdisk -N 2 /dev/vda --no-reread
# partprobe
# resize2fs /dev/vda2

And with that you should be good to go, df and friends will show you the new space, no reboot needed! The VM I have here is very basic partitions, no LVM etc so straight forward, if you have LVM there’s lots of docs on how to deal with that elsewhere.

Fedora on the UDOO Neo

Some time ago I backed the UDOO Neo Kickstarter as it looked like a nifty, well featured, IoT device. I got the full option which came with 1Gb RAM and both wired and wireless Ethernet and some add-on sensors. It was a well run kickstarter campaign and the device was well packaged with a fab box. It has both a Cortex-A9 processor to run Fedora and a Cortex-M4 embedded processor to enable you to do Arduino style functionality which should be interesting to experiment with.

For various reasons it has sat around gathering dust, it’s been a bit of a long drawn out process with me randomly poking it as time allowed.. Primarily this was because there was no decent upstream U-Boot and kernel support, and I’d not had the time to hack that up myself from various downstream git repositories, but even without Fedora support their forked Ubuntu distro in the form of UDOObuntu has an experience that is truly terrible!

Late 2016 the problem of a lack of upstream support for U-Boot and kernel changed with initial basic support landing upstream for all three (Basic, Extended and Full) models so with a few cycles over a weekend it was time to dust it off to see if I could get Fedora 26 (did I mention this has been long running?) running on it and to see what worked.

The first thing for me to do was to setup a serial console for easy debugging. The UDOO Neo documentation is generally outstanding and the pins for the UART1 TTL are documented. Two things to note here is that the headers are female rather than the usual SBC male pins so I had to bodge my usual usb to serial TTL with some male-male jumper wires and you’ll need a ground for the TTL which is undocumented on their page, I used one of the GNDs as documented on connector J7 and all was good.

So after an initial set of fixes to the U-Boot support it saw my Fedora install and started to boot! Success! Well sort of, as mentioned above the initial support is rudimentary, it started to boot the kernel and very quickly managed to corrupt and destroy the filesystem not making it much beyond switch root. That wasn’t good. In the last week or two I’ve had a little time to look again, similar issues, it was better than it was a year or so ago but it still ended up with corruption. I reached out to one of the maintainers from NXP that deals with a bunch of the i.MX platforms and I got directed to a handful of patches, a test kernel and image later and a test boot… all the way to initial-setup! SUCCESS!

The core support for the i.MX6SX SoC and the UDOO Neo is pretty reasonable, with the MMC fixes it’s been very stable, all the core bits are working as expected, included wired and wireless network, thermal, cpufreq, crypto and it looks like the display should work fine. There’s a few quirks that I need to investigate further which should provide for a fun evening or weekend hacking. There has also been recently merged support for the i.MX6SX Cortex-M4 land upstream in Zephyr upstream for the 1.13 release, so getting that running and communication using Open-AMP between Fedora and Zephyr should also be an interesting addition. I think this will be a welcome addition to Fedora 29, and not a moment too soon!!

Fedora on the UP Squared

With the IoT Working Group and Edition moving forward I’ve been looking for an x86_64 device suitable for testing IoT related use cases. I was originally planning on using the MinnowBoard or Joule but given Intel has killed those product lines off it was back to the drawing board. I eventually settled on the UP², in particular I chose the UP² Pentium-4GB-32GB-PACK as it had everything I wanted in one box.

Hardware

The on paper hardware specs show a recent generation Intel Apollo Lake core, reasonable memory and storage options, an onboard FPGA, USB-3, dual ethernet and various other bits. The kit comes with options for active or passive cooling and the later the heatsink is massive, for the moment I’m running it on the passive cooling. The case is OK, I wouldn’t rave about it though. The power connector on the other hand is terrible, the PSU cable doesn’t seat well into the board and I’ve bumped it already and had it lose power, the power button is also tiny, so small in fact I mistook it for a reset button.

Fedora support

As you would expect the support in Fedora 27 is decent, accelerated 4K graphics, wired RealTek ethernet NICs, Intel m.2 PCI-e WiFI/Bluetooth, although the later is only 4.2 for IoT I would have appreciated Bluetooth 5, all work out of the box as expected. The firmware is uEFI and in theory supports secure-boot but I couldn’t work out how to turn it on in the firmware menus as it was greyed out, it also has a TPM2 module I’ve not had time to investigate. They eagle eyed would also note that I mention Fedora 27 even though Fedora 28 has been out a few days. Well for some reason F-28 doesn’t boot, I tried the network installer and the Workstation live image, they both get to the grub menu, then I get no output and nothing for a moment then it resets and we start again. I need to investigate this further but Fedora 27 Workstation livecd booted and installed fine so that’s what it’s got for the moment. Ultimately this is going to a host to test Fedora IoT so while I tested the general support this is fine.

IoT support

There’s a number of reasons I chose this particular device as an IoT test device:

  • Reasonably priced with a reasonable feature set.
  • Intel hasn’t killed it off yet like they’ve done with the Joule platform and Minnowboard 3 so I could actually buy it 🙂
  • Multiple network interfaces, reasonable WiFi and Bluetooth support.
  • Industrial IO sensors via an onboard Intel Sensor Hub. lsiio is reporting 9 sensors of various types. I’ve not checked this further yet.
  • USB-3, a Raspberry Pi HAT compatible connector and other options to add IoT related functionality or interfaces.

FPGA support

I’ve not looked at the FPGA support at all. The upstream kernel now has a FPGA Manager Framework and there’s a bunch of Altera FPGA support there but I’m not sure how it maps to this device. I also have to investigate open source toolchains for FPGA bitstreams as a lot of them just aren’t, I’ll likely do the HW enablement side of things and leave the toolchain bits to people that understand them. I also have the 96boards Ultra96 board so FPGA investigation was already on my Fedora 29 To Do list, and a lot of other people seem quite interested in them of late, no idea why 😉