Werner

This board isn't a supported by Armbian.  Moved to Community Supported/Unmaintained section of forums.

@ReneHegewald I'll add a couple of points to what @Werner has already mentioned.
The board you are using RockPi 5B is not supported by Armbian.  It is Community supported.  That means Armbian doesn't have any resources that work on this board.  All support for the board is done by community members like you.  There generally is little that happens to community supported boards.  Usually someone will submit some work to get the board initially setup and then shortly after disappear and nothing happens to the board again until it stops building at all and then it gets dropped.  Unfortunately this is the reality of support for these boards.  You are using software for free and it takes significant resources (both money and time) to make a board work well.  There are very few people that are willing to donate a hundred hours of time to work on getting a board fully supported and maintain it over time with no compensation.  Unfortunately the manufactures of these boards take advantage of the open source community.  They in house initially do some minimum work to get something running, then once released move on to their next board and don't support the software and hope the open source community does it for free. 
The best thing you can do, is build up your skills and contribute back to the community in exchange for the free software you are using.

@Werner thank you very much for your reply, I understand it's hard to manage such a project, I wish I could help but I don't have the time 😕 
I guess I'm SOL for my project using the RockPro64, I'll donate to help you anyway and wish you good luck!

Yes, that will work unless there is some special weirdness in the R1S-H3 that needs custom drivers...which I doubt for now
 

don't know if this method still works but thought i'd share it 

https://github.com/armbian/documentation/issues/116

Yeah, why not. As CSC of course.

Post the log of your build

Hey @amazingfate, the above-mentioned av1 decoder issue was fixed, turned out that the Rock 5A and a few other boards did not have the av1d node enabled in the device tree. I did update ffmpeg and added some patches to mpv last night, after testing everything it looks good to go. 

The packages ffmpeg, librga, libv4l-rkmpp, mpp, and mpv are ready to be copied to your PPA. 

https://launchpad.net/~jjriek/+archive/ubuntu/rockchip-multimedia/+packages?field.name_filter=&field.status_filter=published&field.series_filter=jammy

There are actual two ways. You can use code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } ./compile.sh KERNEL_CONFIGURE=yes which will continue to assemble an image with the modified config file which is more user friendly.
On the other hand there is code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } ./compile.sh kernel-config which will export the modified kernel config into code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } output/ folder and stops there which is more developer friendly.
If you chose latter route you need to move the exported config to userpatches or overwrite the one in code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } config/kernel/. Once you done that simply execute code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } ./compile.sh and the modified config will be used.

Hi,
 
=y means the driver/functionality is directly compiled into the kernel
=m means it will be built and made available as kernel module
 

