Boot Zynthian from USB SSD

Someone tried it yet?
I just wrote the buster img to ssd and on boot it hangs after a while.

I never tried to boot from USB, sorry.

Give it a try.
For stable use a ssd would be better than corrupted fs.
m2 add on card I will give a try the next months.

I don’t think SD corruption is a serious problem for zynthian currently.
I know some people is concerned about SD corruption, but I hadn’t a corrupted SD in 4 years, and i hack my several zynthians every day …
Even if recording MIDI and audio directly to SD, what should be consider a less-than-secure practice, i didn’t get a corrupted SD.

Regards,

yeah,

difficult.
I used pi as pihole in the past.

two times sd fs corrupted
on after half a year working
on after update.

the raspbian sd never had problems on the working unit.

but better to stay safe and be faster.

reg
ingo

Hi,

I’m running Zynthian on a Pi4. I was using an SD card extender to be able to reach the card easily from my custom made housing. The extender however was giving issues (r/w errors). Since a beta bootloader has been released for the Pi4 that allows direct USB (SSD) boot I decided to give it a try.
On my Zynthian system, I followed the standard instructions on how to update the bootloader.
However, instead of copying the SD card, I burned a new Zynthian image on a usb stick (will be replaced by SSD), and overwrote ELF/DAT files as per instructions. If you want to burn/write the image to a USB SSD device on Windows, you first may need to create a partition on the SSD and perform a quick format so a drive letter is assigned and the drive will become accessible in order to allow the image to be written.

If you place the USB device in your PI now (without sd card inserted) the system will boot initially, but get stuck… this is due to an incorrect referal to the root file system on the SD card that does not exist anymore.

You can initially fix this (right after burning while the USB device is still in the host and before intial boot on the pi) by modifying cmdline.txt in the /boot directory, change current “root=/dev/mmcblk0p2” assignment to “root=/dev/sda2”, this will set the rootfs to point to the usb device.

Next step is to update the Zynthian cmdline.txt files that zynthian uses as template on a config change.
After starting the system with the USB drive inserted and SD card removed, also make the above modification in
/home/pi/zynthian-sys/boot/cmdline.txt
/home/pi/build/zynthian-sys/boot/cmdline.txt
(not sure if both files need to be changed)

IMPORTANT NOTE : You will need to redo the rename steps each time you updated Zynthian, before you reboot (so both the /boot/cmdline.txt and the two under /home/pi…) ; Just in case if you mess up here, simply redo all the cmdline.txt changes. In order to change the /boot/cmdline.txt you will offcourse temporary have to attach the USB device to another host computer.

Now you can configure Zynthian to match your hardware.

A final step is to expand the file system, raspi-config is setup to change the size of an SD card, so we need to do the following trick : “sed -E ‘s/mmcblk0p?/sda/’ /usr/bin/raspi-config | sudo bash” (credit the internet). Make sure to follow the hint to reboot the system directly after the file system is expanded.

After this you are good to go… so far no issues here…

For the real die hards… you can also update the bootloader settings, to first boot from USB and then from the SD card. This will allow to keep the SD inserted and to run different software by simply inserting a USB bootable device. It should also enable you to recover when the SD would get corrupted. (I had some issues with config.txt becoming corrupted on configuration changes, even with SD card directly inserted into the Pi).

5 Likes

Hi @SoulMan!
Nice walkthrough! It’s very clear and easy to follow. I like it! :+1:

We would love to see your housing! If you want, you can post some pics to this thread:


Welcome to the forum! :smiley:

1 Like

Are you able to provide any comparison between SD boot and USB, e.g. boot time, performance difference, etc?

Hi Guys,

Thanks for all the positive feedback :slight_smile:

My custom housing is a repurposed fancy/slylish mini settop box from my cable provider that became obsolete. I will post a couple off pics tonight. Although the current status is not to my standards yet… i messed up a bit milling the opening for the display. Due to the lack of a device blowing away the plastic waste, the plastic melted a bit and ended up on the cutter… and i have to rotate the display because of the orientation of the viewing angle, currently its hard to read when flat on the desk (need to make a V2). Once i have finalized which connections to add on the back,I still need to 3d print a back plate.

