going

Compiling libmraa from source worked, per the instructions here.

Different series of the same chip.
It is sad. I'll think about what can be done.

I am not a git expert, but apparently what partially solved the compilation error was that I done this
git clone --depth=1 --branch=master https://github.com/armbian/build
 
instead of this:
git clone --depth 1 https://github.com/armbian/build
 
But this is just a hint.

In order to disable the patch, it is enough to put a minus sign at the beginning of the line with this patch in the "series.conf" file.
These patches exist, but they don't apply.

@going and @Igor checking the H616 mainlining thread, the x_late patch is running currently unoptimized WIP, we can improve on this as testing play's out. I will add the recommended thermal changes for now and can submit a pr to 6.1 they will be fine if that is good.

Tested:
Armbian_23.02.1_Bananapim64_jammy_current_5.15.93_minimal.img
The first start, boot, reboot is normal.
Found not included in the fix for "armbianmonitor" for one cluster.
Corrections here

I am collecting packages in a virtual machine.
The virtual machine and the running device are on a local network. I have ssh access to both.
mc

I have been building this project for a long time.
And at the moment, I don't see an alternative for the ARM architecture for real-time core operation with short response times.
@Igor The Xenomai4 project is already working well for sunxi today.
 
 
 
lsdiff patch-6.2-rc3-rt1.patch These are some basic changes. I don't see the necessary changes specific to rockchip, meson or sunxi files here.
In order for this patch to work, you need to add a lot of additional changes yourself.
 
And this is for working only in user space.
In any case, you will have to reassemble the entire chain for industrial production. kernel -> lib & modules -> linuxcnc

I have been building this project for a long time.
And at the moment, I don't see an alternative for the ARM architecture for real-time core operation with short response times.
@Igor The Xenomai4 project is already working well for sunxi today.
 
 
 
lsdiff patch-6.2-rc3-rt1.patch These are some basic changes. I don't see the necessary changes specific to rockchip, meson or sunxi files here.
In order for this patch to work, you need to add a lot of additional changes yourself.
 
And this is for working only in user space.
In any case, you will have to reassemble the entire chain for industrial production. kernel -> lib & modules -> linuxcnc

I tested with kernel 6.2RC4 (some driver code change needed), notes:
do not increase GPU voltage reg_dcdcc: dcdcc { regulator-always-on; regulator-min-microvolt = <810000>; - regulator-max-microvolt = <1080000>; + regulator-max-microvolt = <1100000>; regulator-name = "vdd-gpu-sys"; }; absolute maximum (from H616_Datasheet_V1.0_cleaned.pdf):

recommended (from H616_Datasheet_V1.0_cleaned.pdf):

my sun50i-h616-orangepi-zero2.dts: reg_dcdcc: dcdcc { regulator-always-on; regulator-min-microvolt = <810000>; regulator-max-microvolt = <990000>; regulator-name = "vdd-gpu-sys"; };  
I also reworked temperature - cooling
my sun50i-h616.dtsi: cpu_thermal: cpu-thermal { polling-delay-passive = <500>; polling-delay = <1000>; thermal-sensors = <&ths 2>; trips { cpu_target: cpu-target { temperature = <75000>; hysteresis = <2000>; type = "passive"; }; critical { temperature = <105000>; hysteresis = <2000>; type = "critical"; }; }; cooling-maps { map0 { trip = <&cpu_target>; cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; }; }; }; my sun50i-h616-orangepi-zero2.dts:
 
