DietPi OS for Quartz64

[MichaIng]

RAM management, in principle, cannot work as an overlay. You're trying to use an overlay where it basically can't work. Have you seen on a regular PC that someone on a running system connected or disconnected the DDR memory strips and the system automatically changed the RAM? The PnP principle (dynamic overlay/parameter change) works only with equipment that can be dynamically reconfigured (load or unload drivers or change their settings, if they support it).

The overlay works perfectly fine when applying it via fdtoverlay parameter in extlinux.conf. StarFive themselves rewrite the device tree with this exact change on every boot, to support the 8 GiB variant. I just didn't like the fact that the dtb file on disk is rewritten on every boot, hence do this via overlay.

I am sure there are some features which do work dynamically, but I am not keen trying to find out what works and what not and then instruct users to apply this overlay dynamically while applying the other overlay only via boot config. Generally I also do not see the big problem of the need for a reboot, as long as this is the one and only method which simply works for every kind of (effective) device tree change.

But well, if someone requires a specific feature of the Quartz64 which causes problems when being permanently enabled with our kernel builds, and that particular one can be reliably toggled dynamically, then I am open to implement it + a dietpi-config option for it.

EDIT: I see I2C and SPI. Will look into this. Is there any downside to have both interfaces just enabled OOTB?

[balbes150]

RAM management, in principle, cannot work as an overlay. You're trying to use an overlay where it basically can't work. Have you seen on a regular PC that someone on a running system connected or disconnected the DDR memory strips and the system automatically changed the RAM? The PnP principle (dynamic overlay/parameter change) works only with equipment that can be dynamically reconfigured (load or unload drivers or change their settings, if they support it).

The overlay works perfectly fine when applying it via fdtoverlay parameter in extlinux.conf. StarFive themselves rewrite the device tree with this exact change on every boot, to support the 8 GiB variant. I just didn't like the fact that the dtb file on disk is rewritten on every boot, hence do this via overlay.

I am sure there are some features which do work dynamically, but I am not keen trying to find out what works and what not and then instruct users to apply this overlay dynamically while applying the other overlay only via boot config. Generally I also do not see the big problem of the need for a reboot, as long as this is the one and only method which simply works for every kind of (effective) device tree change.

But well, if someone requires a specific feature of the Quartz64 which causes problems when being permanently enabled with our kernel builds, and that particular one can be reliably toggled dynamically, then I am open to implement it + a dietpi-config option for it.

EDIT: I see I2C and SPI. Will look into this. Is there any downside to have both interfaces just enabled OOTB?

Using u-boot to change DTB (at the level of the loaded binary code in RAM that the kernel uses in its work) is just a "dumb" replacement of DTB, similar to if you build a completely new DTB (for example, using the DTC utility or add a new DTS file with the necessary parameters to the kernel build system) and not it has to do with dynamic "overlay" in a running system. I. e. you can immediately create many different ready-made DTBS with the necessary functions \ parameters for each case and just stupidly change the name of the DTB file used (for example, change the name in extlinux.conf) and get this so-called "overlay" (changed the name of which DTB to use, rebooted the system and voila, got the necessary functionality). This option will work with absolutely any startup system (where it is possible to specify the name of the DTB used) - extlinux, grub (UEFI), etc.

[MichaIng]

Yes, rewriting the DTB in U-Boot, which is what StarFive does, has nothing to do with overlays. I find this a highly problematic practice, hence I solved the 8 GiB support with an actual overlay, which works great when applying it via extlinux. And what I do has again nothing to do with dynamic overlay loading, but my method works, while loading the same overlay dynamically does not.

My point really is that you seem to indicate that dynamic overlay loading is the only correct method and doing it via U-Boot script or extlinux is not great as you need to reboot the system every time. And IMO this is a wrong view of things, as dynamic overlay loading, like in above example, does not work for all overlays, might cause subtile problems, memory leaks when removing them again (not sure, but the kernel messages say so) etc. So for systems where a lot of overlays are offered, like when using Armbian kernels and many of the vendor kernels, when aiming for a generic method to toggle overlays, IMO, doing this via boot script/extlinux/whatever non-dynamically is the only correct way. As only some overlays can be dynamically loaded, if this is wanted, then any distro offering it via some kind of UI or documentation, must implement or document two ways of toggling overlays, to assure or make clear that users are not trying to toggle an overlay dynamically which cannot work that way or causes even larger issues when trying it. And I am not sure whether either Armbian or DietPi are keen to implement and maintain two methods, given that both (all such) projects are chronically under-stuffed, and that a reboot, at least IMO, really is a very minor issue as you usually do not regularly toggle hardware features back and forth.

