c0rnelius

I'm told the bluetooth doesn't work, which is why I haven't submitted it. The patch was also done quick and dirty and I'm sure needs some clean up.
0001-arch-arm64-dts-allwinner-sun50i-h618-bananapi-m4-zero-v2.patch

I think the problem is Pine and not Armbian here. But I understand your point of view.

I've only worked with the BPI-M4-ZERO.
 
My personally opinion on the h616/8 line up is that the focus should be on stable and not LTS. Little to none of the official mainline patches are being back ported and the patches being used currently in LTS are kind of hack-a-noodle patches.
 
For example:
https://lore.kernel.org/linux-arm-kernel/CA+E=qVeMnQNrT8tNnHBnCL2Efy3VjbRAYQGMXstziCThRsiBDw@mail.gmail.com/T/
https://lore.kernel.org/linux-arm-kernel/20240419071450.7aiheeoyq35yjoo7@vireshk-i7/T/
 
The ones being currently used in Armbian I believe are either RFC's or taken from OPI. The thermal patch above is already in 6.9.y.
 
But with that said, if you have any questions feel free to hit me up and if I can, I'll help.

Kali is in a lot of ways a polished SID with all of their own custom bits added. It can be debootstrap'd just like Debian, Devuan and Ubuntu. I did find some services didn't work on boot; 'ssh avahi bluetooth ntp'. But there could be some option they have I'm not aware of to allow those services to start out of the box. Creating a custom service to start those does the trick though.
 
I would think adding this as an option could be doable, but the question then becomes who wants to handle the support required to maintain it?
 

Not ideal, but: sudo halt

I'm using overlay meson-g12a-radxa-zero-i2c-ee-m1-gpiox-10-gpiox-11.dtbo
sudo i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Overlay meson-g12a-radxa-zero-i2c-ee-m3-gpioa-14-gpioa-15.dtbo works for me as well.
 

If that doesn't work, you are more than welcome to donate to Armbian so the baseboard can be purchased and a proper OVERLAY or DTS can be created for it. As I will not be buying another baseboard out of pocket to do so.
 

Although this is doable. It would be a fairly large undertaking.  Any services and custom services currently used, would need a sysvinit equivalent. Then there is the question, would this also need to be integrated into armbian-config?  Probably, yes. Would all features in armbian-config even be supported in Devuan? I seriously doubt it. Also depending on how debs specific to Armbian are currently put together and the depends they may or may not have, those would also need to be modified.
 
Plus it would need to be extensively tested. I have found some scripts I run that are linked to services sometimes need modification when using them on Devuan. 
 
For a lot of boards though, on a basic level. It could be done.

Although this is doable. It would be a fairly large undertaking.  Any services and custom services currently used, would need a sysvinit equivalent. Then there is the question, would this also need to be integrated into armbian-config?  Probably, yes. Would all features in armbian-config even be supported in Devuan? I seriously doubt it. Also depending on how debs specific to Armbian are currently put together and the depends they may or may not have, those would also need to be modified.
 
Plus it would need to be extensively tested. I have found some scripts I run that are linked to services sometimes need modification when using them on Devuan. 
 
For a lot of boards though, on a basic level. It could be done.

This requires patching, I'm not sure if it has been submitted yet.
 
You are more than welcome to test it.
 
001-arch-arm64-dts-sun50i-h5-thermal-support.patch
 
A similar patch is also needed for the A64.

The boot partition is flagged ESP, which the PI3 does not support.
 
Model: Generic MassStorageClass (scsi) Disk /dev/sdd: 32.0GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 4194kB 273MB 268MB primary fat32 esp 2 273MB 4106MB 3834MB primary ext4  
Removing the ESP flag from the boot partition should allow the image to boot on both the RPi3 and RPi4. This can be easily done using gparted.
 
if you are comfortable using the command line:
sudo parted /dev/XXX set 1 esp off   

My efforts into this are done. I was asked to make it boot and get it functioning, not to produce images for the masses. I think as that goes, I did as much. Sorry the kernel doesn't have everything "that everyone ever wanted" ticked on, but that wasn't a concern of mine at the time. With that said, I added support for it in the defconfig, if you or someone else wants to compile their own kernel for those images, you are more than welcome too.
 
Honestly, I would suggest people check the commit: https://github.com/armbian/build/pull/4247 and help provide proper Armbian support. 
 
Thanx

9bx154, its uploaded. #4

I've also noticed using an overlay to overclock the RK3399 on 5.15.y doesn't work, although in my testing it does work fine on 5.17 / 5.18.y. One solution is to patch the rk3399-opp.dtsi and add a turbo-mode switch. This way the board can be overclocked on the fly with a simple `echo "1" > sudo tee /sys/devices/system/cpu/cpufreq/boost`.
 
 
013-rk3399-opp-overclock-2GHz-turbo-mode.patch

