SD card incompatibility and some other harsh feedback

I’ve been using the Unleashed in the past and have now obtained an Unmatched (both for academic research purposes). The main reason for the latter was the prospect of having better I/O. If you have been working on this project please don’t take the critique personally. I write this primarily in the hope that it leads to improvements and to document these issues for others (because apart from the fan I could not find a lot of other experience reports on these topics).

The Fan

I like quiet computers. I also had no big problem with the Unleashed fan because I saw it as a very first step and an engineering board.
However, the Unmatched fan is even (slightly) worse albeit the board being clearly marketed to not only engineers but also enthusiastic end users.
Taking that and the fact that the SoC could easily be cooled (semi-)passively into account, this cheap and unbalanced 25mm turbine is simply inexcusable.
I couldn’t find any power ratings actually but I’d be surprised if it dissipates more than 30W max.
On future boards please add at least some holes around the SoC so that we can fix this more easily than this plastic contraption that I don’t even rare to touch.

SATA SSD in M.2 Slot

Due to the B-Key of the M.2 slot I was expecting that at least in theory SATA SSDs could be made to work as this indicates that there are SATA pins. I should have checked that more carefully since this is really the only indicator that SATA could work (which it cannot because there is not even a SATA IP in the SoC AFAICT). A small hint regarding the non-obvious keying in the documentation would be nice.
I guess the B-M-Key slot was used eventually because it was cheaper? The schematic does have an M-only-key slot.

Spacers/Standoffs for the M.2 Slots

In the package there are 4 screws and 4 plastic washers that are supposed to be used to hold the M.2 cards down in the two slots. Depending on the physical size there has to be a spacer between the two PCBs that the screws can hold on to.
On the Unmatched there are only spaces for the maximum sizes and they are pressed into the board. So if you would want to use smaller cards the package contents are not sufficient (but you have two spare screws and washers to spare).
@jwim told me on IRC (thx!) that for the other holes one needs some optional hardware mentioned in the BOM: SMTSO-M25-2ET
These are less than a dollar (excluding shipping) and I won’t write what I think about not including them with a 600$ board.
Fortunately this is not a big issue and one can rather easily hack around this, e.g., with 10mm M3 screws and 2 nuts.

SD Card Support

The documentation talks a bit about issues with Application Performance Class 2 (A2) cards. In the Getting Started they are referred to as “Class 2” cards and the recommended SanDisk A1 as “Class 1”. It is understandable from the context but “Class x” (Cx) is another classification for SD cards that refers to their minimum sequential writing speed. Class 2 would be 2MB/s minimum writing speed.
The Ax classes are newer and specify minimum IOPS.

I can only speculate at this point but I think it is very unlikely that the classification alone (or I/O performance itself) is a good indicator for compatibility as it is stated in the documentation. I presume, only very few cards were tested (maybe even only 2) and the only obvious difference between them was the Application Performance Class. I’d rather expect some timing/race condition to be the culprit.

To keep the original SD card as a backup I tried to use another card that I have been using with the Unleashed without problems.
This is a quite old card from 2014: Samsung MB-MP32D, 32GB, Class 10, UHS-I
With that card I cannot get the ZSBL to execute correctly. I receive different low-number error codes (5 and 9 so far) indicating that some essential SD commands fail. It is independent of the image used (I have tried the latest SDK release (demo-coreip-cli-unmatched-2021.08.00.rootfs.wic.xz) as well as the Preinstalled Ubuntu 21.04 image (ubuntu-21.04-preinstalled-server-riscv64+unmatched.img.xz)).
The same images work fine with two different similarly old but slower 8GB SanDisk cards.
Since I’d like to get away from SD cards altogether I won’t look into that further but it’s worth to note online that if you see output from the ZSBL like “Error 0x0000000000000005” or “Error 0x0000000000000009” that it is a good idea to try another card.

Baud Rate of the ZSBL

The SW reference manual states “[…] boot fail messages from ZSBL are output to the console at 89856 baud instead
of the default 115200 baud.”
I don’t think that’s correct because the above mentioned output was only visible to me when using 57600 baud (which is a much more sensible value too). I only know one other SoC that uses a similarly off UART configuration: PULPino… what’s up with RISC-V devices and funky UART baud rates? :slight_smile:


1 Like

Hey, thanks for the solid critique. Don’t worry about hurting our feelings, Unleashed/Unmatched has been a learning experience for us, and yes we’re still learning. This stuff is pretty far from my research area so I can’t give you any useful responses, just wanted to say that I’ve cross-posted this to an internal board where we’re collecting feedback for future revisions/products. Hopefully others can follow up if there’s anything immediately actionable.


The spacer parts I mentioned are the ones already on the board, it is just that they are only installed in two of the holes, and you want them in other holes.

The odd baud rate is because Unleashed has a 33 and 1/3 MHz base clock, and Unmatched has a 26MHz base clock. I don’t know why the change. But anyways, if you compute 115200 / 33.333333 * 26 you get the odd baud rate. This isn’t deliberate. It is an erratum. It only affects the zsbl in rom before the fsbl initializes the clocks.

The getting started guide has a list of M.2 hardware that we have tested. You shouldn’t expect anything else to work. This really is a dev/eval board, not a consumer class board, and you should not expect that a wide variety of peripherals will work. I think some of the marketing hasn’t been clear about that.

