Building Linux Images

Buildroot

I have often wondered what it takes to start up linux. As I delve further into the Atlas tutorials I will understand it better.  I believe yocto is the hardcore build environment but buildroot is a simpler substitute which, unsurprisingly, runs on linux.
A tool called vagrant makes it ridiculously easy to setup buildroot.  As explained in a short tutorial by Dzone you simply download a vagrant configuration file and run vagrant to startup a VirtualBox ubuntu VM configured for buildroot.  It works a dream.
I followed the second part of the Dzone tutorial to create a simple i386 linux including openssh.
This builds all necessary software and creates two output files, a kernel image (bzImage) and a file system (rootfs.ext2)

Qemu

Armed with these two files we can bring up linux. We don't have a specific hardware processer in mind for this OS so it makes sense to bring it up in a virtual machine. Qemu is the workhorse for linux VMs and initially I installed qemu on my buildroot VM.  I can bring up linux and sign on to the console or ssh from the buildroot VM.  The linux I have built is very simple.  It is absolutely perfect to know that we have everything we need for a working linux system.

It doesn't make a lot of sense to run a qemu linux VM under VirtualBox ubuntu linux.  Qemu is available for Windows so I moved my two files across to my PC and installed Qemu for windows.  The batch file to start up qemu has a different format to the linux script but after a bit of trial and error I could start my qemu VM in Windows.  Establishing the network under windows took a little care, I had to enable openssh server in Windows so that ssh communication from qemu to windows was possible.

RPI image

Clearly buildroot can create images for real hardware and I would like one for my trusty old RPI model 1B.  Buildroot makes this childs play by giving you a default configuration for various RPI models. Within buildroot I simply ran "make raspberrypi_defconfig" and then "make" . The result was an image that I could burn to an SD card using Balena Etcher.  I booted it up and I have a simple RPI build.  This is excellent.

Qemu RPI

Rather than create SD cards for RPIs I would like to have an Qemu RPI VM working under Windows.  Alistair Chapman has provided a little blog showing how to do this.  It isn't a buildroot cutdown but a full RPI-buster-lite image.  The real RPI kernel needs some tweaking to run under windows but Dhruv Vras has provided suitable kernels for each Raspbian release. With a tailored kernel and a standard Raspbian image you can startup a Qemu VM.

In fact it is slightly more complicated than suggested to get the build to work, a couple of files need editing to make the image work and I followed instructions in wiki helpfully provided by Dhruv. Awesome, I now have an RPI VM working under Windows10 without VirtualBox.

Conclusion

It is very educational to build linux systems yourself to gain a feel for what software you need and what hardware components it uses.

Atlas Workshop WS1

Introduction

The DE0-nano-SoC documentation provided some great tutorials to get started with FPGA, HPS and then establish links between them.  I can see that there is a lot more to find out about the device, software and working environment.
My efforts with the Golden Hardware Reference Design (GHRD) were eventually successful and the hard work involved was centred around choosing the right versions of software to match the tutorials.
I learned quite a bit through this process of trial and error, in particular Quartus and EDS version 15 (c.2016) are preferred where possible.  If there are bugs, version 16.1 may be more appropriate.  Version 18.1 is my newer favoured release but doesn't include suitable EDS/DS-5 capabilities as they have become chargeable.

Rocketboards.org provides a set of three workshops for familiarisation and they seem to go down a considerable depth into the internals of the product.  I am reasonably happy that I understand enough about FPGAs for my current purposes, I can compile and load a design using my own verilog or Altera IP modules.  However the Linux environment and FPGA-HPS bridges are mysterious.

The WS1 course materials provide an excellent overview of documentation available / required.  The format is a  slide deck so there isn't much detail included but technical areas are summarised.  The Cyclone V boot process is covered in some detail and forms the basis for the four labs within the workshop.

Preparation

In preparation for lab activities we download an SD card image which contains linux and course files.  The card is tailored for Atlas / DE0 and assumes that Quartus 15.1.2 is used.  Once the image is unzipped and burned to card using BalenaEtcher it can be booted.  This is excellent as I now have a known source for an SD card image which is tailored for my board.
We have a general WS1-IntroToSoc folder and device specific hps_isw_handoff, DE0_NANO_SOC.sof, soc_system.sopcinfo.

LAB 1 Generating and compiling the preloader

