(09-29-2023, 02:02 PM)balbes150 Wrote: 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?