Cornelius

sudo apt install -y python3-pip; sudo pip3 install bpytop

That's my N2+ burning on all cores running slightly under clocked. It is very rare if it ever gets to 50*C. So for sure the script comes in handy.

I've seen that happen before and has more to do with how people set the systemd services on the OS up more than anything. Most services "if any?" don't account for the rc-local service, so sometimes putting a sleep on your script is the easiest route to take. Happy its working for you.

On the unit make sure what the script is looking for is there `ls /sys/devices/virtual/thermal/thermal_zone0/trip_point_4_temp` As far as I know, on Hardkernel, Armbian and my own image that is the only location that the trip point is located? I guess I should add a check in the functions there to give an error, instead of a bash cry? As for the trip points, I didn't develop anything and as far as I know in my testing that can be set to whatever? It doesn't have to be 35000, it could be 20000 if someone so wanted, which would just make the fan run all the time as the board idles higher than that. I place mine at 45000 as it seems like a happy medium when compiling on it.

In the terminal execute: fan-ctrl -h This will show you a list of all the options available, which include the trip points you can set. Once you select a trip point the script takes note of the choice you made and runs its self. Your trip point is now set and the fan will spin up at the given temp you chose. So in rc.local from that point on you just need to use the run function: fan-ctrl -r You can look over the script here to see what its actually doing: https://github.com/pyavitz/scripts/blob/master/fan-ctrl

Remove all this from /etc/rc.local: [Service] ExecStart=/usr/local/bin/fan-ctrl -r &>/dev/null Type=oneshot RemainAfterExit=yes [Install] WantedBy=multi-user.target EOF sudo systemctl enable odroid-fan-ctrl # Options Odroid N2 Trip Point Usage: fan-ctrl -h -1 65°C -2 55°C -3 45°C -4 35°C -r Run -u Update The script is downloaded already, correct? Set the trip point, for example: fan-ctrl -3 Now have the script run upon boot by adding it to /etc/rc.local. Example: #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. /usr/local/bin/fan-ctrl -r exit 0 That's it!

It's pretty much just a copy and paste job, the above commands do all the work for you. I've personally never used it on Armbian and the only thing I can think of that could create a problem is if the service runs before the armbian-hardware-optimize.service. If that's the case, its an easy enough mod to the odroid-fan-ctrl.service file followed by a daemon-reload. But yeah, using the /etc/rc.local file will accomplish the same thing. You only need to set the trip point once and then have the rc-local service run the script: fan-ctrl -r

I created a script to set the trip point, which can then be run at boot with a service or by placing it in /etc/rc.local # Script sudo wget https://raw.githubusercontent.com/pyavitz/scripts/master/fan-ctrl -P /usr/local/bin sudo chmod +x /usr/local/bin/fan-ctrl # Service sudo tee /etc/systemd/system/odroid-fan-ctrl.service <<EOF [Unit] Description=Odroid Fan Control ConditionPathExists=/usr/local/bin/fan-ctrl [Service] ExecStart=/usr/local/bin/fan-ctrl -r &>/dev/null Type=oneshot RemainAfterExit=yes [Install] WantedBy=multi-user.target EOF sudo systemctl enable odroid-fan-ctrl # Options Odroid N2 Trip Point Usage: fan-ctrl -h -1 65°C -2 55°C -3 45°C -4 35°C -r Run -u Update The systemd service runs 'fan-ctrl -r' during boot. One down side is that it requires sudo to work, so you would need to either edit the script to your needs or setup sudo, so that you don't need a password to execute. But then again, it shouldn't matter when being run as a service, as root shouldn't care about sudo?

The kernel and build I use is custom, so I found it to be a pointless venture to bother trying to post it. He is currently on 5.10.y and we are both on 5.14.y "mine being 5.14.9", which is kind of a different beast from the current LTS. Also it isn't Armbian related, so to me it would make more sense to check the other kernel options he has available to him self, than to just throw out random full dmesg's that will most likely not be the same. But that's just my opinion.

There is apparently a partial revert that was accepted: https://lore.kernel.org/linux-rockchip/20211001160238.4335a83d@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/T/#t diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c index ed817011a94a..6924a6aacbd5 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c @@ -21,6 +21,7 @@ #include <linux/delay.h> #include <linux/mfd/syscon.h> #include <linux/regmap.h> +#include <linux/pm_runtime.h> #include "stmmac_platform.h" @@ -1528,6 +1529,8 @@ static int rk_gmac_powerup(struct rk_priv_data *bsp_priv) return ret; } + pm_runtime_get_sync(dev); + if (bsp_priv->integrated_phy) rk_gmac_integrated_phy_powerup(bsp_priv); @@ -1539,6 +1542,8 @@ static void rk_gmac_powerdown(struct rk_priv_data *gmac) if (gmac->integrated_phy) rk_gmac_integrated_phy_powerdown(gmac); + pm_runtime_put_sync(&gmac->pdev->dev); + phy_power_on(gmac, false); gmac_clk_enable(gmac, false); } -- 2.32.0 I haven't tested it my self.

