Map it to the modwheel!
1 Like
We could rescue the turbo button from 90s 
4 Likes
This is still in the Wiki, but the default now is no overclocking:
3.4 Install the thermal block
Zynthian V5.1 gets a 20% extra power from the RPi5 by overclocking the CPU up to 3 GHz. For this to work properly, we need to remove the heat generated by the RPi5’s components. As we don’t want a noisy fan, prone to failure, pushing dust inside our nice case, we are using the aluminum case as a huge heat-sink. This is achieved by the thermal block, a solid aluminum block that closely contacts with the RPi5’s chips and serves as a heat-highway to the aluminum case bottom, and from there, to the rest of the aluminum case. When your zynthian V5.1 is working hard, or when external temperature is high enough, you will note the aluminum case getting hot. This is good because it means the thermal block is doing its job of transferring heat from the inside to the aluminum case body, where it’s dissipated to the ambient environment.
Having understood all this, you may realize this is a key step for getting your V5.1 working at 100% of its capacity, so don’t be in a hurry and take your time to do a good job. Let’s start!
2 Likes
Updated!
Thanks @tunagenes !
2 Likes
Ah, thanks, so I hadn’t dreamed that I’d read that after all! Thanks @tunagenes !
Thanks @jofemodo for fixing it so quickly. One nitpick on the updated text: By default, the RPi runs at 2.4 GHz, not 2.3 GHz (vcgencmd measure_clock arm returns frequency(0)=2400020480 with no overclocking). I’d gladly change the Wiki page myself, but I don’t think I have an account for that.
Ok, so here’s a weird one. I don’t know if this is limited to this particular configuration (V4 with RPi5) or it’s a more general issue. After having changed the kit from ‘V4’ to ‘Custom’ in order to see what audio card options there were, and then back again to ‘V4’, I realized the change of kit had reset the Customizable switches to default values, so I changed S1 to Arrow Let and S2 to Arrow Right as that is my preferred configuration.
After powering down last night, I powered it up today, and was met with the dreaded ERROR screen. Tried flashing a separate SD card with a stock image, which worked fine, so, not a hardware problem. Thinking that my reconfiguration experiments had led to a corrupted config.txt, I was surprised to see that the this file was identical to the original.
So, back to my failed installation. Closer inspection of dmesg and journalctl -p 4 first led me to believe there was a regulator configuration problem owing to the numerous pcm512x 1-004d: supply AVDD not found, using dummy regulator messages, but these were also present when booting from the reflashed card, so although a bit unsightly, they were not apparently not the issue. The following lines brought me closer to the solution:
designware-i2s 1f000a0000.i2s: ASoC: error at snd_soc_dai_set_fmt on 1f000a0000.i2s: -22
HiFiBerry DAC+ADC PRO: ASoC: error at snd_soc_link_init on HiFiBerry DAC+ADC Pro: -22
snd-rpi-hifiberry-dacplusadcpro soc:sound: snd_soc_register_card() failed: -22
snd-rpi-hifiberry-dacplusadcpro: probe of soc:sound failed with error -22
While this initially seemed to indicate a problem specifying the format, some googling led me to this page: I2S audio DAC (hifiberry-dacplus) not working on Raspberry Pi 5 · Issue #5724 · raspberrypi/linux · GitHub, leading me to try adding ,slaveto the Driver Config (Hardware → Audio) in the webconf (again requiring me to change to ‘Custom kit’ in order to be allowed to change the options). And presto, Zynthian starts up again and audio works. Tried removing ,slave, fails again, added it back, works.
The github thread mentions:
Pi 5 (specifically RP1) has slightly different I2S capabilities than those found on the BCM2835 family of processors. It gains the ability to do dual- and quad-lane I2S, but it has separate clock producer (master) and clock consumer (slave) blocks. This means that each overlay has to specify the correct I2S controller - producer or consumer. For most soundcards this is a fixed property, but a few of them can operate in either mode, which causes a problem.
This might be an explanation, but why it worked without ,slave before (which I’m assuming it did - or perhaps something did actually mess up config.txt and remove this option - but then why is it not needed on the reflashed SD card, and if I had it on my card before, how did it get there?) I don’t know. Perhaps someone has more on this issue, including an explanation for why this changed. I’m thinking perhaps some form of race condition at startup causes the Pi to select the wrong configuration sometimes, but in my case it was very stable one way or the other.
EDIT: Ok, having gotten that to work, the next thing that has gotten messed up is that the screen does not react to touch. Newly flashed SD card works fine, so again not a hardware problem, Sure, I can backup all my settings, and continue with the reflashed card, but since I haven’t really done anything wrong with this one I want to figure what has failed, as it’s not practical to restart with a fresh image every time something goes wrong. BTW, why is the dtoverlay for the screen piscreen2r-notouch, that would imply a non-touch-sensitive screen.
1 Like
Why would you want to forcefully use an installation for an RPi4 on an RPi5?
It may work partially, but you are calling up a bunch of problems.
I guess this also explains why your RPI5 does not consume more power than the RPi4, which it would normally do, because it does not use the RPi5 features and speed.
Please consider doing a clean install on the RPi5.
The forum software is suggesting PM here, but I think the summary is of public interest as well:
Change from RPi4 to RPi5 requires a fresh install for that board, because processor and periphery are different.
I’ve tested it and ondemand reduces power cosumption and temperatures significantly on the RPi5, especially when clock max is 3GHz. (I’ve built extremely good cooling, so temperature is less of a concern, anyway, but it can be measured.) The RPi5 has the RP1 I/O chip that has own clocks for i2s and UART, so on well-coded software synths there should be no impact by CPU speed changes.
Actually, I’ve reverted the changes to stock and no overclock, because I don’t know if there will be some plugin failing with that dynamic clock changing and I prefer reliability over power saving. With overclocking, is anyway not so much performance gain on complex programs, because memory transfers are the bottle-neck, anyway, and as long as there is any part of the program not cache-optimised, that will determine performance of it all.
You are right @fussl!
For instance, this is a fragment from the first boot script:
if config_name == "V5" and os.environ.get('RBPI_VERSION_NUMBER') == '5':
config_file = f"zynthian_envars_{config_name}_pi5.sh"
else:
config_file = f"zynthian_envars_{config_name}.sh"
As you can see, the config file template is different depending of your RBPi version.
If some of you want to re-use a SD-card installation after changing the RBPi version, you should “reset” the card so the first boot process is run again. This would do the task:
set_first_boot.sh
All the best,
1 Like
Sorry for the confusion in the thread; initially I did indeed try just moving the SD card from the RPi4 to the RPi5 and but had problems with the ethernet interface. So I moved to a clean install booted first time on the RPi5 and have been working from there (through various updates and reconfigurations).
The problem with the audio card manifested itself after having used the device successfully for several days, after which I reconfigured the softkeys (“Configurable Switches” (Hardware → Wiring), which worked fine, until I powered down and up the next day. The system was working perfectly until then.
BTW, I also tried running set_first_boot.sh and rebooting but it didn’t solve the issue with the audio card or touch screen.
Looking at the boot log, I could see the touchscreen controller (ads7846 driver) being recognized and loaded, but it was not getting recognized as an input device.
At this point I gave up, backuped my data, and started with a fresh oram install. One thing I realized is that I’d used this SD card for various other RPi5 Zynthian experiments, including a touchscreen-only setup with a HDMI+USB touchscreen, so I’m suspecting the accumulated effort of all the experimentation and reconfiguration eventually corrupted something somewhere. After flashing another card with a fresh image, updating it, adding my custom kernel (with midi-uart0-pi5 fix and CME UF6 support), and restoring various presets from various SD cards I’ve used in Zynthian over the past years, I’m back in business. Hoping it will stay stable now.
This also seems to have fixed another issue: Whenever I rebooted, for some reason Zynthian failed to recognize my Keystage. It didn’t show up in lsusb or anywhere else, and needed to be power cycled to be detected and recognized. Not a big issue, just a mild annoyance. But now after reflashing the SD card it is recognized every time.
I guess the moral of the story is go easy on reconfiguration, when the hardware has been determined, do a fresh flash of an SD card. After all that is the overshadowing usecase for most Zynthianers.
If you do simple, forward upgrades then things should work. That is the most tested process. If you are moving around (forward, backwards, sideways) then you may encounter configuration changes that have not been considered or coded for. (My RPi5 is in a stange state which I attribute to the amount of switching I do during development. I suspect I will need to rebuild it soon.
Yeah, I don’t think I did anything but upgrades, but I might have tested various configuration options for the screen and sound card back and forth. I was using an early Pisound for the soundcard initially, which needed upgrading, so at one point I was unloading and loading modules and reconfiguring the GPIO by hand, although that in itself shouldn’t have affected any stored configuration options I would have thought. But I do remember switching between different 'Kit’s and things of that nature.