The getting started guide also mentions the SDcards we use which are known to work. Some people have gotten boot from flash working, but we need more stable boot loaders before putting them in flash makes sense. And if you screw up your flash, then you still need an sdcard boot to fix flash. There is no sdcard controller. We use bitbanging to read from the sdcard. Maybe this is causing the problem with some cards.

Yes, the fan is a problem for many people. This has been discussed in multiple threads. Some people are using adaptors to fit a quieter 40mm fan onto the 25mm fan mount. But asking people to modify their boards is not a good solution.


Could someone else comment on the serial interface?

115200 baud has actually never worked for me either. I have tried both not specifying a baud rate, or just now tried 57600 as per the recommendation above, that also worked.

I’m using the screen command.

Anyone else have this issue? I searched the forum before for this and this is the first I’ve seen someone mention this.

The zsbl baud rate problem is documented in the SW Reference Manual.

Yes the shipping fan was a horrible design choice which I cannot fathom to understand how anybody on the unmatched engineering team thought was a good idea other than it was left up to a bean counter trying to save $1 and not caring about pissing off customers. Maybe in 1998 it would have been ok but in 2021 it’s an obvious engineering failure.

I wonder whether just slowing the stack fan down would make it acceptable?

I haven’t tried that. I’ve got a 40mm Noctua fan mounted the same way the stock fan was but using just one of the screws. It’s very quiet, but doesn’t cool quite as well – but it’s completely not a problem. Idle temperature is 40-41 (with 21 ambient) and sustained max load gets it to 48-49.

My problem with the serial interface is that the connector is not attached very firmly to the motherboard and a little wiggling of the cable will pop it loose. I found someone who was able to solder it back on but attempting to carefully insert the micro-usb cable popped it loose again. So I’m limited in debugging an OS port.

What can be the problem? I am using Silicon Power NVMe disk without problems.

Some peripherals outside our list will work. Some won’t. Lots of things can go wrong, like driver bugs. The key point is that you should not assume anything that isn’t on our list will work. You are welcome to try other products. You just shouldn’t assume that they will work.

@jimw Regarding the baudrate: My point is that the shipped hardware seems to not have the weird (89856) baud rate but just half of 115200 (57600). Maybe this is due some differences of CPU frequency between earlier versions (used in testing/to write the documentation) and the final product? I noticed that the factor of 1.196GHz/1GHz is not too far off of the 33MHz/26MHz that you stated above (but clearly not the exact reason).

Regarding peripheral support: The “list” you mention are the devices that are explicitly mentioned in the SW Reference Guide, right? This is basically one single NVMe SSD and one single SD card. :)
Maybe we could organize a user-curated list of tested devices like many open-source projects do. For example, flashrom generates a list of the implemented hardware with test status. The easiest way to do something similar would be a sticky thread in this forum where people post the hardware they have tested. This is very unorganized but would not require any resources. A git(hub) repo where people can add devices via pull requests would be another way but that’s quite bureaucratic. A user-editable wiki (hosted by SiFive) would be much better from my PoV - not only for this but also other things like guides (e.g., to enable booting from SPI).

After all, it is not as bleak as one might think from the statements above. I could (almost) successfully boot from a SATA SSD attached to a PCIe controller card in the PCIe slot with U-Boot coming from SPI flash, i.e., w/o SD card. :) (It hangs at relocating the kernel ATM… that should be fixable). It needs some U-Boot customization but apart from the known SPI patches it is just configuration changes to enable the controller and SATA (yet).

I use Haiku that I ported mostly myself, so it is my responsibility. As long hardware is recognized and properly communicate, the rest can be solved in software.

Hardware might not be recognized is another problem. PCIe is a complex standard, and incompatibilities between vendors are common. The big guys spend a lot of time and money testing with other vendors. The little guys all test with Intel and AMD hardare. But neither of those applies to the SiFive Unmatched board. So if you try some random PCIe device with the board, you might be the first person in the world checking to see if they are compatible. With luck they are, but this isn’t guaranteed.

1 Like

These two clock rates are unrelated issues. The zsbl runs at the base clock rate. The fsbl sets the clock to the desired rate.

Perhaps the odd baud rate is close enough to 57600 that it works by accident.

I don’t think so - it’s too far off, and actually using 89856 does not work in my setup. Using 57600 I get the proper output of “Error 0x0000000000000005” (for MSEL 1011 w/o an SD card), but I get the following with 89856:


I have not verified the exact baud rate via a logic analyzer but it looks rather clear to me.

1 Like

While I agree the hardware compatibility list is pathetically small I can live with that and think the unmatched is a vast improvement over unleashed for a developers board and I am happy with it overall. You have to start somewhere. I am sure V2 will improve on the lessons learned from the unmatched.


Because I am still struggling to get booting via a PCIe SATA controller to work, I will order the smaller NVMe SSD mentioned in the stated guide (without size). The model number of the 500GB drive has a typo: it should be MZ-V7S500 not 550. Also, the /AM suffix is apparently used for the American market (and just W for west Europe maybe), cf.

I presume they are technically identical.

As long as we’re wishing for things, the SD card slot is just a bit too close to the debug USB connector that you can’t use those cheap SD card ribbon cable extenders from Amazon/eBay. The extenders would let you move the card slot to a more accessible location, and also save a bit of wear and tear on the original connector.


Regarding the fan it would be nice if there was a sifive recommended way to solve this with good/detailed instructions on how to do it without damaging the cpu socket. The fan is really limiting the use of the board for me, the noise is simply so bad it’s a relieve every time i switch it off.

I completely agree. One SD Card slot broken as an experience.