The defconfig is what was used during kernel compilation. Beyond that its not gonna do you much good unless you know exactly what you are looking for. You can find it under /boot/config-*. As for the board I'm running, its the NanoPC-T4. dmesg | grep model; dmesg | grep hdmi; lsmod | grep hdmi [ 0.000000] Machine model: FriendlyElec NanoPC-T4 [ 0.107313] platform ff940000.hdmi: Fixing up cyclic dependency with ff8f0000.vop [ 0.107394] platform ff940000.hdmi: Fixing up cyclic dependency with ff900000.vop [ 3.196953] dwhdmi-rockchip ff940000.hdmi: Detected HDMI TX controller v2.11a with HDCP (DWC HDMI 2.0 TX PHY) [ 3.197886] rockchip-drm display-subsystem: bound ff940000.hdmi (ops dw_hdmi_rockchip_ops [rockchipdrm]) [ 5.948920] rc rc0: dw_hdmi as /devices/platform/ff940000.hdmi/rc/rc0 [ 5.948995] input: dw_hdmi as /devices/platform/ff940000.hdmi/rc/rc0/input12 snd_soc_hdmi_codec 24576 1 snd_soc_core 262144 5 snd_soc_rockchip_pcm,snd_soc_hdmi_codec,snd_soc_simple_card_utils,snd_soc_rockchip_i2s,snd_soc_simple_card snd_pcm 126976 3 snd_soc_hdmi_codec,snd_soc_core,snd_pcm_dmaengine dw_hdmi_cec 16384 0 snd 94208 4 snd_soc_hdmi_codec,snd_timer,snd_soc_core,snd_pcm dw_hdmi_i2s_audio 16384 0 dw_hdmi 53248 2 dw_hdmi_i2s_audio,rockchipdrm drm_kms_helper 278528 4 dw_mipi_dsi,rockchipdrm,dw_hdmi,analogix_dp cec 57344 3 drm_kms_helper,dw_hdmi_cec,dw_hdmi drm 552960 8 gpu_sched,drm_kms_helper,dw_mipi_dsi,rockchipdrm,dw_hdmi,panfrost,analogix_dp I'm not seeing a lot of difference here beyond me not getting that drm being skipped bit. You should be able to change kernels using armbian-config "last time I checked?", its possible that a downgrade or upgrade may solve your problem. If you have a spare monitor or even a TV with an HDMI port, it might be a good idea to give that a shot.

Not owning the board my self I can't say for sure, but I do have a RK3399 from the same vendor and HDMI is fine and I'm also running Ubuntu. In my experience it has very little to do with the distro you are running and more to do with the kernel. If you are seeing an output during the initial boot process, but not when it gets handed off to the kernel, than that would suggest to me its kernel related. Maybe something isn't ticked on in the defconfig of that build? Have you tried a different kernel? Do you see anything of substance in dmesg or lsmod? dmesg | grep hdmi; lsmod | grep hdmi Edit: Have you tried a different monitor? Maybe it doesn't like the default resolution of the current display you are using? Most monitors have a auto detect button or option, have you tried pressing it?

I found this on lore.kernel.org: https://lore.kernel.org/linux-rockchip/YS0v9UbzoHkiU9om@sashalap/T/#t Apparently they're looking into a proper fix, but nothing has come of it yet.

I haven't noticed any eth related problems on 5.13.y and RK3399, but when moving to 5.14.y I also found that eth no longer worked. I corrected the issue by reverting the following commit: https://github.com/torvalds/linux/commit/2d26f6e39afb88d32b8f39e76a51b542c3c51674 I understand its not a true fix. This was tested on the NanoPC-T4. --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c 2021-09-12 03:01:00.000000000 -0400 +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c 2021-09-14 07:19:24.402736613 -0400 @@ -21,6 +21,7 @@ #include <linux/delay.h> #include <linux/mfd/syscon.h> #include <linux/regmap.h> +#include <linux/pm_runtime.h> #include "stmmac_platform.h" @@ -1528,6 +1529,9 @@ return ret; } + pm_runtime_enable(dev); + pm_runtime_get_sync(dev); + if (bsp_priv->integrated_phy) rk_gmac_integrated_phy_powerup(bsp_priv); @@ -1536,9 +1540,14 @@ static void rk_gmac_powerdown(struct rk_priv_data *gmac) { + struct device *dev = &gmac->pdev->dev; + if (gmac->integrated_phy) rk_gmac_integrated_phy_powerdown(gmac); + pm_runtime_put_sync(dev); + pm_runtime_disable(dev); + phy_power_on(gmac, false); gmac_clk_enable(gmac, false); }

Other than the suggestion I made before I see nothing really wrong with it. It's way more complicated than my approach and written better, but that would be expected. This is Armbian after all. I see some variables I don't understand such as $MAKE and $SRCARCH, but I'm going to assume that makes sense in the builder somewhere. I also notice that none of the pre/post scripts define what they are..? Such as #!/bin/bash or #!/bin/sh, but that would only be relative during the kernel install and have nothing to really do with creation. Only major difference I see, is you appear to be using the builddeb/mkdebian files from 5.10.y, where as I use the 5.4.y files and patch them accordingly to the SoC I am building for. I find it to be a more simplistic builddeb script and less of hassle to deal with and the kernel doesn't complain when I replace the ones it comes with. Example packaging I use for my test builds. https://github.com/pyavitz/debian-image-builder/tree/feature/patches/packaging Disclaimer: I don't recommend anyone using that builder, it's mostly a pet project and learning tool for myself. As for the slow down you are getting in the VM, I really have no ideas as to why that would be. I never use a VM when building, although I do use Docker sometimes.