When you have been involved with Armbian for a length of time (and read a few of igor's rants 🙂 ) you will realize why what was said here will not be received well by many within Armbian.
It isn't that what you are saying isn't a reasonable comment.  The problem is that Armbian is under resourced by probably an order of magnitude.  Discussions are continually occurring on how the project can survive let alone move forward.  Many of those conversations involve discussing how more can be done with less resources, ways to cut features/scope to make what exists manageable.  So by you saying to "put [more work] onto developers in Armbian is far better than ..." you are hitting a nerve.  In the current environment that will never pass muster.  Any proposed solution needs to maintain or reduce developer work in the long term.  So any feature suggestion is going to be measured first against that metric, then secondarily by the merits of that feature. 
 
This whole dtd discussion is fundamentally a request for a new feature for Armbian.  Regardless of the merits of your focus on the end user experience, that isn't the way Armbian has handled dtbs in any of the existing boards that are supported.  I'm not saying that what exists is good or desireable, but it is what it is.  Can it be improved, sure.  Can it be improved and at the same time not increase maintenance costs going forward, maybe.
 

https://debug.armbian.de

@bahtiyar57
 
 
_________________ FTDI232 BPI | _________________ | | 3.3v |_____ ____ UART GND o|---------------|o GND o| | || | | Linux TX o|---------------|o RX o| | USB|| |====USB cable===| console RX o|---------------|o TX o |____||____| | "minicom" _________________| |________5v______| o| 3.3v
o|
This is the jumper on the device.
I use this scheme. Everyone uses this scheme. It's safe.

Absolute awesome. Thank you @Igor for the fast response. Now all the kernel and kernel headers are there and I can compile additional kernel modules. Highly appreciated!

There never was a cert since it is just a simple redirect to https://armbian.myspreadshop.net/ so feel free to use this address.

https://debug.armbian.de

if the whole OS is no longer on a SD card you can disable ramlog in /etc/default/armbian-ramlog.

Player left the game. Case closed.

I have hit this problem (on a non-dkms OS), it helped patching this symbol restriction:
 
https://github.com/armbian/linux-rockchip/pull/142

https://openzfs.github.io/openzfs-docs/Developer Resources/Building ZFS.html
 
[ 424.596656] zfs: module license taints kernel. [ 425.491531] ZFS: Loaded module v2.2.99-311_gd9cb42da9, ZFS pool version 5000, ZFS filesystem version 5  
tested on OPi5 with kernel 6.7.1
 
Getting it working on legacy 5.10.y rk Android-hackedtogether kernel is a bot tougher.
https://github.com/radxa/kernel/issues/54
Spoiler: patching method does not work anymore, at least not for me . Tested with 5.10.160...
 

Check /etc/default/armbian-zram-whatever file. Don't remember the exact name
 

here is some 2 cents comments, if you are meaning NPUs like these:
 
https://github.com/rockchip-linux/rknpu2
 
- hardware interfaces are kept as trade secrets and not published anywhere
 
1st the hardware interfaces are practically undocumented, what they provide is mostly an 'sdk' with some binary blobs
it practically means there is *no way* to use the NPU as those binary blobs in turn depend on device drivers which again are binary blobs (no source)
and there is no hardware documentation any where about the technical details, registers etc. 
if that at least those are published, one could possibly start coding something to test things on the NPU.
 
then that for things like ethos-n78
https://www.arm.com/products/silicon-ip-cpu/ethos/ethos-n78
you can find some info here
https://developer.arm.com/Processors/Ethos-N78
but that it seemed the real SOCs with that chip is no where to be seen let alone any boards found with them.
 
- IO / cpu scheduling 
 
cpu frequency scaling / governors are well documented
https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
https://docs.kernel.org/scheduler/schedutil.html
https://www.kernel.org/doc/html/latest/scheduler/
and for 'simple' ARM (or RISC V) chips, any sort of 'elaborate' scheduling are probably going to just burn more cpu cycles with little to gain.
but that nevertheless the source codes and the documentations are there so that one can try to develop your own governor if you prefer.
and that the elaborate 'advanced' schedutil governor is already there in the kernel, likely in Armbian as well.
Hence, one can proceed to improve that if one deem that the state-of-the-art currently isn't adequate.
 
and if one wants to do some manual scheduling there is the plain old "nice" command
https://www.scaler.com/topics/linux-nice/
 
----
well my thoughts, scheduling and NPU are 2 unrelated issues, it is possible to handle 'elaborate' scheduling without an NPU, this is currently the state-of-the-art from the 'lowly' ARM boards that we are running, to top tier high core count Intel Xeon / AMD Epyc processors and running all that loads ranging from amazon, google, chatgpt etc, no issues.
 
The other thing being the NPUs itself, currently many SOC IP owners, held their hardware interfaces as *trade secrets* and refused to release them.
You would need to jump that hoop to even use the NPU without any documentation, or else use their proprietary binary blob software, which won't work outside their proprietary binary blob distributions.
 
This withheld *trade secret* about the NPU is the biggest pitfall / trap to those buying those boards with those SOCs and wanting to use the NPU. you get *no support*, *no help*, *no nothing* after you buy the board which purportedly has the NPU. practically *useless*. don't even bother to try it for any 'test' 'AI' stuff, you may at best get a *binary blob demo* and that's it (and it is not anywhere close to even using it for any practical purpose, let alone scheduling).
 
And much more than that, using an NPU practically means that your neural network model must be *quantized*, if you know what that means. All those small NPU hardware normally handles like 8 bit integers, 16 bit integers or at best 16 bit floats. This practically means that you would need to spend a lot of effort to *convert* even ordinary neural networks into the *quantized* form that can be processed by the NPU, if you can't convert that it is  unusable. Even if you managed to convert that there is a risk of lost of precision, e.g. if you convert a 32 bit float down to an 8 bit int, you may practically be quantizing a number space of 4 billion numbers (actually more) to 256 quantized levels. that is the extreme of the information loss, and at the end of the day, if it even works, you may simply get *wrong* results, and again it is practically *useless*.
 

"legacy" is a term that thas been established years ago when there wasn't much confusion about it. However things have changed and now it is, depending on board family, either an old-LTS just for historical purpose or a vendor kernel which may or may not significantly outdated but working.
Anyway there are discussion about renaming that into "vendor" or something, however the impact would be huge if not done carefully.
 
If anyone steps up doing, testing and maintaining this, why not? We won't simply due to lack of human resources.

You should be up-to-date regarding "current" branch. Since "edge" kernels are not available through this you can try building and installing those packages by yourself.
https://docs.armbian.com/Developer-Guide_Build-Preparation/
 
Anyway also an option is to try an older one, like 5.15.y and see if the issue disappears....

"legacy" is a term that thas been established years ago when there wasn't much confusion about it. However things have changed and now it is, depending on board family, either an old-LTS just for historical purpose or a vendor kernel which may or may not significantly outdated but working.
Anyway there are discussion about renaming that into "vendor" or something, however the impact would be huge if not done carefully.
 
If anyone steps up doing, testing and maintaining this, why not? We won't simply due to lack of human resources.