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:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

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

ROCK 5 ITX RK3588 mini-ITX motherboard

22 Replies to “Getting Started with the Yocto Linux BSP for Polarfire SoC FPGA Icicle Kit”

  1. 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 packages specified in your metadata layers and it will then provide you .rpm, .deb, and/or .ipks for you to use in a packaging repository accordingly.

    You’re also not limited in sysvinit or systemd for your init/supervision choices either. Check out meta-runit over on GitHub. It’s a layer that is slowly growing over time to support more and more of the whole of Yocto with the option choice of runit instead of the other two. Runit’s more suited for a lot of the advanced embedded systems targets and it’s used by at least one Fortune 500 company at the core of things.

    (Yeah, this class of thing is what I do for my day job and I maintain several piece parts in the space on github… X-D )

    Reply

      1. 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

        1. 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

          1. 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.

        2. >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 company actually does? Here’s a hint: They don’t make any chips.

          >and voltages their designs use, engineers are not
          >consumers, by your standards DPG.

          ARM doesn’t supply information about voltages. Voltages would be chip specific and those will be supplied by whatever company made your chip and maybe only if you have an NDA with them.

          As an engineer that works on these sorts of boards on a daily basis I’m not too surprised if an eval board costs thousands of dollars and the software is complete garbage. You aren’t paying thousands of dollars for these boards because they are working Raspberry Pi like boards you can run a web server on and feel smug about being a Linux haxor. You’re paying thousands of dollars for the vendors reference platform to test your stuff on, poke the vendor with questions and decide if you want to drop hundreds of thousands of dollars on bringing a product to production using their chip.

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

          These aren’t sold in the volumes required for them to be some sort of scam to separate money from chumps.

          Reply

          1. 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.

          2. >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 expensive to be used in e-waste grade products. You have no idea what you are talking about.

          3. 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.

          4. 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 system (this) isn’t intended for the likes of yourself, unless you up your game. Seriously. You’re playing in the playground that the pros do. MY world. And you either live it and get on with analyzing the things or you don’t. (Ever wonder why the LKML list can be so caustic at times or why Linus has his trademarked rants? This is a part of it. There’s all sorts of things I get to deal with and I get paid well to do that.) Worse, this one’s an FPGA as stated earlier, bonded to an SoC as a unified device. Have you ever done either, VHDL, Verilog, Chisel3, SpinalHDL, or any other HDL coding to basically define a digital circuit? This is in a whole new league of “engineer” than you’re used to involved with THAT part of it.

            There’s tons of rather complicated documentation involved with Yocto, along with a lot of books you can obtain to start you off with. Just like with trying to do Linux drivers. Buildroot’s a differing story- it’s a system kind of derived from the Linux Kernel configuration system and it’s a nasty mess with little in the way of docs that’re useful for it. In this case, you can actually do like Jean-Luc managed to do here and learn a bit about Yocto (I’d even give advice…even now…) and find out that you’re talking about rolling your own distribution, etc. instead of sysadmining a Pi4.

            Making rants about things like, “hack it, dump it,” isn’t productive and it’s neither going to change the situation…or make you any happier. You either need to up your game or stick to things that have an ecosystem that can accommodate your expertise…and skip the unhelpful commentary that makes you look, well, foolish and childish.

          5. > 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.

          6. 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.

        3. 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 making Embedded Linux possible in my case (I shipped one of the earliest recorded systems on the market and kept doing it… :-D) so in my case, it’s almost like puttering around on my craft when I’m not working on it for my employer. It’s, sadly, not in the space of a lot of the things we’re used to in this group, to be honest. It’s getting there and I’m eager to contribute a lot more than a drib here and a drop there.

          Reply

    2. 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

      1. 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

  3. 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

    1. It’s possible to use sysfs to control GPIOs:

      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 not sure what it will look like yet. Last week, I tried to download Libero SoC design suite, but I could not create an account for the download. Microchip support still has not replied about that. I’ll need to ping them again… There’s still time, as I’ll be working on Zidoo M6 mini PC first.

      Reply

      1. Following up on that I can see Microchip has a bunch of code sample in /opt/microchip:

        Include a GPIO sample in C language that just use system calls to sysfs:

        This will blink all four user LEDs at the top left corner of the board.

        Reply

    2. 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

Leave a Reply

Your email address will not be published. Required fields are marked *

Boardcon Rockchip and Allwinner SoM and SBC products
Boardcon Rockchip and Allwinner SoM and SBC products