Icicle: Mikrobus Access

I am struggling to access the mikrobus pins (and therefore any Click boards) through the PolarFire SOC, on an Icicle board. I am running Linux, with the latest releases from git (2021.4).

Goal: transmit arbitrary data through mikrobus UART, SPI, I2C.
Status: Cannot access UART via linux.
Steps taken:

Researched pin outs and confirmed that MSS complex enabled MMUART4, that MMUART4 is pinned to outputs at the top level of the SoC, and that the pins are defined in the physical constraint files, matching the pins on the schematic (TX on B20, RX on A21).

When running linux, only 3 UARTs are shown when “cat /proc/iomem”. I opened up the file meta-polarfire-soc-yocto-bsp/0004-dts-Add-device-tree-for-Microchip-Icicle-Kit.patch at master · polarfire-soc/meta-polarfire-soc-yocto-bsp · GitHub

and I only saw four UARTs in there (that makes sense based on what’s observed in linux).

Can any of you please help suggest how to get the MMUART4 visible within linux? Same question would apply to the QSPI that is pinned out to the microbus.


I’m bumping around in the dark just like you. My present interest is in i2c. What it looks like to me is that the 2021.4 MSS release does route the “other” i2c port (that has IO conflicting with SD) through the fabric to the already routed traces from the PF to the MikroBus. That’s real good, but it also looks to me like the corresponding 2021.4 Yocto release does not attach an instance of the standard linux i2c driver to the “other” i2c port at 2010.A000 as i2c-1.

As time permits, I am setting-up a Yocto build VM to address this.

There’s more - the “present” i2c already has traffic on it from a background task 90 - wq_pac193x - for U55, the on board current monitor. Also looking for the code that sets-up this little driver instance on i2c-0 so we can do the same and tap in to that bus for our own stuff when we burn our own instance of the icicle board…for our own entertainment. ;o)

…the old guy

Pls create a Tech Support case for this issue here:-

My team has edited the device tree source (.dts) to add the MMUART4, i2c-0, and QSPI entries. We are testing the rebuilt kernel today and I will update this thread if that works to provide us Mikrobus access. I think the build system from Microchip’s Git had all the appropriate drivers (i2c, spi, uart) so nothing new needed to be added to the build.


Sanjeev - i did that, though in the past, not much luck with cases here or via the fae.

In my copy of 2021.4 yocto (and earlier versions), i2c-0 is already there. Did you mean i2c-1?

Using this file in the git repo as a reference for the i2c mapped on my Icicle:

There exists only i2c1, at address 0x2010_b000, which corresponds to the v1.2 of PF_SoC_RegMap for device I2C_B_LO.

This matches what I observe with cat /proc/iomem, and what is shown in MSS Configurator when loaded with the Icicle eMMC Reference config. *Caveat: the eMMC Reference Config in the MSS i2c_1 at the high address 0x2810_b000, which doesn’t match the stock linux release [downloaded the .wic directly] where linux shows the i2c actually living at the lo address 0x2010_b000 *

At this point- I’m fairly confused as to what is the truth, and what isn’t. That is to say:

  • i2c1 appears in the .dts by name, at the lo address for i2c1.
  • i2c1 appears as 2010b000.i2c in the /proc/iomem on linux
  • i2c1 appears as 2810b000 in the MSS Configurator when loaded with PF_SoC_MSS_Icicle_eMMC.cfg from the Git repo. This obviously conflicts with what I observed in the linux build running on my Icicle.

Can you provide any clarification on what items are on LO or HI addresses, and why, for the Icicle board? I’m trying to learn as much as I can for self sufficiency. I see that two processors have access to the high space, and two to the low. I’m surprised it matters on the SMP kernel.

I feel your pain. here’s what i think:
i2c/0 lives at 2010.a000 (note that in Libero and MSS, this is i2c-0, but for this discussion…)
i2c/1 lives at 2010.b000

i2c/0 was never routed to pins until 2021.4 (current), but now it is.

while it was not routed, i2c/1 was the only one present, and linux named it i2c-0. then someone instantiated wq_pac193x - a driver on the i2c bus that serves U55. some program uses that driver routinely, because there’s plenty of activity on U55’s pins. perhaps changing that one to i2c-1 will break something in the system? not sure how much of this works.

anyway, the present 2021.4 when loaded into libero has a constraint file for mikrobus

set_io -port_name I2C0_SCL
-pin_name F12
-fixed true
-io_std LVCMOS33

