SD-Card slot broken

[gaby]

I’m very unlucky : my Unmatched hardware (B0) survived to 6 SD-card ejections (second day of usage). The spring mecanism inside is not working as expected now : the SD-card is not retained inside and so is ejected automatically. The SD-card can’t stay inside as the anchor mecanism on the side is apparently unable to keep the SD-card inside. I tried multiple SD-card and it’s really a mechanical issue.

Is there any workaround to this ?

I was about to install Ubuntu on the NVME to not have to boot anymore on this SD-card…

Edited: a bit of tape and the SD-Card is kept in. I hope it’s the last time I need to use an SD-Card. I can now understand why some hardware design use a SD card slot-in mecanism without any spring system. That’s more reliable at the end.

Edited (2): adjust the length of tape so that the SD-card is really fitting inside with an alignment to the contact pads. A bit of trial and error there.

[andre]

I was about to install Ubuntu on the NVME to not have to boot anymore on this SD-card…

from what i could gather, you still need to boot from sdcard initially, even transfering to nvme in the end boot proccess… is that incorrect?

i also seem to be having sdcard issues (have to massage in just right) so im curious for any pointers… thanks in advance

[dorms]

@andre

from what i could gather, you still need to boot from sdcard initially, even transfering to nvme in the end boot proccess… is that incorrect?

From reading the documentation I think it should be possible to copy the first two partitions from the SD card to the onboard NOR flash and change the MSEL accordingly to being able to boot without an SD card.

It looks like the debugger can write to the flash, so you can do even that without the SD card.

[andre]

@dorms

From reading the documentation I think it should be possible to copy the first two partitions from the SD card to the onboard NOR flash and change the MSEL accordingly to being able to boot without an SD card.

It looks like the debugger can write to the flash, so you can do even that without the SD card.

interesting, ok ill take a closer look!

[gaby]

@andre @dorms

You are right, for now the simplest solution is to boot from the SD-Card and then instruct to jump onto NVME’s rootfs install. That’s what I finally did by modifying inside the \boot\extlinux\extlinux.conf file on SD card the line:

append root=/dev/mmcblk0p4

with

append root=/dev/nvme0n1p1

Later on when, once I booted on NVME’s ubuntu install and updated this last, it complains that I’m not running the latest kernel (since I booted with the one on sd-card) but it’s ok. I also tried the latest image available there of May (the one on SD card bundled with the board is from March). But the execution process was stopped around USB HID devices detection. Maybe I did something wrong during the image installation on another SD card (32 Gb too). Hopefully I still have the original SD-card with March release which is still running fine (with same USB HID devices). I’ll re-check this operation.

I originally misunderstood these instructions:

I thought that the NVME could be the primary boot. But it can’t be. When I read the software reference manual available there and in particular § 2.7 it all went more clearer.

I noticed on this forum’s comment from @JawnSmith that:

The need for the SD card to be present is actually part of the board’s firmware rather than u-boot itself, so unfortunately an SD card will be required.
EDIT: I stand corrected, it is actually possible to flash bootloaders into EEPROM and set the DIP switches to boot from EEPROM. If there’s some interest in how to do that I’d be happy to do a write-up.

I would definitely be interested by such procedure

For the board’s itself personnaly I would see these two changes:

• take a SD Card connector without any spring system, which is more reliable. It should survive more than 6 ejections
• move the SD card connector away from the USB connector for the serial console. The access to the SD card is always a bit complicated if you let the USB cable plugged in, next to this SD card connector. Or you take the habit to always remove this USB cable before messing with this SD card connector.

This may be considerations which are important for first installation steps. Probably that in a few weeks I will don’t use these this SD card slot if I can change this boot-up process, and also use less this serial console. I’ll see.

Thanks all for your remarks & advices.

[sirn]

I haven’t tried this myself (planned to do so once I finished compiling rootfs), but my guess for booting from EEPROM is to partition /dev/mtdblock0 and flash U-Boot and OpenSBI into it, with layout similar to carlosedp’s guide, then change DIP switches to 1001.

Possibly something among this line:

# Partition SPI flash
sudo sgdisk -g --clear --set-alignment=1 \
    --new=1:34:+1M:    --change-name=1:'u-boot-spl'    --typecode=1:5b193300-fc78-40cd-8002-e86c45580b47 \
    --new=2:2082:+4M:  --change-name=2:'opensbi-uboot' --typecode=2:2e54b353-1271-4842-806f-e436d6af6985 \
    /dev/mtdblock0

