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

ROCK 5 ITX Rockchip RK3588 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
Frank Earl
Frank Earl
3 years ago

Epic article, as always, Jean-Luc. As a long-time Yocto dev, I can state that the statement there’s no packaging, etc. is not WHOLLY accurate, though. The system as it’s designed builds out packages (whether you use them or not on the target for upgrades, installs, etc.) and it uses them to stage it into the root filesystem image. You have a choice of three differing packaging systems: RPM, Debian, and Ipk. Each has their own consequences. You can build an image with just the desired stuff for the target or you can build the “world” which handles all of the… Read more »

Reply
Jean-Luc Aufranc (CNXSoft)
Author
Jean-Luc Aufranc (CNXSoft)
3 years ago
  Frank Earl

Thanks for the correction. I understand the OpenEmbedded image is relying on ipk packages.
I did not link directly to it, but there’s a short discussion about the “lack of package manager” @ https://exchange.riscv.org/t/icicle-kit-linux-package-manager/76

Reply
Theguyuk
Theguyuk
3 years ago

I wonder why customer use of a supplied device should be so hard?

Reply
dgp
dgp
3 years ago
  Theguyuk

Because these are not consumer devices.

Reply
Theguyuk
Theguyuk
3 years ago
  dgp

So the buyer is not a customer, and products are not supplied as working products. With working software.

You have to waste, paid time to get them to work. Why supply documentation when it is not a consumer product.

Why does aRM supply engineers documents on what instructions and voltages their designs use, engineers are not consumers, by your standards DPG.

To me it is more make and forget, lazy, greedy manufacturing and a way to charge for extra product support.

Reply
Jean-Luc Aufranc (CNXSoft)
Author
Jean-Luc Aufranc (CNXSoft)
3 years ago
  Theguyuk

Microchip customers will normally build their own boards and then customize their software. The Yocto and Buildroot BSP provides more flexibility to build custom images, and customers may not want to rely on Microchip’s packages repository, preferring to handle firmware updates by themselves.

That means they’ll have a team of engineers many of which are already familiar with either Yocto or buildroot. Documentation is there, but still, it’s a bit all over the place. Larger customers will normally be assigned one or more FAEs (Field Application Engineer) for technical support, who will help with any technical issues that may arise.

Reply
Frank Earl
Frank Earl
3 years ago
  Jean-Luc Aufranc (CNXSoft)

