09-30-2023, 06:27 AM
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".
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".