When you boot the Atlas board from SDcard a very small BootROM program loads the preloader into on-chip memory.  The preloaders job is to setup the FGPA, define HPS I/O and memory and then copy the Linux bootloader into DDR memory which allows the HPS to boot in the usual manner, load the OS etc.

Our first task is to generate a Board Support Package (BSP) which will define various hardware details relating to the FPGA design and HPS interface.  We have a pre-generated QSYS design, whose details are provideed in hps_isw_handoff/soc_system_hps_0. We create a new BSP using the Altera BSP Editor tool, give it a copy of the design and generate a BSP.
The BSP folder contains source code, preloader settings and a Makefile to build the Preloader.

We now run make to compile the preloader and create a image file preloader-mkpimage.bin.

Finally we use the Altera Boot Disk Utility to copy the file to the correct partition on the SDcard so that the Boot Rom program will read it in and execute it.

Inserting the SDcard into the Atlas board we see the preloader booting up the system.  This is great progress but the system doesn't do a lot at this stage so we reset to the original preloader for now.

The lab is very instructive in showing the files required produced and the steps needed to generate a preloader.  We don't need to understand more detail as the design provides details and the BSP Editor interprets them to generate a preloader.

LAB 2 Verifying Hardware with System Console

Quite a short lab showing you how to use the System Console which looks to be hugely powerful.    It allows you see and set values within the FPGA.  Our FPGA demo design runs a Fast Fourier Transform in hardware and sends the results back to HPS.  Using the system console you can provide values to the FPGA, run the algorithm and using scripts, capture and display output.
It requires a far better understanding of the hardware than I have currently so I don't expect to use it in practice.

LAB 3 Bare Metal FFT app

A bare metal C program is provided for us and our mission is to run it.
The file soc_system.sopcinfo which was given to us contains information about the FPGA memory layout. Using sopc-create-header-files utility a number of headers are created from .sopcinfo which are required by our C program.

Now run make to use the provided Makefile to compile our bare metal program fft.bin.
C the executable across to the SDcard FAT partition which is mounted on our PC.

We now boot the SDcard and type "stop" to get to a u-boot prompt.
Commands are used to:
 load the FPGA program
 configure HPS-to-FPGA bridges
 load the bare metal application into memory
 run the application
See the output, Hello world followed by FFT inputs and outputs.

Finally we automate the load of the bare metal application.  This is (intentionally) partially successful, when our application runs it only prints hello world.  This is because we haven't configured or started the FPGA and bridges.

The tutorial covers a lot of ground.  Although I am unlikely to write bare metal programs it is wonderful to set up a working example so that we can see what a program does without an operating system there to help it.

LAB 4 Linux FFT Application

After the complexities of the previous labs this one is quite easy.
The fft app is compiled in EDS and copied to the SDcard.
We can then run the fft program on Atlas linux.
The linux configuration includes a lighttpd web server which can be used to specify input parameters and graph the output from the FFT.
It is deceptively simple as the C program looks complex and has a lot of code concerned with sending fft values to the FPGA, controlling it and reading back results before formatting them for the web server.

Atlas - First designs

Introduction

The DE0-nano-SoC documentation on CD-ROM (contents available here) is the best way to get started using the Atlas SoC.  Three step by step guides are available to build an FPGA design (using Quartus), an HPS design (using C and EDS) and a combined FPGA-HPS deisgn.

After completing these projects I wanted to test the Golden Hardware Reference Design (GHRD) which combines all the hardware components and pins.  This should help with starting any future computer project.

My First FPGA

This is a good project to familiarise yourself with Quartus.  A simple counter is implemented in verilog and a schematic created integrating the counter with a clock and a multiplexor.  A button input is used to control the speed of LED output pattern flashing.
The tutorial clearly shows you how to use a number of Quartus features without introducing more complexity than necessary.

My First HPS

The purpose of this tutorial is to allow you to compile and run a C program on the linux system.
A cross-compiler is required and should be provided following a successful install as described in the getting started guide.
Initially my Altera toolchain didn't work so I installed arm-linux-gnueabihf-gcc under wsl and compiled / copied it across to atlas_sockit using winscp.
It wasn't particularly informative but good preparation for the combined FPGA-HPS test.
For further tutorials it was important that the compiler works as expected and I could use EDS (Embedded development software).  Generally I am using v18.1 software but licensing has changed so EDS isn't included.  I installed Quartus and EDS v16.1, the last release including EDS, and this worked exactly as expected.