Bingo! Some of us, though, are slowly working towards “better” for a lot of this. It’s unfortunately presumed you’ve got a team of engineers or an SME (Waves hand…) working on this stuff. There needs to be a BIT better because there’s all sorts of amazing things possible with Yocto (Buildroot/OpenWRT’s not scalable- so while you can get simplistic solutions or, heh, a router appliance with OpenWRT, it’s more difficult to get, say an embedded secured DVR, for example, with it. It becomes hard to make something that scales to gigs of “firmware” (yes) with those tools.

Reply
dgp
dgp
3 years ago
  Theguyuk

>So the buyer is not a customer These are evaluation boards. Evaluating if the supplied software is garbage or not is part of the process. >You have to waste, paid time to get them to work. Why supply documentation >when it is not a consumer product. These boards are used during product development. If you are developing a product you are already “wasting time” doing component selection, trying to reduce the BoM cost etc. >Why does aRM supply engineers documents on what instructions ARM supplies reference manuals for their cores and nothing else. Are you unaware of what ARM the… Read more »

Reply
Theguyuk
Theguyuk
3 years ago
  dgp

And that’s why products supplied to consumers are crap, the hardware and software engineers are just making it up as they go along. Hack it then dump it, Orange Pi style. Just fire and forget.

Reply
dgp
dgp
3 years ago
  Theguyuk

>And that’s why products supplied to consumers are crap, >the hardware and software engineers are just making >it up as they go along. What do you base that on? Have you worked on a consumer product that is out in the wild being used? If not you are just talking out of your arse. >Hack it then dump it, Orange Pi style. Just fire and forget. The orange pi stuff is hobbyist grade boards produced for as little as possible. These hard CPU core + FPGA chips are not going into that level of product. The chip alone is too… Read more »

Reply
Frank Earl
Frank Earl
3 years ago
  dgp

Heh. We’ve all been there at one point in time. Well…most of us.

He’s a base level hobbyist and doesn’t get there’s a deep end there to that pool. He’s still thinking like it’s all like a Pi4 as best as I can tell and has NEVER built out any consumer, industrial, or mission-critical products. 35+ years of it in my case. But…unlike some, I kind of live it as well as work with it.

Reply
Frank Earl
Frank Earl
3 years ago
  Theguyuk

Not QUITE. Let me guess. Hobbyist, right? That’s not negative, that’s just trying to, again, frame this in the right ways so you can get this… An OrangePI isn’t a consumer part any more than any of the others are. NONE of them are consumer parts. They’re either maker parts, industrial eval kits, or BOTH (Embrace the epic power of, “AND!!” it applies here) The presumption that they have clean documentation, etc. is going to disappoint you. REPEATEDLY. If you want this sort of thing, Stick with a Pi Foundation device, an indstrial X86 computer and the like. An FPGA… Read more »

Reply
tkaiser
tkaiser
3 years ago
  Frank Earl

> Hobbyist, right?

To be more precise: just a retired old fart who thinks the solution to every problem is a crappy Android TV box. Not able to distinguish between distro and kernel, hardware and software, board maker and SoC maker.

Reply
Theguyuk
Theguyuk
3 years ago
  tkaiser

Oh look the guy who programmed the hated Orange Pi software and who encouraged others to buy Orange Pi boards, without declaring he worked for Orange Pi.

Reply
Frank Earl
Frank Earl
3 years ago
  Theguyuk

Waste paid time… Looks at his desk covered with a mix of company and personal HW, including FPGA boards for RISC-V and related dev… Sorta. And it’s seldom wasting time (well…some vendors…it IS that…) and more a level of investment in knowledge about the systems you’re working with. Right now none of the RISC-V related space is really anything other than a playground for the virtuosos, the paid grandmasters, etc. to do things unless you’re willing to step up to the plate and try to become one of them. 25+ years of doing Linux stuff professionally and 22 of it… Read more »

Reply
Frank Earl
Frank Earl
3 years ago
  Theguyuk

Because it’s presumed you’re like, heh, me, there and live, breathe and eat Embedded systems, specifically Embedded Linux.

When you’re dealing with embedded stuff, the vendors presume you’re either a complete ninny or someone that deeply knows what you’re doing. Nothing in-between…and the ninny route’s more than a bit offensive.

Reply
Theguyuk
Theguyuk
3 years ago
  Frank Earl

Actual you condescending arse cleaner. I am paid not by the hour but by results. If what I tell a company to do, does not work or create profit I don’t get paid. Companies are told to fire people like you, by people like me. I earn enough to work as and when I chose.

People like you are the problem in the industry…

Reply
ben
3 years ago

Any plans on showing how to debug thru a simple blink-led program on the risc-v ?

Or how to synthesize a new fpga bitstream?

Reply
Jean-Luc Aufranc (CNXSoft)
Author
Jean-Luc Aufranc (CNXSoft)
3 years ago
  ben

It’s possible to use sysfs to control GPIOs: root@icicle-kit-es:~# ls -l /sys/class/gpio/ total 0 --w------- 1 root root 4096 Mar 23 2021 export lrwxrwxrwx 1 root root   0 Mar 23 2021 gpiochip0 -> ../../devices/platform/soc/20122000.gpio/gpio/gpiochip0 --w------- 1 root root 4096 Mar 23 2021 unexport 12345 root@icicle-kit-es:~# ls -l /sys/class/gpio/total 0--w------- 1 root root 4096 Mar 23 2021 exportlrwxrwxrwx 1 root root   0 Mar 23 2021 gpiochip0 -> ../../devices/platform/soc/20122000.gpio/gpio/gpiochip0--w------- 1 root root 4096 Mar 23 2021 unexport It’s the same as with any Arm Linux-based system. I’ll probably try GPIO that with another board like the upcoming Radxa Starlight JH7110. A post about the FPGA part is coming, but I’m… Read more »

Reply
Jean-Luc Aufranc (CNXSoft)
Author
Jean-Luc Aufranc (CNXSoft)
3 years ago
  Jean-Luc Aufranc (CNXSoft)

Following up on that I can see Microchip has a bunch of code sample in /opt/microchip: ls -l total 40 -rw-r--r-- 1 root root 1072 Sep 26 11:24 LICENSE -rw-r--r-- 1 root root  844 Sep 26 11:24 README.md drwxr-xr-x 2 root root 4096 Sep 26 11:30 can drwxr-xr-x 7 root root 4096 Sep 26 11:29 coremark-pro drwxr-xr-x 2 root root 4096 Sep 26 11:30 dma drwxr-xr-x 3 root root 4096 Sep 26 11:30 ethernet drwxr-xr-x 3 root root 4096 Sep 26 11:30 fpga-fabric-interfaces drwxr-xr-x 2 root root 4096 Oct  3 03:52 gpio lrwxrwxrwx 1 root root   24 Sep 26 11:30… Read more »

Reply
Frank Earl
Frank Earl
3 years ago
  ben

I don’t know if there’s any tools ON target to synthesize a bitstream there. If this was coupled to an ice40k or an ECP5, be a differing story since IceStorm works on pretty much any Linux. Unless they’ve made a PolarFire toolchain for RISC-V
or as source…that’s not happening.

Reply
Boardcon Rockchip RK3588S SBC with 8K, WiFI 6, 4G LTE, NVME SSD, HDMI 2.1...