&cpu_thermal { /delete-node/ trips; // beaware, all points must have different names otherwise dts compiller does not hold position and driver stuck in differnt trip point trips { cpu_warm: cpu_warm { temperature = <75000>; hysteresis = <2000>; type = "passive"; }; cpu_hot_pre: cpu_hot_pre { temperature = <80000>; hysteresis = <2000>; type = "passive"; }; cpu_hot: cpu_hot { temperature = <85000>; hysteresis = <2000>; type = "passive"; }; cpu_very_hot: cpu_very_hot { temperature = <90000>; hysteresis = <2000>; type = "passive"; }; cpu_critical { temperature = <105000>; hysteresis = <2000>; type = "critical"; }; }; /delete-node/ cooling-maps; cooling-maps { cpu_warm_limit_cpu { trip = <&cpu_warm>; cooling-device = <&cpu0 THERMAL_NO_LIMIT 2>; }; cpu_hot_pre_limit_cpu { trip = <&cpu_hot_pre>; cooling-device = <&cpu0 3 3>; }; cpu_hot_limit_cpu { trip = <&cpu_hot>; cooling-device = <&cpu0 4 4>; }; cpu_very_hot_limit_cpu { trip = <&cpu_very_hot>; cooling-device = <&cpu0 5 THERMAL_NO_LIMIT>; }; }; };  
my testing 0 - idle 10 - run "stress --cpu 4" 36 - additional external heating 134 - remove heating 304 - stop "stress --cpu 4"

H616_User_Manual_V1.0.
Yes it is different from other allwinner chips. The register is read-only and a jumper is needed.

Unfortunately, this is not the only discrepancy.
 
I'm doing a little work, but it's about supporting a series of patches.
Which are applied using the function lib/functions/compilation/patch/patching.sh.
The day after the origin/linux-6.1.y branch appeared in linux-stable.git I extract from this repository
branch origin/orange-pi-6.1 all the commits that were applied from above. And it becomes a series of megous patches.
A series of armbian patches are those patches that one of the users once suggested for use.
I am not able to check all of them and the correctness of their work after applying them.
All I do is monitor their correct application when moving the kernel code upstream.
And I fix compilation errors if they occur.
@Igor also makes a huge contribution to this process.
We hope for your contribution to the development.
 

H616_User_Manual_V1.0.
Yes it is different from other allwinner chips. The register is read-only and a jumper is needed.

I was successful to boot uBoot over SPI-FLASH and continue to boot over network (PXE+NFS), and my few comments:
uboot (orangepi)
 - https://github.com/orangepi-xunlong/u-boot-orangepi.git (v2021.10-sunxi)
does not support SPI-FLASH boot  upstream uboot hungs, but it has patch to support SPI boot (since v2023.01-rc1)
- https://patchwork.ozlabs.org/project/uboot/list/?series=252044&state=*
- https://github.com/u-boot/u-boot/commit/e50ee3a8d7328142eb24741305f751e5c0952380 so I extend 1. with 2. (attached) and rebuild uBoot flash uboot, in linux ` nandwrite /dev/mtd0 u-boot-sunxi-with-spl.bin ` (erase: ` flash_eraseall /dev/mtd0 `) install jumper between PC5 and GND (13-14 pinheader)
... and boot U-Boot SPL 2021.10-g0b91e222-dirty (Jan 09 2023 - 02:10:12 +0100) DRAM: 1024 MiB Trying to boot from sunxi SPI NOTICE: BL31: v2.8(debug):f4d8ed5 NOTICE: BL31: Built : 23:43:55, Jan 7 2023 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a087b80, model: OrangePi Zero2 INFO: ARM GICv2 driver initialized INFO: Configuring SPC Controller INFO: PMIC: Probing AXP305 on RSB INFO: PMIC: aldo1 voltage: 3.300V INFO: PMIC: aldo2 voltage: 3.300V INFO: PMIC: aldo3 voltage: 3.300V INFO: PMIC: bldo1 voltage: 1.800V INFO: PMIC: bldo2 voltage: 1.800V INFO: PMIC: dcdcd voltage: 1.500V INFO: PMIC: dcdce voltage: 3.300V INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 855873 was applied INFO: BL31: cortex_a53: CPU workaround for 1530924 was applied INFO: PSCI: Suspend is unavailable INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 INFO: Changed devicetree. U-Boot 2021.10-g0b91e222-dirty (Jan 09 2023 - 02:10:12 +0100) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero2 I2C: ready DRAM: 1 GiB MMC: mmc@4020000: 0 Loading Environment from SPIFlash... SF: Detected mx25l1606e with page size 256 Bytes, erase size 4 KiB, total 2 MiB OK In: serial@5000000 Out: serial@5000000 Err: serial@5000000 Net: phy interface7 eth0: ethernet@5020000 Autoboot in 2 seconds, press <Space> to stop MMC: no card present ethernet@5020000 Waiting for PHY auto negotiation to complete.. done BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 2 *** Unhandled DHCP Option in OFFER/ACK: 42 *** Unhandled DHCP Option in OFFER/ACK: 4 *** Unhandled DHCP Option in OFFER/ACK: 252 *** Unhandled DHCP Option in OFFER/ACK: 2 *** Unhandled DHCP Option in OFFER/ACK: 42 *** Unhandled DHCP Option in OFFER/ACK: 4 *** Unhandled DHCP Option in OFFER/ACK: 252 DHCP client bound to address 192.168.1.242 (45 ms) *** Warning: no boot file name; using 'C0A801F2.img' Using ethernet@5020000 device TFTP from server 192.168.1.1; our IP address is 192.168.1.242 Filename 'C0A801F2.img'. Load address: 0x42000000 Loading: * TFTP error: 'Access violation' (2) Not retrying... missing environment variable: pxeuuid missing environment variable: bootfile Retrieving file: pxelinux.cfg/01-02-00-d2-c3-32-42 Using ethernet@5020000 device TFTP from server 192.168.1.1; our IP address is 192.168.1.242 Filename 'pxelinux.cfg/01-02-00-d2-c3-32-42'. Load address: 0x4fd00000 Loading: * TFTP error: 'Access violation' (2) Not retrying... missing environment variable: bootfile Retrieving file: pxelinux.cfg/C0A801F2 Using ethernet@5020000 device TFTP from server 192.168.1.1; our IP address is 192.168.1.242 Filename 'pxelinux.cfg/C0A801F2'. Load address: 0x4fd00000 Loading: # 11.7 KiB/s done Bytes transferred = 126 (7e hex) Config file found 1: linux missing environment variable: bootfile Retrieving file: uInitrd Using ethernet@5020000 device TFTP from server 192.168.1.1; our IP address is 192.168.1.242 Filename 'uInitrd'. Load address: 0x4ff00000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ######################### 9.2 MiB/s done Bytes transferred = 15625901 (ee6ead hex) missing environment variable: bootfile Retrieving file: Image Using ethernet@5020000 device TFTP from server 192.168.1.1; our IP address is 192.168.1.242 Filename 'Image'. Load address: 0x40080000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ###################### 9.8 MiB/s done Bytes transferred = 22259720 (153a808 hex) append: root=/dev/nfs nfsroot=192.168.1.1:/sunxi/ ip=dhcp rw missing environment variable: bootfile Retrieving file: dtb/allwinner/sun50i-h616-orangepi-zero2.dtb Using ethernet@5020000 device TFTP from server 192.168.1.1; our IP address is 192.168.1.242 Filename 'dtb/allwinner/sun50i-h616-orangepi-zero2.dtb'. Load address: 0x4fa00000 Loading: ### 706.1 KiB/s done Bytes transferred = 38323 (95b3 hex) Moving Image from 0x40080000 to 0x40200000, end=417a0000 ## Loading init Ramdisk from Legacy Image at 4ff00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 15625837 Bytes = 14.9 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 Loading Ramdisk to 49119000, end 49fffe6d ... OK Loading Device Tree to 000000004910c000, end 00000000491185b2 ... OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 5.16.17-sun50iw9 (martin@martin-v15) (aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #3 SMP Wed Jan 11 14:07:16 CET 2023 [ 0.000000] Machine model: OrangePi Zero2 [ 0.000000] NUMA: No NUMA configuration found [ 0.000000] NUMA: Faking a node at [mem 0x0000000040000000-0x000000007fffffff] [ 0.000000] NUMA: NODE_DATA [mem 0x7fdca040-0x7fdcbfff] [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000040000000-0x000000007fffffff] [ 0.000000] DMA32 empty [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000040000000-0x000000004007ffff] [ 0.000000] node 0: [mem 0x0000000040080000-0x000000007fffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x000000007fffffff] [ 0.000000] cma: Reserved 128 MiB at 0x0000000076c00000 [ 0.000000] psci: probing for conduit method from DT. [ 0.000000] psci: PSCIv1.1 detected in firmware. [ 0.000000] psci: Using standard PSCI v0.2 function IDs  
spiboot.patch

Ok! This means that something has been fixed.
I was building this release htop/releases/tag/3.2.1
 
 I'll check the build from the head git.

I have removed htop from our repository. We are at least good for the future.

Can you post some technical specifications?
The thermal dissipation power of this device.
And for comparison, the maximum power allocated on the processor.

What I am observing here is not a lack of support for this particular armhf architecture.
This is an incorrectly constructed construction algorithm in the assembly system itself.
The analysis of the architecture that needs to be built and the architecture on which the build system started working looks pretty trivial and it already exists.
To do this analysis and upload only what is required for this task does not look like something complicated.

P.S. This also applies to the master.

Yes. It is a process that requires human. What I automated is the boring part, so the human only has to use the eye at the end of it. At least for trivial rebases.
It is part of the Python patching system, but only used if invoked manually by a developer. Don't worry.
 

Ricardo, all we need in the future is a lot of additional versioning of the commands that we use in the build system.
And a message to the user if the version is lower than the required one.
Linux OS can be anything if the versions of the commands meet the requirements.
This will save us from a lot of discussions on the forum.

😄 Ricardo well done! This is an incentive for the correct design of patches.
The patch should contain a description in this style. Otherwise, it may be difficult for another person to understand what has been done and for what purpose. This is also necessary so that the patch can be applied as a git am command.

This opportunity is necessary for professionals.
I have almost implemented such an opportunity to build and develop packages in a chroot environment.
And this remains only in my local branch for now.
 
First, we need to make a small adjustment in the logic of choosing goals.

I see two ways.
1) You can turn the user's @hoov manual into a debian/rule file.
Mount the already patched kernel into the build environment and assemble the kernel module.
Take my branch. https://github.com/The-going/armbian-build/tree/chroot_build_pkg
Use the parameter mount_linux_src=yes
https://github.com/The-going/armbian-build/blob/1e9a7a1b24e5d5aead730f58ad910124782b5576/lib/chroot-buildpackages.sh#L313
 