My First HPS-FPGA

The third tutorial guides you to create a QSYS design based on the GHRD (Golden Hardware Reference Design) which includes a PIO module for the LEDs.  An interface between FPGA and HPS is configured so LEDs can be controlled from a linux program.  

An HPS C program is written to map the appropriate memory locations so that the C program can use them.  It is quite complex and I couldn't write it from scratch.

Once we have loaded the FPGA image and copied the compiled C program to Linux we can run the program and control LEDs.  This is a leap forward in using these devices.
I am not convinced I will go far along this route.  I don't want to spend too much time writing C programs.


Again software was a bit of an issue but once I standardised on Quartus / EDS 16.1 I could follow the tutorial easily.

Compiling Hardware Design

Having completed basic tutorials I wanted to compile the Golden Hardware Reference Design (GHRD) as this would provide me with a template for using all the FPGA components.  It also seemed to provide a way to build an SD card image.  Instructions were simple, an intricate Makefile script is provided to create a Quartus project, build it and add all the necessary files for an SD card image. Unfortunately they didn't work well.
Eventually I was able to compile the GHRD and download it to Atlas.  It required me to start the creation process on Quartus web edition 15.0 + EDS, then continue in Quartus 16.1 and finalise/download in Quartus 18.1.
I am pleased that I have a "working" reference design and I did learn quite a lot along the way but it wasn't enjoyable.

MUSE + MPD.JS

Although it is fine to use mpd clients to choose and play music on MUSE (music server) it can be a bit fiddly. The album structure on music player apps isn't reliable due to incorrect mp3tags and we use a variety of playlists for radio stations and some albums.
I want to be able to choose and play my music from any source (files, playlists, internet radio) using the same interface.  This requirement can be met using a wonderful javascript app called MPD.js.  It provides an interface to MPD using websockets.  The client sends instructions to the MPD server using websockets.  Unfortunately MPD doesn't have a direct interface and a utility websockify is needed on the MPD server to send info from the browser to MPD on port 6600.
Using MPD.js I can start / stop music, choose a playlist, see what is playing, or queued up, select albums, files or internet radio stations to listen to.

Radio-stations : Play a single URL playlist, UK stations I listen to can be found at radiofeeds

Albums: Javascript is to display music directory structure and to choose a sub-directory containing the album to be played. A JS function then adds the tracks into MPD.

Noad/chart radio: These are playlists created on my app server and saved within mpd/playlists.

Buttons are an important feature of the app.  I use websocketd to allow me to associate batch files with a button so that I can use a combination of mpc and OS commands within the button function.

Status updates, e.g. for Album name and bluetooth connect are achieved by saving the status in an html snippet and updating the screen,.

bluealsa

Bluetooth always causes me misery and suffering.  I came across a wonderful utility by Arkadiusz Bokowy called bluealsa some time ago but I haven't previously successfully integrated it into my MPD music solution.  It has been over two weeks since my last post and this is mainly due to renewed struggles with bluetooth.

I found that bluealsa is in the raspbian repository so I could install with "apt install bluealsa".  Sometimes it would work fine for many hours.  It would stop working and I would be unable to find its address or connect back to the Jongo without rebooting.
I noticed that "dmesg" was giving frequent "under-voltage detected" messages and I think this corresponded to my disappearing devices.  Clearly my home power socket USB supplies aren't meaty enough for an RPI 3 so I changed to a better one.
I still wasn't able to get a good connection so eventually I despaired and installed pulseaudio.  It has its own eccentricities and I wasn't happy overall so I tried again with bluealsa.

Initially I guessed at how to configure it, and since my knowledge of building applications is extremely limited, this didn't go well.  By the time I found that comprehensive installation instructions are provided in the wiki I had done bad things to to my new server and stopped bluetooth working at all.  I spent a couple of days recreating PI32 (which was a good test that my written notes were comprehensive) and then installed bluealsa properly.

With a proper installation bluealsa appears to do its job very well.  I have a Pure Jongo bluetooth speaker A2 called JOB connected to my hifi.  I start bluealsa at boot time.  As soon as I connect the bluetooth speaker with bluetoothctl it is available to use.  I can use JOB from aplay, mpg123 or mpd and it acts just like a speaker attached to the RPI alsa jack socket.