# Copy U-Boot SPL and OpenSBI from SD card
sudo dd if=/dev/mmcblk0p1 of=/dev/mtdblock0p1 bs=8k iflag=fullblock oflag=direct conv=fsync status=progress
sudo dd if=/dev/mmcblk0p2 of=/dev/mtdblock0p2 bs=8k iflag=fullblock oflag=direct conv=fsync status=progress

Is it possible for someone from SiFive to confirm whether this is the right approach? (I’m also a bit confused why Boot Mode configuration settings table in GSG v1p1 has gone missing in GSG v1p4)

[vpelletier (Vincent Pelletier)]

@dorms

it should be possible to copy the first two partitions from the SD card to the onboard NOR flash and change the MSEL accordingly to being able to boot without an SD card.

My guess is that for this to work, the first part (u-boot SPL) has to be either aware of MSEL, or to be aware that the NOR may contain the second part (u-boot proper with embedded OpenSBI). Then, u-boot proper may also have to know where it booted from so it can know where to load (and possibly write-back) its environment.

[jimw (Jim Wilson)]

I’m told that the current u-boot port doesn’t support flash yet. I don’t know the details.

[dorms]

@vpelletier

My guess is that for this to work, the first part (u-boot SPL) has to be either aware of MSEL

The FU740 manual says on page 72 (PDF page 74): “Both the ZSBL and FSBL download the next stage boot-loader from a QSPI interface. However, the protocol used varies depending on MSEL.” U-Boot is the FSBL, so it’s supposed to support it.

@jimw

I’m told that the current u-boot port doesn’t support flash yet. I don’t know the details.

I’ve read that somewhere, too. Maybe it’s not yet implemented.

[vpelletier (Vincent Pelletier)]

@dorms

The FU740 manual says on page 72 (PDF page 74): “Both the ZSBL and FSBL download the next stage boot-loader from a QSPI interface. However, the protocol used varies depending on MSEL.” U-Boot is the FSBL, so it’s supposed to support it.

I believe there was a board-(or chip- ?)specific FSBL before it switched to u-boot SPL, and maybe the documentation describes how that one already worked ?

So if you mean “supposed” as “it needs to, on the way to feature-completeness”, this is also my understanding.

There is another setting I am curious about: MSEL=0001. u-boot can be compiled in XIP mode, so it should be able to produce code pre-linked to be run from 0x2000_0000. But then it needs to also duplicate some of the work done by the ZSBL (setting the peripheral clock dividers, as per the documentation) so here again some support from u-boot is necessary (which I guess is not there yet).

I would love to get this board to boot from NOR (MSEL either 0001 or 0110), with the NOR containing OpenSBI and EDK2. This would solve OP’s problem: no need for the sdcard in the boot process. But I have no idea of the status of EDK2 on this board at the moment.

[vmedea (mara)]

@gaby

move the SD card connector away from the USB connector for the serial console

The sd card slot in the I/O shield doesn’t work that well as it is, anyhow. It’s so narrow which makes it hard to align. I just had a clumsy accident where I almost literally lost a micro-SD card inside the enclosure while reinserting it

[jrtc27 (Jessica Clarke)]

@dorms

@vpelletier

My guess is that for this to work, the first part (u-boot SPL) has to be either aware of MSEL

The FU740 manual says on page 72 (PDF page 74): “Both the ZSBL and FSBL download the next stage boot-loader from a QSPI interface. However, the protocol used varies depending on MSEL.” U-Boot is the FSBL, so it’s supposed to support it.

Parts of that manual are just copied from the original FU540 manual and are outdated. For example, it has a whole section on BBL, and the FSBL section talks about loading BBL, but there is no BBL for the FU740 (and BBL is extremely deprecated), instead it’s using U-Boot+OpenSBI. I don’t trust any of that section, it’s clear that nobody ever reviewed it before publication.

[jimw (Jim Wilson)]

I filed an internal bug report for the BBL mentions back in December. It will eventually get fixed. I hope. Engineers don’t always remember that docs are just as important as the hardware/software.

But the fundamental problem here is that the hardware docs weren’t reviewed by the software folk. That entire chapter should probably just be removed, except for the bits that talk about how the zsbl in mask rom works, which is actual hardware, and hence appropriate to be in a hardware manual. And that part of the chapter is correct. The rest of it should be in a software manual that software folks review.

Code will have to be written before u-boot can work from flash. My understanding is that SiFive choose not to do this at the start because putting stuff in flash on the Unleashed caused too much trouble. The SDcards are easier to deal with. If you need to change it, you just pop it out and rewrite it.

