going

@Hasan Ali The bootloader and kernel versions in your original firmware and what is going to Armbian are most likely different. You must convert the original dtb into a text file of the dts and create your own for your device and in accordance with the requirements and capabilities of the new kernel and u-boot versions. Add compilation capability to Makefile. Make these changes in the form of patches and add them to the appropriate directories in the userpatches/patch directory. Currently: cache/sources/linux-mainline/6.1> ls arch/arm64/boot/dts/allwinner/*h616* arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts u-boot> ls arch/arm/dts/*h616* arch/arm/dts/sun50i-h616.dtsi arch/arm/dts/sun50i-h616-orangepi-zero2.dts arch/arm/dts/sun50i-h616-x96-mate.dts

First, find the documentation for this device. Processor, memory chips, wifi\Ethernet chips. Read the documentation about the capabilities of the sunxi-tools utility. Build and install this program on your external Linux computer. Try to connect from this computer to the device that you are breaking. Try to read and save all the files that you managed to take. Of particular value is *.dtb. If there is a USB port on the device and it is possible to boot from it and luck to read and save a binary dtb file, then no special problems are expected. If there is no USB connector, then you will have to disassemble the device and pick up a soldering iron. Are you ready for such a development? I'm not an Android expert. I can only give advice on how to assemble an image using the armbian assembly system. Good luck. Write if something starts to work out there are people who have done hacking of such devices. You can search for them on the forum.

Sunxi-tools See custom-u-boot-configuration-howto

@rodw Why are you asking these questions about the real-time operation of the kernel here on this site? Here we can discuss the Armbian assembly system itself. Here we can discuss working on the devices of images that have been provided for download. If you use the Armbian build system and want it to be able to assemble a number of interdependent packages in a complex, then ask. I can direct you right now and I can provide my development branch for this. But it is best to discuss the source code of the kernel and linuxcnc on the linuxcnc forum.

Xenomai or rt-preempt today is a simple application of patches to the kernel source code. This process will not cause difficulties. But then we will need to build\rebuild several additional libraries and kernel modules and the application that uses these libraries loads and unloads modules. Obviously, it is necessary to prescribe dependencies correctly in this entire chain.

That's all I'd like to take care of. That is, to support the Xenomai4 assembly within the framework of the Armbian project. And this requires a mechanism for assembling and reassembling packages, such as is customary in basic distributions. Both will serve to popularize the assembly system.

embedded/xenomai

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

Oh my God! Igor, I have been in the Armbian team for a long time.

That's not so. Some patches are outdated and do not work in the 6.1 kernel. sunxi-6.1/series.conf the bad ones are off Some patches are applied and work, but these changes in the 6.1 kernel are useless. I only discovered this today. Most of the armbian patches were taken from those that were proposed for kernel.org . Those patches that were accepted are gone from this list.

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.

In devices with allwinner chips, a simple code is hard-wired that polls possible boot devices in the following order: 1) sd card 2) a memory chip soldered on the board. 3) if they are empty, the device switches to "fel" mode and becomes available when it is connected to another computer using a USB cable. In this mode, you have the opportunity to read or write any boot code to a soldered memory chip. This is done using the "sunxi-tools" utility. 1-2) When the boot code "u-boot" is found on one of these media, it starts working and scans the devices for downloading about which it has information. This process can be seen in the UART console. "u-boot" reads the file armbianEnv.txt For verification, you can boot from the SD card. Connect an external drive via the USB connector. Having previously written the file system of any OS to one of its partitions. Determine its UUID using the blkid command. Edit the file armbianEnv.txt on your sd card, register a new UUID for the root partition there and reboot.

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.

Женя конечно ДА. Of course YES. Now it will be possible to install the package that is already provided by the base operating system. In the future, perhaps we will collect the latest version being developed with our own fixes.

@Igor The package has been deleted, but the metadata stores information about it http://mirror.yandex.ru/mirrors/armbian/apt/pool/bullseye-utils/h/htop/htop_3.1.0-0~armbian20.08.2+1_armhf.deb 404 Not Found

Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2669 bytes read in 2 ms (1.3 MiB/s) ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 180 bytes read in 2 ms (87.9 KiB/s) No FDT memory address configured. Please configure the FDT address via "fdt addr <address>" command. Aborting! No FDT memory address configured. Please configure the FDT address via "fdt addr <address>" command. Aborting! It looks like you updated the kernel and the dtb, but interrupted the process and the installation did not finish its work. There are no necessary files. Two options: 1) Download a new one and burn the whole image to the sd card. 2) Use an adapter for SD cards. Attach it to a running Linux computer and mount the root partition in /mnt. Then use the chroot command and reinstall the kernel and dtb packages.

@ALIGMSTEN If you succeed with the configuration file, I will immediately add to the build system the construction of the current version of the htop package and configure it for our devices.

pkg libsensors-config : /etc/sensors3.conf /etc/sensors.d/ Now that Igor has cleared the repository of broken packages, you can install the system package and try to configure the library using this file

Unfortunately, the system package from this OS will not work properly for CPU temperature and frequency. I learned how to make the latest version from the developer's website: https://github.com/htop-dev/htop/releases/tag/3.2.1 But it shows the processor frequency not constantly, but with some different time intervals. The temperature does not show at all. The situation for today is like this. The old package that currently exists in the build system is either not being built (jammy) or is being built but does not work (Bullseye).

Hello Alistair. What operating system? Just delete this old one and install the one that comes with the system.

I have read the documentation published on the internet for this processor. But I did not find the characteristics of heat dissipation. I just assumed that you were able to find out this experimentally or learned this data from other sources. I also assumed that in the paper documentation attached to the radiator with a fan, the maximum power that it can divert into the air is written. I want to estimate the heat dissipation capacity for this processor before I purchase this device. Up to now, I have made do with simpler solutions for these small boards.

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.