The housing is black but see through… im still debating what additional fancy lights (or lcd dot/text display) i can add to make it look even cooler :slight_smile: if you guys have any ideas for something “usefull” to indicate…

With regards to performance, I have not done any comparison. I’m awaiting a usb3 m.2 case and m.2 120GB SSD to come in. I can perform a boot up time with that setup.
I can check how quickly a synth loads … any specific wishes what to test where we could really notice a difference ?

br,

SoulMan

So my m.2 SSD came in :star_struck:
I tried to measure boot time.
sd card takes about 31 seconds… but because i have set boot order to usb - sd, the system waits for an usb device first before starting from sd… my guesstimation is that this takes about 6 seconds… so it leaves about 25 seconds of real start up time.
ssd starts right through and takes 21 seconds.

Adding a new synth layer (ZynAddSubFx) loading time is comparable.

I my setup i have wifi active, ssh, vnc. Audio set to [HifiBerry DAC+ light], Display: [WaveShare 5 HDMI+USB],Wiring: [MCP23017_EXTRA]
Both configurations run the same SW

I can confirm that you can “repair” your internal sd card while starting from usb by mounting it (accidently made the cmdline.txt changes on the sd card) …

1 Like

I got it working, but be warned! https://github.com/zynthian/zynthian-issue-tracking/issues/218

I followed these steps

https://www.raspberrypi.org/forums/viewtopic.php?f=56&t=279470&p=1692544&hilit=pi4+boot#p1692544

but where the poster goes “Also note that you must have already updated the eeprom on the raspberry pi 4” the relevent part is https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md

It’s not enough to update the firmware, you need to update the boot config as well.

I did it with this line

sudo rpi-eeprom-update -d -f /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-06-15.bin

the output of vcgencmd bootloader_config needs to show BOOT_ORDER=0xf41

Also https://github.com/zynthian/zynthian-issue-tracking/issues/219

:face_with_monocle:

3 Likes

Which zynthian base image did you use, please? Also, did you have to use the blank formatted card for first boot?

I used the one in the KXStudio thread. I still copied all the elf and bin files, I might give it a go without as I’d like to know if it worked. I didn’t need the blank sd card boot in the linked thread.

Ok, I now know where I went wrong…

Step 4 says to change cmdline.txt but it says filesystem is ext3… Probably fine for the Kali example, but zynthian needs it to be set to ext4.

Thanks baggy… I also had to redo after config as per your bug.

1 Like

I didn’t notice the ext3/4 difference. Also you don’t need to change fstab as it uses partid.

To temporarily solve the cmdline.txt device name it’s simply copied from $ZYNTHIAN_SYS_DIR/boot/cmdline.txt so you can probably edit that and it will update and reboot fine.

1 Like

I changed this file… next update changed it back.

1 Like

I was seeing a lot of these…

[17541.887261] mmc0: Timeout waiting for hardware cmd interrupt.
[17541.887266] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[17541.887272] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00001002
[17541.887276] mmc0: sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000
[17541.887279] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
[17541.887283] mmc0: sdhci: Present: 0x1fff0001 | Host ctl: 0x00000001
[17541.887287] mmc0: sdhci: Power: 0x0000000f | Blk gap: 0x00000080
[17541.887291] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x0000f447
[17541.887294] mmc0: sdhci: Timeout: 0x00000000 | Int stat: 0x00000000
[17541.887298] mmc0: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003
[17541.887302] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[17541.887305] mmc0: sdhci: Caps: 0x45ee6432 | Caps_1: 0x0000a525
[17541.887309] mmc0: sdhci: Cmd: 0x00000502 | Max curr: 0x00080008
[17541.887313] mmc0: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0x00000000
[17541.887317] mmc0: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000
[17541.887320] mmc0: sdhci: Host ctl2: 0x00000000
[17541.887324] mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000
[17541.887327] mmc0: sdhci: ============================================

Until I found this

That said “Without an SD card it’s best to put dtparam=sd_poll_once in config.txt - that will prevent (or minimise) the errors”

and it does!

2 Likes