SD-Card slot broken

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.

1 Like

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 :sweat_drops:

1 Like

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!

@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 :grinning:

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 :wink:
  • 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.

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)

2 Likes

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.

2 Likes

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

2 Likes

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’ve read that somewhere, too. Maybe it’s not yet implemented.

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.