However, for the Quartz64, our kernel build does not ship with any overlay so far, and we have no UI or documentation to toggle them yet. So if the here requested I2C and SPI interfaces can be toggled reliably dynamically, without any downsides, I am open to implement it that way.

Ah one thing: Of course one usually expects hardware feature changes to persist reboots. So when implementing dynamic overlay loading, one needs to apply then statically anyway. And before adding a userland script which does the dynamic loading on every boot, it is much better (at least easier) to additionally add them via extlinux/boot script/..., isn't it? The only problem then surely is that a statically loaded overlay cannot be dynamically removed, at least not without adding another dynamic overlay which reverts the change of the static one . Hmm, the more I think about it, the more I dislike the mix of these methods. Probably I should read a little more into the related kernel docs, to check whether this really is a future-prove API or is seen problematic and might eventually get removed anyway. That there is a kernel warning spit out at all to me looks like a "do this if you must for testing, but do not do this on a production system/on a regular basis".

[stormwyrm]

I've tried using dietpi as my distribution for an SOQuartz and it seems to work pretty well enough. I've been having some trouble with some hardware support, most notably with sound. It seems that HDMI audio is not available and I can't figure out how to get that working. The only available sound hardware is analog audio out, but I'm using the Pine64 Model A carrier board which does not have a 3.5 mm audio jack output. No sound comes out from HDMI audio. I also have a set of Bose USB speakers that work perfectly with my Ubuntu laptop, but it seems that the snd-usb-audio module is not available and so plugging it in does nothing. I would try to build the kernel from source to add in the module but I don't know where to find the sources for firmware-soquartz. Any hints on how to get any sound output working for my setup?

[MichaIng]

I have the original baseboard as well. Let me have a look.

... I see the "hw:0,0  : HDMI fe400000.i2s-i2s-hifi i2s-hifi-0" audio device, is this the same for you? But it has no alsamixer controls. speaker-test reveals that it does not support many audio stream formats OOTB, so you might need to enable the auto-conversion plugin, e.g. via dietpi-config audio options.

I am a bit lazy currently to move around and attach an actual HDMI monitor. Let me know whether you see this device as well and whether the auto-conversion plugin helps, and in case if the "speaker-test" command produces output. If not, I'll have a closer look. Not sure if some kernel build flag is needed for additional HDMI PCM controls in alsamixer.

[stormwyrm]

I am a bit lazy currently to move around and attach an actual HDMI monitor. Let me know whether you see this device as well and whether the auto-conversion plugin helps, and in case if the "speaker-test" command produces output. If not, I'll have a closer look. Not sure if some kernel build flag is needed for additional HDMI PCM controls in alsamixer.

I tried to set this up and it seems to have worked! Setting HDMI output to the "hw:0,0  : HDMI fe400000.i2s-i2s-hifi i2s-hifi-0" device which is also present on my machine seems to have done the trick. YouTube videos play sound, and mplayer/mpg123 suffice to play most music and videos. I think this should be set default for the SOQuartz builds for the Model A baseboard.

Thank you so much for all your help, and your efforts in maintaining this distro!

[MichaIng]

I think this should be set default for the SOQuartz builds for the Model A baseboard.

Aside of the generic "USB DAC" option, which throws an error if not USB DAC is attached, this should be the only one anyway? I.e. which one did you select before? There is not really a way to detect a particular baseboard.

What we could change in general is: Currently, when you enable audio, at first "None" is selected as sound card, so one must select one explicitly. We could change it a way that, when audio is enabled for the first time, a sound card "default" is selected/setup automatically. For some boards there is even a "default" entry in the menu, which is often internally replaced by HDMI audio. For the Quartz64 there is no such, but, when passing "default" to the backend script, it will just use the "hw:0,0" PCM, which is HDMI audio anyway in this case. If there is a 3.5mm jack, it might be that one instead, and "hw:1,0" HDMI audio instead, however, probably having any sound card selected OOTB is better then none?

[stormwyrm]

Aside of the generic "USB DAC" option, which throws an error if not USB DAC is attached, this should be the only one anyway? I.e. which one did you select before? There is not really a way to detect a particular baseboard.

