65 lines
5.5 KiB
TeX
65 lines
5.5 KiB
TeX
\documentclass[12pt]{article}
|
|
\usepackage[margin=2cm]{geometry}
|
|
\usepackage[utf8]{inputenc}
|
|
\usepackage{hyperref}
|
|
\usepackage{graphicx}
|
|
\usepackage[margin=2cm]{geometry}
|
|
\usepackage[utf8]{inputenc}
|
|
\usepackage{hyperref}
|
|
\usepackage{graphicx}
|
|
\usepackage{minted}
|
|
\usepackage{caption}
|
|
|
|
\title{Laboratory 3 report}
|
|
\author{Cédric Hölzl \and Antoine Brunner}
|
|
\date{May 2020}
|
|
|
|
\begin{document}
|
|
\maketitle
|
|
|
|
\section{Introduction}
|
|
The goal of this laboratory was to build a complete Linux system on a DE0-nano-SoC - a hybrid board consisting of a FPGA and an ARM dual-core HPS. Building a Linux system tailored to a specific hardware architecture is not an easy task, and there were a lot of steps involved before succeeding with that. First, we had to use the QSys platform designer to configure the hardware properly. Then, we had to use Altera's BSP editor to generate a boot loader tailored to the hardware configuration. After that, we had to compile the Linux OS and flash it to an SD card, along with the pre-loader and the boot loader. Finally, we could boot the system, and log onto it using a minicom terminal and after configuring the wired interface via SSH from a remote device.
|
|
|
|
\section{Configuring the hardware using QSys}
|
|
In this part, we had to configure the hardware for the Linux system. While the Linux system can run on an ARM processor, we still had to configure the FPGA part, because the goal was to reuse some hardware interfaces from previous labs. That is, we want to configure the joysticks and the thermal camera so that they can be used by the HPS. Figure~\ref{fig:qsys} shows how we configured the system with the joysticks, the thermal camera and the ARM processor.
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics[width=\textwidth]{QSYS.PNG}
|
|
\caption{Overall view of the system}
|
|
\label{fig:qsys}
|
|
\end{figure}
|
|
|
|
As a side note, since the HPS would run a Linux OS, accessing the memory mapped peripherals cannot be done in the virtual address space of the processes. Several solutions exists, such as creating a driver, or probably simpler, using \emph{mmap} to map physical pages into the virtual address space. That was not the concern of the lab, but it is worth mentioning it, because that's a problem we will face in the next laboratory.
|
|
|
|
An error that we made while using QSys was that we didn't understand what the \emph{peripheral multiplexer} tab was doing. Due to that misunderstanding, we did not select the pins that system needed, and couldn't boot the system correctly. After an explanation by an assistant, we finally understood how that pin multiplexer works, and we could fix the mistake that we had made.
|
|
|
|
Other than that, we also had to instantiate the system in the top-level VHD file, by making the right pin assignments for all the components, and get the design to compile. We also had some problems at this stage. Initialy we left some pins unassigned by mistake, causing the fitter to fail, but that was easily fixed.
|
|
|
|
\section{Compiling the system}
|
|
To compile the system on the board, we still had a long way. We had to generate the pre-loader using the BSP editor. After that, we downloaded Alteras's U-boot, configured it for the ARM processor and compiled it. The last piece of the puzzle was to download Ubuntu 14, compile it, and configure it by creating scripts that would run at the first start.
|
|
|
|
Although we have not succeeded initialy in doing those steps by ourselves, we didn't encounter any major problems in those steps, thanks to the Soc-FPGA Design Guide.
|
|
|
|
The final step was to put all the generated files in the right partitions of the SD card, so that the system could properly boot: the pre-loader to the A2 partition, the boot loader to the FAT32 partition and the Linux file system to the EXT3 partition.
|
|
|
|
We were already familiar with creating partitions and moving data to certain partitions using the command line, so we managed to do this step without major difficulties.
|
|
|
|
\section{Problems encountered}
|
|
Of course, it would have been to easy if everything went correctly... We didn't manage to boot our system from the first time because of a very dumb mistake. At least, we have learnt something from that mistake.
|
|
|
|
The mistake that we did is that we forgot to enable the GPIO pins in the QSys platform designer, meaning that the multiple ports (SD, Ethernet, ...) would never be properly connected to the processor. Figure~\ref{fig:pin_multiplexer} shows the interface on which we should have selected the right pins. That was the reason why we could not see anything in the Minicom terminal when the system was supposed to be booting. That mistake came from the fact that we didn't understand the QSys interface very well, nor the utility of the pin multiplexer. After an explanation from one of the assistants we have now understood what this interface is useful for, and we managed to fix the problem pretty easily.
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics[width=\textwidth]{HPS_PERIF.PNG}
|
|
\caption{The peripherals multiplexer view}
|
|
\label{fig:pin_multiplexer}
|
|
\end{figure}
|
|
|
|
\section{Conclusion}
|
|
As a conclusion, we think that this lab was a lot about following the guide, which sometimes didn't help us understand what we were doing. This in part the reason why we have made that mistake. Fortunately, it allowed us to question what we had done, and to learn what we were doing wrong. We had to restart the instruction from the beginning (having had a corruption issue with the VM), so the second time we started to remember a lot better what to do, allowing us to complete it quickly without issues.
|
|
|
|
\end{document}
|
|
|