My efforts into this are done. I was asked to make it boot and get it functioning, not to produce images for the masses. I think as that goes, I did as much. Sorry the kernel doesn't have everything "that everyone ever wanted" ticked on, but that wasn't a concern of mine at the time. With that said, I added support for it in the defconfig, if you or someone else wants to compile their own kernel for those images, you are more than welcome too.
 
Honestly, I would suggest people check the commit: https://github.com/armbian/build/pull/4247 and help provide proper Armbian support. 
 
Thanx

Very good news about landed patches. 
Tobetter's posture: shortsighted. He's also contradicting himself, having worked on board DTs for Banana boards. 
 
 
Yeah, here's an edge 5.19 version, which is a snapshot/git format-patch of tobetter's 5.19 at some point, rebased to 5.19.4 and now rolled-forward by armbian to 5.19.12.
It does not carry an u-boot anymore, and uses less crazy partitioning. All blobs are from HK's SPI.
It now requires the SPI u-boot with skip_spiboot = true, https://wiki.odroid.com/odroid-m1/software/boot_sequence#bypassing_petitboot
CLI: https://github.com/rpardini/armbian-release/releases/download/20221007a/Armbian_20221007a-rpardini_Odroidm1_jammy_edge_5.19.14.img.xz
      👆☝️

Vendor u-boot needs to be purged from the eMMC: https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R5S#The_Boot_order_between_eMMC_and_SD_card
I drop test imgs and kernels here: https://github.com/pyavitz/binary/releases/tag/images
 
What was last reported;
5.19.3-2022-08-22 boots but no m.2, nor proper eth led functions.
5.19.6 I was told it booted, but then upon powering down the device it wouldn't come back. No other info given.
Only change between 5.19.3 and 5.19.6 was a defconfig adjustment.
 
Not tested;
5.19.8-2022-09-10 pin-ctrl added in hopes it brings up the m.2 and a custom led patch for the eth ports.
 
Can open an issue there or find me on IRC / Discord.

I'll add it to the build and see what people report. Thanx.

I think I can help here as I'm already working on this off and on. The problem I have is I don't own the hardware, so I'm not going to be submitting any thing to Armbian. But so far "as I'm told by the tester" I have the board booting and everything working except the m.2 and eth leds. Those two bits are a WIP and I'm currently waiting for the tester to get back from holiday so he can see if its working now.
 
As for submitting the work to Armbian. I'd be happy to point whom ever to what I've done so far and help where I can.

I'll start by saying I don't own the board, but as this has come up and seems to be a problem across many boards using the same SoC and bits, it would appear on its face that the fix is probably generally the same across them all. Give or take a few differences?
 
My github reference to the issue: https://github.com/armbian/build/issues/1352#issuecomment-952077351
 
I've included two patches you could test that I made for 5.10.y as that appears to be the kernel ur using.
 
One thing I do not mention in the github issue is I also include the following to /etc/modules
# /etc/modules: kernel modules to load at boot time. # # This file contains the names of kernel modules that should be loaded # at boot time, one per line. Lines beginning with "#" are ignored. bluetooth hidp rfcomm bnep hci_uart  
 
002-sun50i-h5-orangepi-zero-plus2-rfkill-gpio.patch 001-sun50i-h5-orangepi-zero-plus2-bluetooth-support.patch

I can't be 100% sure, but I believe I saw a pull request for this some time ago where some one removed some things related to the reboot issue. I haven't scanned through the patch set as of late, but in my testing the following is needed.
 
Need to revert:
drivers/gpu/drm/meson/meson_drv.c
https://github.com/pyavitz/debian-image-builder/blob/feature/patches/amlogic/odroid/002-linux-odroid-patch-set.patch#L524
https://github.com/pyavitz/debian-image-builder/blob/feature/patches/amlogic/odroid/002-linux-odroid-patch-set.patch#L542
 
Add Odroid reboot:
https://github.com/pyavitz/debian-image-builder/blob/feature/patches/amlogic/odroid/002-linux-odroid-patch-set.patch#L2323
https://github.com/pyavitz/debian-image-builder/blob/feature/patches/amlogic/odroid/002-linux-odroid-patch-set.patch#L2533
 
If you review the pull request, you can see where the revert and odroid power reset patch was removed: https://github.com/armbian/build/pull/3154/files
 
As for mainline u-boot the only thing of real importance is the following revert: https://github.com/armbian/build/pull/3154/files#diff-65100acf19e202ac3f3980da554c205752ea3c67d08fc4a3b445d4397189d12fR36
 
With out it, the boards "especially the N2/+ will kernel panic, as the reserved memory "CMA pool won't be set correctly".  So the patch forces the boards to be marked nomap, hence populated after uboot hands off to the kernel.
 

I believe what is required is this commit added to the meson64 patch set. https://github.com/tobetter/linux/commit/a026e2e9f55116e81ed49f48d918fdb91e28eff6

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?

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.