What we could change in general is: Currently, when you enable audio, at first "None" is selected as sound card, so one must select one explicitly. We could change it a way that, when audio is enabled for the first time, a sound card "default" is selected/setup automatically. For some boards there is even a "default" entry in the menu, which is often internally replaced by HDMI audio. For the Quartz64 there is no such, but, when passing "default" to the backend script, it will just use the "hw:0,0" PCM, which is HDMI audio anyway in this case. If there is a 3.5mm jack, it might be that one instead, and "hw:1,0" HDMI audio instead, however, probably having any sound card selected OOTB is better then none?

I don't think I selected one before, as the startup scripts didn't ask. Perhaps, as some other distros do (Plebian I think does this) there should be a separate image for each of the common baseboards, or provide the DTBs for each board (Manjaro's approach) which can be set up by editing extlinux.conf before first boot.

Speaking of which, I also have a Waveshare CM4 to Pi3 carrier board, and I can't use it, because for some reason all of the USB ports are non-functional no matter which distro I tried to use (DietPi, Manjaro, and Plebian all fail). I get a login prompt with no way to type a username and password. I read somewhere here:

https://forum.pine64.org/showthread.php?tid=18419

that it is possible to set up some kind of DTB overlay to get the USB on the carrier board working, but I don't know if that's doable with DietPi.

[MichaIng]

Ah okay. Audio is intentionally not enabled OOTB. It is done automatically when you install audio software via dietpi-software, otherwise you need to enable it via dietpi-config and select a sound card there, or install and setup "alsa-utils" (or PulseAudio if preferred) manually.

You can pre-configure the system prior to first boot via dietpi.txt on the FAT setup partition of the image (or directly on the ext4 partition if you flashed via Linux host), after flashing the image. Set AUTO_SETUP_AUTOMATED=1 and add AUTO_SETUP_INSTALL_SOFTWARE_ID=5 there to install ALSA automatically on first boot, which implies having said "default" sound card (hw:0,0) setup automatically.

With extlinux, you cannot really do something in this regards, which is why we did not add it to the FAT setup partition. But probably we can do that as well, in case someone wants to setup custom kernel command-line parameters.

Regarding the Waveshare CM4 baseboard: If an overlay is required, then this should be either part of the default RPi kernel (see /boot/overlays and in case the README file for a list of available ones), or provided by Waveshare. I checked some docs: https://www.waveshare.com/wiki/CM4-IO-BASE-A
They suggest to add dtoverlay=dwc2,dr_mode=host to /boot/config.txt, i.e. using the dwc2 driver instead of dwc_otg, and set it to host mode explicitly. Even if this is not your exact baseboard model, worth to give it a try.

[stormwyrm]

Regarding the Waveshare CM4 baseboard: If an overlay is required, then this should be either part of the default RPi kernel (see /boot/overlays and in case the README file for a list of available ones), or provided by Waveshare. I checked some docs: https://www.waveshare.com/wiki/CM4-IO-BASE-A
They suggest to add dtoverlay=dwc2,dr_mode=host to /boot/config.txt, i.e. using the dwc2 driver instead of dwc_otg, and set it to host mode explicitly. Even if this is not your exact baseboard model, worth to give it a try.

Not sure how that is supposed to work with DietPi though, as none of these files exist in /boot there. Not a big deal for now since th Waveshare CM4-to-Pi3 board doesn't have a 12v header I can plug my fan heatsink into and running the CM4 without heatsinks is a bad idea. I got to 71°C on moderate load that way.

One other thing that I wanted to see working are my FIDO2 security keys that are used for 2FA. I have several such keys that I require for access to some critical accounts, and they don't work. I get the following for my Yubico Yubikey:

Code:

[ 3985.502029] input: Yubico YubiKey OTP+FIDO+CCID as /devices/platform/fcc00000.usb/xhci-hcd.0.auto/usb1/1-1/1-1.1/1-1.1:1.0/0003:1050:0407.0006/input/input12
[ 3985.560558] hid-generic 0003:1050:0407.0006: input: USB HID v1.10 Keyboard [Yubico YubiKey OTP+FIDO+CCID] on usb-xhci-hcd.0.auto-1.1/input0
[ 3985.561965] hid-generic 0003:1050:0407.0007: device has no listeners, quitting

I think it needs CONFIG_USB_HIDDEV and CONFIG_USB_HIDRAW enabled in the kernel to work fully, and this seems to be disabled in the kernel build we have:

# gzip -d < /proc/config.gz  |grep HIDDEV

# CONFIG_USB_HIDDEV is not set

# gzip -d < /proc/config.gz |grep HIDRAW
# CONFIG_HIDRAW is not set


I'd try to rebuild the kernel myself (haven't done this in a very long time, not since my Gentoo days) but I don't know where to get the sources to do that.