Time for the Buster RC-3 SD image

Thanks for that :smiley:

and how do I do that …? :smiley:

It’s turtles all the way down I tell ya…!

For backing up an SD card the same strategy would work, but in reverse: you create an image file from the SD card in the sd card reader.

Indeed, it’s turtles all the way down:

The only gotcha is you don’t want to make a backup of an SD card that is actually running the OS, so you need another machine to do that (or another SD card to boot your same raspberry pi) to make a backup of another SD card.

It might be easier and certainly faster from a PC, but it’s certainly doable from a RP alone, you just need an extra SD card with an OS containing DD that won’t be touched, and external SD card reader/writer. One you’re there make an image of the original SD card to an image file (using dd) and keep it somewhere safe in case ou need to restore it (again, dd will do that).
Once you have the backup, boot from that image to actually attempt to WRITE a NEW image to a new SD card (now knowing you have a backup of the OS you’re running in case you mess up).
If all is succesfull you can try and boot the new SD card.

I’ve never attempted it this way, but you’re sure to spend a lot of time on this and have some exciting moments :slight_smile:

Or you could simply do it from a PC… It won’t lock up the PC for very long…

Here’s some more light reading if you’re really heading this way:

1 Like

@twelve Thanks for this, so if I understand this right. Having a rpi to dd the image onto the sd card fixes the RC3 problem? (or am I completely misunderstanding the cs_high issue?)

Ah no worries & sorry I misunderstood I think.

So consensus for now is to give RC3 a bit of a wait and continue with RC2 for burning onto SD and use the built-in system update to get to the latest and greatest. Check :slight_smile:

That’s right :slight_smile:

Confirmed! It’s the SPI CS issue. I downgraded to kernel 4.19 that doesn’t have the issue using this command:

sudo rpi-update e1050e94821a70b2e4c72b318d6c6c968552e9a2

Reboot, and everything is working again! :wink:

I changed the build system to use the latest Raspberry Pi OS with kernel 4.19 and tomorrow’s build should be functional. Cross fingers!!

Thanks a lot!

3 Likes

The linked kernel discussion suggests the problem may lie in the device tree and how the control line are selected. It suggests the kernel issue is resolved and that overlays must be correctly selected. Maybe there is another issue I missed.

For me I get problem with USB on the RC2 so I will (try)

YES ! working again…

Thanks…

Another issue, with the RC3 and the e1050e94821a70b2e4c72b318d6c6c968552e9a2 kernel is the USB Midi Keyboard been detect ONLY if plugged AFTER bootup…
If the USB Keyboard stay connected at boot, it will not been detected at all, also if moved from the USB port to another USB port…

tryed with a fresh new Kit V4 and a RPiv4

Hi! We have a new green build and it should be functional:

https://os.zynthian.org/2020-08-08-zynthianos-buster-lite-armhf-1.0.0.zip

Stop downloading and testing this image. It’s not workig OK…

I would like to test this image as a candidate for RC3 (RC3C :yum:) and ask for your help, beloved community as, due to the “New Subnormality”, i’m still living on a little country house with only 4G connectivity, quite limited for downloading SD images … so … if you download, test and the basics are working OK, i will download and test in detail.

Regards,

I had to use

sudo rpi-update e1050e94821a70b2e4c72b318d6c6c968552e9a2

to get the display on v4 running.

1 Like

Thanks @C0d3man !

Zynthianers, please, stop downloading and testing the latest image. It’s not workig OK…

1 Like

Yeah, the ch_high issue was only merged 5 days ago so you need the bleeding edge firmware you get from rpi-update.

OK @zynthianers!

I would like to propose a new candidate for RC-3 (must i say RC3C? :grin:)

https://os.zynthian.org/2020-09-03-zynthianos-buster-lite-armhf-1.0.0.zip

It should work out-the-box on v3 & v4 oficial kits. Older or customized kits would need to configure the hardware from webconf.

Please, download and test, test & test!!

Thanks for helping!!

5 Likes

Here are some results so far from the testing of this image (from a new SD card) on a V4 kit:
Boot & screen detection on V4 kit is ok!

Alsa Mixer out of the box doesn’t show what it should:
it’s initially configured as “Digital,ADC,ADC Left Input,ADC Right Input” and shows just 2 controls: ADC Left Input and ADC Right Input" (ignoring the first 2 entries, which seem to be impling Left/Right varieties but not correctly detected.
Correcting this in the webconfig to something along the lines of “ADC Left,ADC Right,ADC Left Input,ADC Right Input,Digital Left,Digital Right” or another ordering gives the original 6 controls back.

exfat USB disks are not detected/used. (Seriously, try buying and USB disk with any capacity from a major brand that’s not formatted as exfat. To me this is a flaw, and shouldn’t be solved by reformatting). The package exfat-utils is installed by default, but not providing the intended services.
(Something related; the default naming of snapshots includes “>”, which is not filename friendly at all, and downright impossible on (ex)fat(32) filesystems.)

I tried a few Synths, no real isues detected.

What audio effects that are configured by default are recommended for something as basic as a simple Mono->stereo conversion? I have settled on Calf Haas Stereo Enhancer and Calf Stereo Tools, both of which are not activated by default.

Please fix:

  • the initial ALSA configuration (rather crucial)
  • the exfat usb support (nice to have, not essential)

Yes. I see. It can be solved easily by a software update, although it’s suboptimal.

Sorry, this has never been supported. It’s not a flaw. If someone finds a way of configuring the “fuse exfat” driver for automounting an USB disk, i will integrate it. Until then, try to convince M$ to release the patent pending on exfat, so the driver can be included on the linux kernel :wink:

It’s already fixed :wink:

Thanks for testing!

2 Likes

I don’t think exfat support should block the RC. It is additional functionality hence can be bumped to next release. Nice to have but does not stop Zynthian working at least as well as it has.

Sure, this can wait until later.
Automatic mounting of exfat usb drives turns out to be less trivial than expected it seems.

I played around with it for a day now, didn’t detect any showstoppers.

There are a large number of plugins, especially Audio Effects :slight_smile:
Screenshot_20200905_211156

Not all plugins work though, but those can most likely be fixed through an update.
(For example the Drum Synth Geonkick (activated by default?) starts without any controls, and doesn’t respond to midi.)

Did anybody else test the image?

1 Like

OK @zynthianers!

This image is identical to the 2020-09-03, but fixes the little problem with the Mixer:

https://os.zynthian.org/2020-09-05-zynthianos-buster-lite-armhf-1.0.0.zip

Please, test with it and if nobody find critical issues, it will be the RC-3.

I can feel we are really close to release a stable image, that should last for a long time :star_struck: :star_struck:

Enjoy!

6 Likes

Hi @jofemodo, is there something like a test procedure, a protocol or something? Or is it just using it and reporting issues?

As soon as my v4 arrives I will test/use this build. If this build does not become RC3, do I need to install a new build afterwards or do I just need to perform an update?

Cheers,
Johann