[Monotech (Walter S.)]

Regarding the SD-card being required for boot, it might not be required at all. I saw this being mentioned on another thread:

[…] NVMe is one of the first devices for U-Boot to probe, and the SD card the last, so you save a few seconds off the U-Boot boot time by not having to let it go all the way through the list […]

Reporting Success, FreeBSD on my Unmatched - #15 by jrtc27

L.E. Oh, wait Jessica is also in this thread. Should have read the thread more carefully.

[cliffs-edge]

gaby
Jun 5
I’m very unlucky : my Unmatched hardware (B0) survived to 6 SD-card ejections (second day of usage). The spring mecanism inside is not working as expected now : the SD-card is not retained inside and so is ejected automatically. The SD-card can’t stay inside as the anchor mecanism on the side is apparently unable to keep the SD-card inside. I tried multiple SD-card and it’s really a mechanical issue.

Hi. I’ve just experienced the same problem.
I had my Unmatched board sitting unused for a couple of weeks, and when I went to use it [to upgrade to Ubuntu 21.10] I found that the microSDCard slot is no longer able to retain the card…

{I have Ubuntu 21.04 installed on an NVMe SSD, so still able to use the Unmatched currently as I only need the SDCard for booting [and so have to physically hold it in the slot for ~2 minutes], but it’s still a huge pain, and not acceptable for long time use…it’s such a shame to have a few $USD component failing on a ~$700 board…].

Did you find a way to fix the broken “push-push” spring retainer mechanism, or have to RMA the board back to Mouser?

[gaby]

Hi,

Did you find a way to fix the broken “push-push” spring retainer mechanism, or have to RMA the board back to Mouser?

Alas, I have not found a good solution to this issue.

When the board was “naked”, simply tied to its power supply, I could easily put some adhesive tape and hold the SD card inside without too much troubles. I now have it inside a PC case, and it’s very difficult to hold the SD card inside with the same adhesive tape. The board’s backplate and its frame design is simply not compatible with such trick. The adhesive tape is not retaining the SD card enough for it to work.

I changed my SSD recently and so I can’t use the solution that you have found (hold the SD card manually during the boot-up procedure with an existing install on NVME).

I looked at the BOM and found the corresponding SD card connector from Molex at Mouser, in stock.

So I have two solutions now:

[1] - replace myself this SD connector: it’s doable as everything is soldered on one side of the PCB, and there’s not a lot of components around that I can damage. But it voids the warranty then.
[2] - go for the RMA as you mentioned.

It’s an unpleasant situation anyhow as I waited 6 months to get this board and if I take the RMA path, I don’t know when I’ll receive back a new board.

On Molex web site there’s a 3d model that I could open with FreeCAD to understand how the spring mechanism is working. There’s a small “U lever” that follows a path molded in a black plastic part. And on my case this lever has jumped outside this molded path. So the card is simply not retained inside through this lever. The spring is ejecting the SD card, always. And I haven’t found a way, even with a small pincer, to replace this lever inside its path. Anyhow, I doubt that this would work for long. I found the overall mechanical principle to be too weak, in my opinion. It’s not suprising that you had this issue too. And some others will probably follow.

All in all, I think I’ll go now for a RMA and hope to not face again the same issue.

I’ll buy a SD card adapter like this one:

… to plug once this adapter to the SD card connector and not touch the original connector anymore. If something breaks, it will be at adapter level, I hope.

[andre]

@gaby

I’ll buy a SD card adapter like this one:

were you able to get it to work? for me it seems there isnt enough current (?) to support that long cable and its as if i never plugged in an sdcard…

[gaby]

I tried one from a friend, which just look like the one in my snapshot. It didn’t work with the Unmatched. It worked on a Dell laptop which has a small SD-Card connector available.

I also remarked the same behavior as you (from the LEDs status on Unmatched mother board): no possible boot-up. Maybe this is due to the adapter’s cable length as you suggested. Maybe there’s another adapter which can still works with the Unmatched.

In the meantime my RMA request review started with Mouser. We will see the outcome.

[andersm (Anders Montonen)]

I use one of these extenders. It’s not as convenient as the ribbon cable ones, since it just sticks out of the rear panel, but it has worked well for me so far.

Edit: Forgot to mention that unlike the ribbon cable adapters, this extender fits into the machine even when using the console USB port.

[gaby]

Thanks @andersm for the hint and feedback ! I appreciate.

I guess @andre is right and the adapter’s cable length plays a role there.