04-09-2023, 04:41 AM
(This post was last modified: 04-09-2023, 04:42 AM by balbes150.)
(04-08-2023, 09:15 AM)CounterPillow Wrote: [quote pid="116764" dateline="1680699708"]
Anyone?
You'll have to use device tree overlays for that, but I don't think DietPi supports those.
[/quote]
Enabling overlay is not difficult. If overlay support is not enabled in the dietpi kernel, it is easy to replace the core (take it from armbiantv, overlay is enabled there).
https://forum.pine64.org/showthread.php?...#pid116276
(04-09-2023, 04:41 AM)balbes150 Wrote: (04-08-2023, 09:15 AM)CounterPillow Wrote: [quote pid="116764" dateline="1680699708"]
Anyone?
You'll have to use device tree overlays for that, but I don't think DietPi supports those.
Enabling overlay is not difficult. If overlay support is not enabled in the dietpi kernel, it is easy to replace the core (take it from armbiantv, overlay is enabled there).
https://forum.pine64.org/showthread.php?...#pid116276
[/quote]
Overlays shouldn't be done with kernel patches. They should be enabled through mainline u-boot.
(04-09-2023, 07:59 AM)CounterPillow Wrote: Overlays shouldn't be done with kernel patches. They should be enabled through mainline u-boot.
Absolutely the opposite. Using u-boot for overlay is a very bad solution. The correct solution is to perform the overlay "on the fly" in a running system, analogous to PnP drivers. Using u-booth to overlay, you will have to reboot the entire system at every change and do a bunch of stupid work.
(04-10-2023, 01:24 AM)balbes150 Wrote: (04-09-2023, 07:59 AM)CounterPillow Wrote: Overlays shouldn't be done with kernel patches. They should be enabled through mainline u-boot.
Absolutely the opposite. Using u-boot for overlay is a very bad solution. The correct solution is to perform the overlay "on the fly" in a running system, analogous to PnP drivers. Using u-booth to overlay, you will have to reboot the entire system at every change and do a bunch of stupid work.
Absolutely the opposite. "on-the-fly" overlays were rejected by the mainline kernel because they're a bad hack. Of course, Armbian loves carrying bad hacks around, which is why people keep complaining that they can't get more than a week's worth of uptime in the chats with it.
(04-10-2023, 04:13 AM)CounterPillow Wrote: (04-10-2023, 01:24 AM)balbes150 Wrote: (04-09-2023, 07:59 AM)CounterPillow Wrote: Overlays shouldn't be done with kernel patches. They should be enabled through mainline u-boot.
Absolutely the opposite. Using u-boot for overlay is a very bad solution. The correct solution is to perform the overlay "on the fly" in a running system, analogous to PnP drivers. Using u-booth to overlay, you will have to reboot the entire system at every change and do a bunch of stupid work.
Absolutely the opposite. "on-the-fly" overlays were rejected by the mainline kernel because they're a bad hack. Of course, Armbian loves carrying bad hacks around, which is why people keep complaining that they can't get more than a week's worth of uptime in the chats with it.
I'm not wedded to DietPi. Been using Plebian too. Which does have overlays because they work for SPI.
H
(04-10-2023, 04:13 AM)CounterPillow Wrote: (04-10-2023, 01:24 AM)balbes150 Wrote: (04-09-2023, 07:59 AM)CounterPillow Wrote: Overlays shouldn't be done with kernel patches. They should be enabled through mainline u-boot.
Absolutely the opposite. Using u-boot for overlay is a very bad solution. The correct solution is to perform the overlay "on the fly" in a running system, analogous to PnP drivers. Using u-booth to overlay, you will have to reboot the entire system at every change and do a bunch of stupid work.
Absolutely the opposite. "on-the-fly" overlays were rejected by the mainline kernel because they're a bad hack. Of course, Armbian loves carrying bad hacks around, which is why people keep complaining that they can't get more than a week's worth of uptime in the chats with it.
Show how you will enable the overlay in EFI mode (using u-boot and with EDK2). In the main core, the part uses the opinion of "authoritative" idiots who do not understand the essence. Example - placing dtb files in the root system is complete idiocy. And there are more than enough such examples. But idiots stupidly repeat this idiocy referring to "this is used in the main core, so this is the right decision." And if you follow your logic, all overlays are hacks that violate security and stability, so they should not be used. The only correct solution is to use a full-fledged DTB with included content at once at the level of the entire DTB.
Show examples that Armbian cannot provide uptime.
How many users use your system ?
09-26-2023, 09:21 AM
(This post was last modified: 09-26-2023, 09:22 AM by MichaIng.)
If someone can show me a method to enable device tree overlays on-the-fly on mainline Linux 6.5.y, I am open to try it. I have however never seen such, despite for a very short time on Raspberry Pi with their vendor kernel/bootloader and "dtoverlay" command, which worked with only a very small number of their overlays, while in most cases it just caused kernel errors and did not enable the intended functionality. From that point on I was pretty sure that there is no reliable way to enable kernel device tree overlays on-the-fly, but I am open to be proven wrong.
In the meantime, even extlinux has support for (not on-the-fly) device tree overlays with fdtoverlay setting, so theoretically we could add some. Our U-Boot might be too old, as it is still a fork based on 2022.10, but I should be able to switch to mainline U-Boot, now that it supports adding (the sadly needed) SPL and DDR blobs properly.
But, it might be easier to enable I2S/SPI/... interfaces just OOTB, as long as they do not collide and the GPIO pins do not have conflicting uses.
(09-26-2023, 09:21 AM)MichaIng Wrote: If someone can show me a method to enable device tree overlays on-the-fly on mainline Linux 6.5.y, I am open to try it. I have however never seen such, despite for a very short time on Raspberry Pi with their vendor kernel/bootloader and "dtoverlay" command, which worked with only a very small number of their overlays, while in most cases it just caused kernel errors and did not enable the intended functionality. From that point on I was pretty sure that there is no reliable way to enable kernel device tree overlays on-the-fly, but I am open to be proven wrong.
In the meantime, even extlinux has support for (not on-the-fly) device tree overlays with fdtoverlay setting, so theoretically we could add some. Our U-Boot might be too old, as it is still a fork based on 2022.10, but I should be able to switch to mainline U-Boot, now that it supports adding (the sadly needed) SPL and DDR blobs properly.
But, it might be easier to enable I2S/SPI/... interfaces just OOTB, as long as they do not collide and the GPIO pins do not have conflicting uses.
link
https://forum.armbian.com/topic/24931-ar...ent=160812
(09-27-2023, 02:14 AM)balbes150 Wrote: (09-26-2023, 09:21 AM)MichaIng Wrote: If someone can show me a method to enable device tree overlays on-the-fly on mainline Linux 6.5.y, I am open to try it. I have however never seen such, despite for a very short time on Raspberry Pi with their vendor kernel/bootloader and "dtoverlay" command, which worked with only a very small number of their overlays, while in most cases it just caused kernel errors and did not enable the intended functionality. From that point on I was pretty sure that there is no reliable way to enable kernel device tree overlays on-the-fly, but I am open to be proven wrong.
In the meantime, even extlinux has support for (not on-the-fly) device tree overlays with fdtoverlay setting, so theoretically we could add some. Our U-Boot might be too old, as it is still a fork based on 2022.10, but I should be able to switch to mainline U-Boot, now that it supports adding (the sadly needed) SPL and DDR blobs properly.
But, it might be easier to enable I2S/SPI/... interfaces just OOTB, as long as they do not collide and the GPIO pins do not have conflicting uses.
link
https://forum.armbian.com/topic/24931-ar...ent=160812
Thanks. However, it does not seem to work reliably. Tested on VisionFive 2:
Code: root@DietPi:~# cd /sys/kernel/config/device-tree/overlays
root@DietPi:/sys/kernel/config/device-tree/overlays# mkdir test
root@DietPi:/sys/kernel/config/device-tree/overlays# cat /boot/dietpi-visionfive2-8GB.dtbo > test/dtbo
root@DietPi:/sys/kernel/config/device-tree/overlays# cat test/status
applied
root@DietPi:/sys/kernel/config/device-tree/overlays# free -m
gesamt benutzt frei gemns. Puffer/Cache verfügbar
Speicher: 3872 659 2753 198 700 3213
Swap: 0 0 0
root@DietPi:/sys/kernel/config/device-tree/overlays# dmesg | tail -1
[62252.093999] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /memory@40000000/reg
So the overlay was applied successfully, in this case for 8 GiB RAM support, but it did not have an effect. The very same was the case with the majority of the RPi overlays I tested this (with their dtoverlay comnmand) a while ago. I think most features simply cannot be changed or added plug&play with the device tree, but the kernel and/or driver(s) need to initialise with them being set in the first place. And the memory leak warning was the very same on RPi and at least does not sound great, though I am not 100% sure if/when/how this applies or not.
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).
|