set_io -port_name I2C0_SDA
-pin_name F13
-fixed true
-io_std LVCMOS33

and if you look at the design, i2c/0 (i2c-0) is now routed.

looks like you’re ahead of me in terms of being able to build yocto and change stuff around, so maybe, if you have 2021.4 fully loaded for both fpga and linux, perhaps you can try setting-up the i2c device at 2010.a000 as i2c-1 in linux. if that works, and /dev/i2c-1 appears, please let me know. i’m sure it will make all this VM setup feel more worthwhile.

…the old guy.

We’ll urgently priorities this and will post solution here ASAP.

We have two Icicle boards. One is stock, the other is running buildroot with our modifications.
Rebuilt the buildroot toolchain kernel with updates:

  • added MMUART4 at 0x2810_6000
  • added i2c-0 at 0x2010_A000

Both of those devices are picked up in DMESG, and both appear at their correct addresses in /proc/iomem. This is a very good sign.

Next steps:

  1. See if I can observe anything on a scope attached to the mikrobus i2c, and mikrobus UART.
  2. If good, start writing apps. If not, then tinker with the addresses until we can control data over those two interfaces.

Unfortunately, we tried adding SPI - but failed. I suspect that it was either:

  1. Kernel didn’t contain the right driver
  2. We didn’t point to the right driver
  3. We wrote the DTS entry incorrectly.

Not really sure how to attack that problem.

As a follow-up, I re-read the 2021.4 release notes for the FPGA.

  • Enabled QSPI and connected to MikroBus
  • Enabled MMUART4 and connected to MikroBus
  • Enabled I2C0 and connected to MikroBus

So that answers the question of what we SHOULD set up in the kernel. Now to actually prove success on MMUART4 and i2c0, and then get QSPI in there.


I tried this today on my Icicle kit and MMUART4 is easily up in my Linux.

root@icicle-kit-es:~# uname -a
Linux icicle-kit-es 5.6.16 #1 SMP Tue Jun 8 12:45:29 UTC 2021 riscv64 riscv64 riscv64 GNU/Linux
root@icicle-kit-es:~# cat /proc/iomem
20002000-20002fff : 20002000.clkcfg
2000318c-200031cb : 37020000.mailbox
20008000-20008fff : 20008000.mmc
20100000-201003ff : serial
20102000-201023ff : serial
20104000-201043ff : serial
20106000-201063ff : serial
2010b000-2010bfff : 2010b000.i2c

I did following changes to my icicle-kit-es-microchip.dts file:-
serial4: serial@20106000 {
compatible = “ns16550a”;
reg = <0x0 0x20106000 0x0 0x400>;
reg-io-width = <4>;
reg-shift = <2>;
interrupt-parent = <&L1>;
interrupts = <94>;
current-speed = <115200>;
clocks = <&clkcfg CLK_MMUART4>;
status = “okay”;

And rebuild the Linux yocto image again for a new kernel and DTB file with above changes. ()


Pls make sure you use latest Icicle Kit Reference Design Release 2021.04:-
Releases · polarfire-soc/icicle-kit-reference-design · GitHub ( [2021.04]



That’s fantastic - thanks for the detailed reply. That confirms the approach (and the memory region) that we should use. Could you please provide that same information on how to edit to provide the QSPI interface into the icicle-kit-es-microchip.dts file?

Thanks again!

QSPI Linux drivers are under development, so I can’t comment on similar DTS information for QSPI right now. Will update this thread later when drivers are ready in future.


@taiowa, your solution is similar to MMUART4 I have given below. Pls give it a try, we can discuss thru Microsemi case portal if you have more questions. I’ll post the summary of our discussion here.


@Sanjeev - thanks. let’s keep the discussion going here…the Oracle thingie appears on my screen as a tiny keyhole view to the response text, so it’s difficult to read. This is a better and more open format.

@OldCat - good on ya! - does /dev/i2c-1 appear now?

i just ran across a patch by Padmarao Begari that has i2c0 in it, and probably has more. it’s here: meta-polarfire-soc-yocto-bsp/0004-dts-Add-device-tree-for-Microchip-Icicle-Kit.patch at master · polarfire-soc/meta-polarfire-soc-yocto-bsp · GitHub - it does not appear to have mmuart4.

also, are you using Qspi, or the normal SPI devices?

getting the time to build my build vm has slowed to a crawl, but i’m right behind ya. please keep the good news coming.

…the old guy.

@OldCat - paint a big old “duh” on my link above. i think i clicked on your link from earlier then never navigated to the tab until this morning and got excited.