Posted on by Jean-Luc Aufranc (CNXSoft) - 22 Comments on Getting Started with the Yocto Linux BSP for Polarfire SoC FPGA Icicle Kit

Getting Started with the Yocto Linux BSP for Polarfire SoC FPGA Icicle Kit

Last month I received Microchip PolarFire SoC FPGA Icicle development kit that features PolarFire SoC FPGA with a Penta–core 64-bit RISC-V CPU subsystem and an FPGA with 254K LE, and booted it into the pre-installed Linux operating systems based on OpenEmbedded.

Today, I’ll show how to get started with the Yocto BSP and run the EEMBC CoreMark benchmark, and I’ll check out the FPGA with Libero SoC Design Suite in a couple of weeks.

Operating Systems supported by PolarFire SoC FPGA

My initial idea was to focus this part of the review on Linux on RISC-V status, checking some system information, running some benchmarks (e.g. SBC-Bench), compiling the Linux kernel, and installing services like a LEMP stack (Linux, Nginx (pronounced Engine-X), MySQL, PHP) which could be used for WordPress hosting for instance. But then I looked at the operating systems supported with Microchip PolarFire SoC FPGA.

Polarfire SoC FPGA Operating Systems

There’s a Yocto Linux BSP and a Buidlroot Linux BSP supported by Microchip, and Embedded Linux distributions from third parties like Siemens Embedded and WindRiver. FreeBSD is said to be coming soon, and several real-time operating systems should probably be for the small 64-bit RISC-V core from the SoC.

That means there’s no package manager and no Debian-based root filesystem excepted by some of the tools I planned to use. So while in theory, it would still be possible to achieve what I intended to do, I don’t have the 100+ hours required to achieve that… So I scaled down my ambition, and instead will report my experience building the Yocto images from images, cross-compile a hello world, and natively compile and run EEMBC benchmark. It’s not my first time playing with the Yocto Project, but I still learned a few things along the way, and I hope you will too.

Webserver demo and Voltage/Current Analytics

Before working on the Yocto BSP, I connected the board to Ethernet to complete Microchip’s getting started guide, and run a webserver.


We can access a web page that will show voltage and current for VDDA (XCVR Tx/Rx Lanes Supply), VDD25 (PLL and PNVM Supply), VDDA25 (XCVR PLL Supply), and VDD (Core Supply) by going to http://<board_ip_address>

It will be interesting to revisit this page once we run EEMBC CoreMark benchmark.

Yocto Linux BSP

Let’s build Linux using the Yocto BSP as explained on Github. For reference, I’m using a laptop running Ubuntu 20.04, and I had to change some of the commands.

First, let’s install the repo utility:


then a few dependencies:


Time to initialize the repo:


We can now configure the build:


To start the build, run the following command:


I remember Yocto build system can take a lot of time having spent over 24 hours building an image on a low-end laptop about 10 years ago, and with the default settings, my laptop, powered by an 8-core AMD Ryzen 7 2700U processor and fitted with 16 GB RAM, quickly become very slow and close to unusable with a 50+ CPU load:

Polarfire Icicle Yocto BSP build CPU Usage

I let the build run its course as I went to bed after launching it. But I did not check the storage requirements, and the build stops after about two hours with my hard drive running out of space. As we’ll see once the build is completed, around 100 GB of free storage is required.

Libero SoC system requirementsWhile we are on the topic of system requirements, Libero SoC design suite will need around 35 GB extra space, and for PolarFire SoC development at least 16 GB RAM. So you’ll want to have a powerful workstation to develop applications on PolarFire SoC FPGA Icicle development kit with plenty of RAM and sufficient storage.

Back to our Yocto build. The ideal would be to have a dedicated build server, but if you intend to use your computer at the same time as the build take place you may want to edit [your_yocto_build_dir]/conf/local.conf


then


Before starting the build…

An alternative is to pause the build with Ctrl-Z, which works in a similar way to Ctrl-C, but uses SIGTSTP instead of SIGINT in order to pause the process, and not terminate it.


Since bitbake spawns so many other processes, we have to wait for them to complete, and it took about 10 minutes to get back to having a usual computer.

I stopped for about 3 hours, and then it can be resumed with the command “fg“. It’s like a hibernation mode for terminal programs, and it’s been around forever, but I either forgot about it, or never used it myself.  The complete build took around 7 to 8 hours on my machine.

That’s the space used by the Yocto BSP:


We can find the images in tmp-glibc/deploy/images/icicle-kit-es/ folder:


The uncompressed image is 5.5GB large so it would be into an 8GB SD card, but 16GB or 32GB cards are recommended. This is the command provided by Microchip to flash it to an SD card:


But if you want image verification, utilities like USBImager would be preferred. That’s what I used to flash the image to a 32GB SD card, which I then inserted into the SD card slot of the board to try it out.

Let’s interrupt the boot to check the SD card is detected:


All good, let’s carry on… and it fails to switch to the kernel. I eventually reflashed the image using the uncompressed binary, and I could login to the terminal:


The rootfs was not resized automatically, and it seems there’s a problem with the GPT table… I’m not quite sure what happened here. But since our self-built image is working, and we have an eMMC flash let’s flash it to the internal storage instead.

Power off the board, remove the SD card, and connect to ttyUSB0 with Bootterm to access the HSS terminal:


Before restarting the board, interrupting the boot, and type “usbdmsc” to expose the eMMC flash as a USB mass storage to our Ubuntu laptop.


We’ll need another Micro USB cable connected to J16 Micro USB port to see the flash in Ubuntu.

Getting Started Guide PolarFire SoC FPGA Icicle Kit

PolarFire Icicle eMMC as USB flash drive

We can unmount the Boot and root partitions before flashing the image as we did for the SD card. I tried with the gz image first, but I had the same problem as with the SD card with the root partition failing to mount even on PC, so I went with the uncompressed image, and everything went smoothly.

Flash eMMC PolarFire FPGA SoC IcicleAfter completion, we can remove the micro USB cable connected to J16, and access our Linux image…

Hello World Cross-Compilation

Let’s try to cross-compile the Hello World program.


for RISC-V using the Yocto toolchain, which we’ll first add to our path:


and use the RISCV GCC tool to build it:


Oops, it does not work as expected. It looks like the toolchain is not properly installed, or I used the wrong one. I’ve tried to play with CFLAGS, but no luck… Maybe it’s only supposed to work within Yocto/Bitbake framework… I’ve got more experience with buildroot, and usually the cross-compilation toolchain works out of the box.

EEMBC CoreMark Benchmark

So I’ll build EEMBC CoreMark natively, i.e. directly on the board. The image we’ve built comes with git and the GNU GCC toolchain so it should be straightforward.


This both builds and runs CoreMark with two files generated

  • run1.log
  • run2.log

    The board achieved a 1339.136257 score, or about 2.23 CoreMark/MHz since the RISC-V cores run at 600 MHz.  But Microchip reports 3.25 CoreMark/MHz on the board. Let’s try again with the same flags as used by the company:


This is the content of run1.log:


Somehow the CoreMark score is nowhere to be found, but we still have the Iterations/Sec that went from 1341.651573 to 1666. So it’s improved. It’s easy to see why the score did not show by looking at the code:


Let’s repeat this with -DHAS_FLOAT=1 instead…


This time it looks correct:


But that’s only 2.59 CoreMark/Mhz, still not quite up to 3.125 CoreMark/MHz.  Actually, it matches Microchip’s results using unsigned index. Somebody tried to do the same and was advised to change the code in posix/core_portme.h to use signed index:


After running the benchmark again, the score is even higher:


1789.159376 CoreMark corresponds to roughly 2.98 CoreMark/MHz. Let’s do a final hack by defining HAS_FLOAT=0 in the make command line. Results:


Let’s use the Iterations/Sec result: 1875 as the CoreMark 1.0 value, and in this case, we can indeed achieve exactly 3.125 CoreMark/MHz as Microchip did for using a signed index.  Why signed is significantly faster than unsigned, I’m not quite sure… and we’d need to look at the assembly, and check the number of cycles for each instruction to find out.

It truly shows how benchmarks can be tweaked/manipulated to achieve greater results, and also the importance of compile flags to optimize the code. The voltage/current analytics web page did not show any significant variation during testing.

That will be all for today, and in a few weeks, I’ll hopefully post something about the FPGA part. Somebody asked me to assess virt-io over the PCI-e bus, but due to time constraints, I was unable to do so. I still asked Microchip who replied that it should work, but they haven’t tested for it…

If you are interested in the board, it’s available from various distributors, such as Mouser, for under $500.

Share this:

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

Radxa Orion O6 Armv9 mini-ITX motherboard
Subscribe
Notify of
guest
The comment form collects your name, email and content to allow us keep track of the comments placed on the website. Please read and accept our website Terms and Privacy Policy to post a comment.
22 Comments
oldest
newest
Boardcon CM3588 Rockchip RK3588 System-on-Module designed for AI and IoT applications