usual user
-
Posts
543 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by usual user
-
-
-
6 hours ago, duing said:
I cannot access flash from mainline U-Boot
As long as you do not provide proper serial console logs, no one can tell what is going on.
I can't help you in this situation any further, and you have to find a solution for yourself. -
1 hour ago, duing said:
You're using Hardkernel's U-Boot.
Nope, my build is based on current mainline and even build on target (aarch64). I.e. no cross-compiling involved.
Oh, by the way, in my build bootstd scans any attached storage for a valid bootflow and uses the first found one.
The used hardware interface dosen't matter and even network is valid. -
3 hours ago, duing said:
How do you write U-Boot to SPI NOR flash?
Usually I do that via the U-Boot console, since I build my firmware with SPI command support for devices with SPI flash.
With an added convenience command, it's just a "==> run mmc-fw-to-sf" to transfer firmware currently running from microSD.
So everything is self-contained, no external components involved. -
15 hours ago, aleksandriusz said:
Can't confirm, still the same thing.
You made me curious, so I rebooted for the first time after my previous report to activate my current versions.
I' m now at kernel 7.0.0-0.rc1.15.fc45.aarch64 and U-Boot 2026.07-rc1 (May 22 2026 - 00:00:00 +0000).
No regressions can be observed and it works as fast as before. -
-
It happened a few days ago that I rebuilt my complete firmware package to try something with another device. An HC4 firmware binary also automatically falls out in this process.
If you like, you can put it on a microSD card (dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/${entire-device-to-be-used}), place the prepared microSD card in your HC4 and start it with the boot button pressed.
Check whether it meets your expectations, and if all tests are successful, you can transfer it to the SPI flash. -
37 minutes ago, eselarm said:
What U-Boot/bootloader is in the MTD?
The one from my firmware build.
-
1 hour ago, aleksandriusz said:
Could anyone subscribed to this thread confirm that's still the case?
Since I haven't restarted the M1 for some time, I am currently still at:
# uptime 12:56:23 up 115 days, 1:51, 5 users, load average: 1.76, 1.26, 0.92 # uname -a Linux micro-015 6.18.0-65.fc44.aarch64 #1 SMP PREEMPT_DYNAMIC Sun Dec 7 20:40:45 CET 2025 aarch64 GNU/LinuxI still get:
Spoiler# iperf3 -c odroid-m1 Connecting to host odroid-m1, port 5201 [ 5] local odroid-m2 port 38866 connected to odroid-m1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 114 MBytes 959 Mbits/sec 0 553 KBytes [ 5] 1.00-2.00 sec 113 MBytes 946 Mbits/sec 0 648 KBytes [ 5] 2.00-3.00 sec 112 MBytes 941 Mbits/sec 0 684 KBytes [ 5] 3.00-4.00 sec 111 MBytes 930 Mbits/sec 0 809 KBytes [ 5] 4.00-5.00 sec 113 MBytes 949 Mbits/sec 0 809 KBytes [ 5] 5.00-6.00 sec 112 MBytes 943 Mbits/sec 0 809 KBytes [ 5] 6.00-7.00 sec 112 MBytes 940 Mbits/sec 0 809 KBytes [ 5] 7.00-8.00 sec 112 MBytes 940 Mbits/sec 0 809 KBytes [ 5] 8.00-9.00 sec 112 MBytes 935 Mbits/sec 0 850 KBytes [ 5] 9.00-10.00 sec 112 MBytes 942 Mbits/sec 0 850 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 0 sender [ 5] 0.00-10.01 sec 1.09 GBytes 940 Mbits/sec receiver iperf Done. # iperf3 -R -c odroid-m1 Connecting to host odroid-m1, port 5201 Reverse mode, remote host odroid-m1 is sending [ 5] local odroid-m2 port 50806 connected to odroid-m1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 92.2 MBytes 773 Mbits/sec [ 5] 1.00-2.00 sec 89.0 MBytes 746 Mbits/sec [ 5] 2.00-3.00 sec 88.1 MBytes 739 Mbits/sec [ 5] 3.00-4.00 sec 73.6 MBytes 618 Mbits/sec [ 5] 4.00-5.00 sec 89.5 MBytes 751 Mbits/sec [ 5] 5.00-6.00 sec 89.9 MBytes 754 Mbits/sec [ 5] 6.00-7.00 sec 77.5 MBytes 650 Mbits/sec [ 5] 7.00-8.00 sec 83.5 MBytes 701 Mbits/sec [ 5] 8.00-9.00 sec 84.6 MBytes 709 Mbits/sec [ 5] 9.00-10.00 sec 84.0 MBytes 705 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 853 MBytes 715 Mbits/sec 214 sender [ 5] 0.00-10.00 sec 852 MBytes 715 Mbits/sec receiver iperf Done.So nothing to complain about.
-
On 5/1/2026 at 11:46 AM, ando said:
Any tips to troubleshoot
According to the circuit diagram, the reset button is connected to the hardware reset lines, so nothing can prevent forcing the reset state.
-
1 hour ago, zjd said:
It doesn't see NVMe device on PCI bus.
At least that explains the result of the nvme scan command.
Now it remains to find out why this is the case, but since improvements are still pending for PCIe support even in the mainline kernel, the question arises whether all of this has already been migrated into the firmware. -
-
1 hour ago, eselarm said:
What happens after that?
IMHO, OP wants to boot OS from NVME while the firmware is stored in the SPI flash, but he is using firmware in which the necessary support is not enabled.
-
3 hours ago, Sharkam said:
Which gstreamer based browser
I usually use Falkon in a Plasma environment with Wayland backend.
-
22 hours ago, Sharkam said:
can we achieve in browser video hardware acceleration now, and how?
I haven't looked at this use case for a very long time. I can no longer remember since when it has worked out-of-the-box for me. Since decoder support has been part of the GStreamer framework for a very long time, hardware-supported video decoding works for all browsers that use this framework with the standard packages of the distribution of my choice.
When v4lrequest support was still implemented with the out-of-tree patches using the stateful method, it also worked with Firefox out-of-the-box. Just an accordingly patched FFmpeg framework was required. This is likely no longer going to work with the current patches for the FFmpeg framework and requires an additional implementation in Firefox. I suspect, however, that this will only happen after the official inclusion of v4lrequest support in the FFmpeg framework, as is also the case with MPV. To what extent patches for Firefox are already available is unknown to me. For the distribution of my choice, I have in any case rebuilt the FFmpeg and MPV packages with the corresponding patches.
I have to confess that I usually use Firefox and the video decoding works flawlessly for my use cases. However, I cannot say whether this is actually hardware-accelerated, because the SBCs I use with a graphical Desktop are powerful enough to function sufficiently even with only software decoding.
I'm just taking the lazy way here and waiting for it to end up in Manline. For SBCs that need hardware acceleration, I simply use a browser that uses the GStreamer framework. -
4 hours ago, Werner said:
Everyhing else necessary (like libraries) is out of scope for Armbian.
From an OS's point of view, only a Mesa build with Teflon and Rocket driver support is needed (available since Mesa 25.3).
Inferences can then be executed with ai-edge-litert. I have been experimenting with this for some time on all my devices equipped with Rockchip RK3588/RK3588s. -
-
10 hours ago, mircsicz said:
So now I need to ask @usual user what specific kernel are you running?
I am currently at 7.0.0-rc1. I can upload my jump-start image so you can check if my kernel build works with your device. If you like what you see, it is only a 'prepare-jump-start ${target-mount-point}' away to install the kernel package alongside your existing system.
1 hour ago, flappyjet said:I found an interesting project https://github.com/NotPunchnox/rkllama
I know about it, but since it is just another not mainline solution with another dependency mess, I am not particularly interested.
-
On 3/2/2026 at 2:22 AM, flappyjet said:
Would you be generous to post your NPU device info?
Since the hardware support for Rockchip SoCs in the mainline kernelis generally already very outstanding and their further development is also being actively pursued, I only have SBCs with integrated NPUs that are based on them. Among them are ODROID-M2, NanoPC-T6, and ROCK-5-ITX. But since the NPU is an integral part of the SoC, the board manufacturer and the design of the SBC are not necessarily of importance.
On 3/2/2026 at 2:22 AM, flappyjet said:I'm also looking for some w8a8 llm models working on NPU (the GEMM capability is perfect, isn't it).
As far as I understand, edge-class NPUs are best suited for computer vision tasks.
I am therefore engaged in object detection:
and super-resolution:
-
8 hours ago, flappyjet said:
Do you have rocket kernel with mesa that enable NPU working now?
This is what my software stack looks like:
My kernel is build as a generic one, hence my OS is working on any device equipped with a VeriSilicon VIPNano, a Rockchip RK3588 or an Arm Ethos-U65/U85 NPU.
The application can be written NPU-agnostic, as long as a model.tflite file suitable for the NPU is used. -
8 hours ago, BoringName said:
drm has been changed to v4l2request.
The patches that were available out-of-tree for a long time were a kind of hack using the DRM subsystem for decoding. For inclusion in mainline, they were further developed into a more correct request method.
8 hours ago, BoringName said:I'm going to assume you have hwdec=v4l2request in your mpv.conf file.
It is hwdec=v4l2request-copy in fact, because the stateless decoder is an m2m device and the scan-out is still carried out via the DRM subsystem. However, the copy is cheap because it is executed via dmabuf as zero copy.
-
6 hours ago, BoringName said:
Run mpv --hwdec=help
If drm is not listed as one of the options it will not work. You need to find a build with drm support.
mpv_--hwdec=help.logis what I get, and everything works as expected, but I am on current mainline releases with in-flight patches for mpv and ffmpeg on top. Gstreamer framework based applications work out-of-the-box.
The log entries that contain the 'request' component are the ones that matter.
But you're right, it can still take a while before current mainline releases are declared stable by some distributions and adopted. But this is not the fault of mainline development, which continues to progress and does not take outdated versions into account any longer. -
Lately, I've been playing around a bit with computer vision detection. I managed to patch together a PoC script with which I conducted some tests. The results are quite promising. The frame rate is just based on the round trip time of my test script, so it only roughly reflects the inference time. The throughput includes all additional overhead but is sufficiently informative for a relative comparison.
Inference on a single CPU core delivers an image throughput of about 4 images:
Inference on a single NPU core delivers an image throughput of about 17 images:
Inference on eight CPU cores delivers an image throughput of about 21 images. But all eight cores run over 80% during this, and after a short time the fan kicks in. The headroom is also quite limited, for e.g., to perform other tasks concurrently. Running several similar inference tasks concurrently immediately results in a proportional drop in frame rate per task.
When six similar inference tasks are executed simultaneously with NPU delegates, they are distributed across the three available NPU cores, and the SoC utilization is moderate enough that the fan doesn't even turn on. The throughput does not degrade and the CPU cores remain available for other tasks as well:
For my tests, I used a random video clip. For the inference, I used a model pre-trained with the COCO dataset. With its 4.1MB memory size and its 80 object classes, it delivers surprisingly good results. Using the NPU hardware not only reduces the load on the CPU cores but also provides additional acceleration of processing. But the best part is that only current mainline code is required for use. No dependencies on proprietary implementations or outdated software stacks. It just works out-of-the-box, you just need to know how to use it.
-
SPI NOR Flash on Odroid HC4
in Odroid C4
Posted
Your previous post reminded me that the board supplier changed the BOM of the ODROID-N2+ by using a different SPI flash vendor. He hacked the support for it into his legacy firmware build without making any further note about it. It took some effort of reverse engineering to figure that out. Mainline hasn't picked up this additional driver activation to this day, but I still keep it in my builds anyway.
In my latest build for the ODROID-HC4, I also included this driver to see if they might have gone about it in the same way. But your confirmation shows that this is probably not the case.
Since I don't have an ODROId-HC4 with the behavior you described on hand, I can't analyze any further what the cause of it is. These days, I also mostly avoid devices with Amlogic SoCs because of their strict closed-source policy and lack of mainline support. And the board manufacturer isn't much more helpful on this point either. Devices powered by Rockchip are much more appealing objects. So you have to help yourself if you want to find a solution.