Here I help the user to build a debian package in a chroot environment, bypassing many unnecessary steps.
 
2) I wanted to try to rework the debian rules directly from the original ubuntu repository:
/gituser/ubuntu-kernel> mkdir jammy /gituser/ubuntu-kernel> cd jammy/ /gituser/ubuntu-kernel/jammy> git init /gituser/ubuntu-kernel/jammy> git remote add origin git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy /gituser/ubuntu-kernel/jammy> git fetch /gituser/ubuntu-kernel/jammy> git checkout -b hwe-5.19-next origin/hwe-5.19-next I'll take that as a basis. Everything is available here. We only need to choose what we will take.

This is what can be confidently called the most correct part of the algorithm.
 
You've already done everything! Well done!
This is something that I am happy to store in a local folder.
And the ability to extract from the archive to the target folder cache/sources/linux-mainline.
This algorithm will greatly save free space inside the virtual machine.
 
But then the process of creating these archives in the build system is not necessary. It becomes a simple periodic manual work. Update this storage once a month.

The reference for why this was written: https://github.com/armbian/build/pull/3476#issuecomment-1042063299
(mricon is from the Linux Foundation, who appeared after our CI was banned from kernel.org due to too much shallow fetching)
 
Also https://github.com/armbian/build/pull/3476#issuecomment-1042322996