going

Cross-posting this because it took a while to untangle, and most guides out there are either
vendor-BSP/rkmpp (the wrong stack for mainline) or they stop at "it says hardware accelerated"
without checking whether it actually is.

Tested on an Orange Pi 5B, mainline Debian 13 (trixie),
kernel 7.1.3+deb13-arm64, panthor + PanVK, Wayfire. Should apply to any RK3588/RK3588S board on a
mainline stateless-decode kernel (Rock 5B, OPi 5, etc.). Corrections welcome; I'd rather this be
right than mine.
First, the thing that trips everyone up: on mainline, rkmpp is not your path.
Rockchip's MPP library (the thing that hardware-decodes at ~9% CPU on the vendor BSP images) talks
to /dev/mpp_service. That device only exists on the vendor kernel. On mainline/panthor there is no
mpp_service and there never will be, so every rkmpp-based ffmpeg/Chromium build is a dead end here.
And no, the GPU doesn't help. PanVK exposes zero VK_KHR_video_decode extensions. Mali-G610 has no
video engine. Vulkan composites and scales the decoded frames; it never produces them. The decode
blocks are separate silicon (rkvdec, Hantro) behind a separate kernel API.
The mainline path is V4L2 stateless (the request API), the work Collabora and Jernej Skrabec carry
upstream, with the userspace ffmpeg side maintained by Kwiboo (Jonas Karlman). The kernel drivers
are already there; on my box the v4l2_h264/v4l2_vp9 helpers are loaded and bound to rkvdec/hantro_vpu
out of the box. What's missing is a userspace that speaks the request API. Stock Debian ffmpeg
doesn't, so it silently decodes in software (1080p H.264 is about 600% CPU, six cores pegged).
Check what your kernel actually exposes before anything else:
  for v in /dev/video*; do echo "== $v =="; v4l2-ctl -d $v --list-formats-out 2>/dev/null | grep -oE "'[A-Z0-9]{4}'"; done
On my 7.1.3 kernel:
  /dev/video1 (rkvdec)              -> S264 S265         (H.264, HEVC)
  /dev/video2 (rk3568-vpu)         -> S264 VP8F MG2S    (H.264, VP8, MPEG-2)
  /dev/video4 (rk3588-av1-vpu-dec) -> AV1F              (AV1, advertises up to 4096x2304)
  VP9 is NOT exposed on this kernel; that is a beryllium/7.2-rc5+ restore (VP9-on-VDPU381).
  More on why that barely matters below.

Part A: system-wide HW decode (mpv, VLC, GStreamer, everything)
Build Kwiboo's FFmpeg fork, branch v4l2-request-n7.1.3. The version choice is deliberate: ffmpeg
7.1.3 is libavcodec.so.61, the same soname as Debian trixie's 7.1.5, so it is a genuine drop-in.
You swap one component and every libav app hardware-decodes with zero rebuilds. (The newer n8.x
branches are .so.62 and become an island: only the one binary you point at them benefits.)
  sudo apt install build-essential git nasm pkg-config libdrm-dev libudev-dev v4l-utils \
    libx264-dev libx265-dev libvpx-dev libopus-dev libvorbis-dev libmp3lame-dev libdav1d-dev libva-dev
  git clone -b v4l2-request-n7.1.3 https://github.com/Kwiboo/FFmpeg ffmpeg-7131 && cd ffmpeg-7131
  ./configure --prefix=/usr/local --enable-shared --disable-static \
    --enable-gpl --enable-version3 --enable-v4l2-request --enable-libdrm \
    --enable-libx264 --enable-libx265 --enable-libvpx --enable-libopus \
    --enable-libvorbis --enable-libmp3lame --enable-libdav1d --disable-vulkan --disable-doc
  make -j$(nproc)
Build gotcha that cost me an hour: do NOT add --enable-libv4l2. On n7.1.3 its libavdevice/v4l2.c
fails to compile against current libv4l headers (the SET_WRAPPERS macro). That is the webcam-capture
indev, nothing to do with request-API decode. Leave it off.
Test before installing anything system-wide, with stock mpv pointed at the fresh libs:
  LD_LIBRARY_PATH=/usr/local/lib mpv --hwdec=v4l2request-copy --gpu-api=vulkan yourfile.mp4
You want to see "Using hardware decoding (v4l2request-copy)" and pixfmt drm_prime. My numbers:
1080p H.264 went from about 600% CPU (software) to about 37% of one core.
Then package it as a .deb that Provides/Conflicts/Replaces the eight Debian libav* packages
(= 7:7.1.5-0+deb13u1) and installs your .so.61 plus symlinks into /usr/lib/aarch64-linux-gnu/. apt
treats it as satisfying the deps, so mpv/vlc/gstreamer/qt-multimedia all stay installed and all
start hardware-decoding. Cache the stock debs first (apt download the eight) so rollback is one
command.
Honest tradeoff: this replaces your system libav with a fork, so (a) the blast radius is every
media app, and (b) you now own libav security. When Debian bumps 7.1.x for a CVE, you rebuild the
one deb. I think that is a fair price for one-component maintenance versus forking every app.
Your call.

Part B: in-browser HW decode (Chromium), and a myth to kill
You do not need a forked Chromium, and you do not need the libva-v4l2-request VA-API shim for the
browser. Both are things the vendor/rkmpp world needs; mainline does not.
Two facts do the work:
  1. Debian trixie already ships Chromium 151, past the upstream 150 ANGLE roll that fixed the old
     VP9 green-artifact bug. Stock: apt install chromium.
  2. Chromium bundles its own ffmpeg, and its AcceleratedVideoDecoder talks V4L2-stateless straight
     to /dev/videoN. So Part A's libav swap is irrelevant to the browser; the two paths are
     independent.
Debian's chromium launcher sources /etc/chromium.d/*, so drop a flag file:
  # /etc/chromium.d/50-hwdecode
  export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --ozone-platform-hint=auto \
    --enable-features=AcceleratedVideoDecoder,AcceleratedVideoDecodeLinuxGL,AcceleratedVideoDecodeLinuxZeroCopyGL \
    --ignore-gpu-blocklist --enable-gpu-rasterization --enable-zero-copy"
Notes:
  - The flag that actually gates it is AcceleratedVideoDecoder. The older
    AcceleratedVideoDecodeLinuxV4L2 no longer exists in 150+ and is silently ignored.
  - It needs a Wayland session. --ozone-platform-hint=auto picks it under Wayfire/wlroots.
Result: browser H.264 held /dev/video1 at about 23% of one core. AV1 held /dev/video4. Which brings
us to the part that actually stumped me.

Part 😄 the 4K@30 gotcha. cma=256M is too small, and it fails silently.
This is the reason I wrote the post. In-browser AV1 worked perfectly at 1080p: decoder node held,
about 26% of one core, 95% idle. Force the same av01 stream to 2160p and it dropped straight back to
software: one Chromium process at about 400%, /dev/video4 idle, and stats-for-nerds still reading
av01. Same codec, two outcomes.
The tell that it is not the codec: the AV1 block advertises up to 4096x2304, so 4K is in spec. It is
not a capability ceiling. The kernel log named it exactly:
  cma: __cma_alloc_frozen: alloc failed, req-size: 3421 pages, ret: -16
    hantro_postproc_alloc -> dma_alloc_attrs -> hantro_start_streaming
The Hantro decoder needs a roughly 13 MB contiguous buffer for a 4K frame, and the default cma=256M
pool was too fragmented to hand it out. hantro_start_streaming bails, and Chromium does what it is
designed to do: falls back to software, silently, with no error on screen. At 1080p the buffer is a
quarter the size and fits; at 4K it does not.
Fix (a boot argument, not a kernel rebuild): bump the CMA reservation. On the mainline extlinux
setup that is:
  # /boot/extlinux/extlinux.conf  -> in the "append ..." line(s), and
  # /etc/default/u-boot           -> U_BOOT_PARAMETERS (the template extlinux regenerates from)
  cma=256M   becomes   cma=1G
Edit both, or a future u-boot-update reverts you. Reboot. (The other fix you will see mentioned is
CONFIG_VSI_IOMMU=y, which lets the AV1 VPU scatter-gather through the IOMMU and sidestep the
contiguous requirement, but that is a kernel rebuild. The boot arg is free.)
After cma=1G (CmaTotal 1 GB): the same 4K av01 fullscreen stream went from four pegged cores to
58% of one core, 91% idle, decoder node held, zero allocation failures, and it ran cooler (47C to
36C). 256 MB is simply too small a house for 4K decode on this SoC. Ship 512M or more; I use 1G.
Codec support, honestly (this kernel): H.264 yes, HEVC yes, AV1 yes (including 4K with the CMA
bump), VP8/MPEG-2 yes, VP9 is software (not in 7.1.3; needs beryllium/7.2+). In practice the VP9
gap barely bites: because Chromium now advertises AV1 decode, YouTube negotiates av01 at every
resolution I tested (1080p and 4K), and only reaches for VP9 in ads. So I am leaving VP9 to upstream
rather than chasing a custom kernel.
How to actually verify HW decode (do not trust chrome://gpu): it reports a capability ("Video
Decode: Hardware accelerated") that stays true even while a given stream decodes in software. The
only honest test is who holds the decode node, sampled during steady playback (not during an ad or
a quality ramp; those transients will lie to a CPU snapshot):
  fuser /dev/video1 /dev/video2 /dev/video4     # whoever holds it is the real decoder
Cross-check in the browser at chrome://media-internals: kVideoDecoderName is V4L2VideoDecoder, and
kIsPlatformVideoDecoder is true.

The build this ran on (for reproducibility)
Nothing exotic; the point is it is stock trixie + backports, not a vendor BSP. This is a mainline
Debian desktop I put together for the 5B (my own image line, "Pi Phreak"):
  - Board:      Xunlong Orange Pi 5B, RK3588S (4x Cortex-A76 + 4x Cortex-A55), Mali-G610 MC4, 16 GB
  - OS:         Debian 13 (trixie), with trixie-backports enabled
  - Kernel:     7.1.3+deb13-arm64, mainline (stateless V4L2 decoders, panthor), booted with cma=1G
  - GPU stack:  Mesa 26.1.2 (~bpo13), Vulkan 1.4 via PanVK on Mali-G610 (loader 1.4.309), GLES 3.1
  - Compositor: Wayfire 0.11.0 on wlroots 0.20.2 (built from source; trixie ships 0.9), plus
                swaybg / waybar / wofi / foot
  - Media:      Chromium 151 (stock Debian) + the /etc/chromium.d flags, mpv 0.40, system libav =
                the Kwiboo v4l2-request 7.1.3 drop-in (7:7.1.3-phreak1, soname-matched to 7.1.5)
Two things to flag for anyone reproducing this: Mesa/PanVK come from trixie-backports (stock trixie
Mesa is older and PanVK is not 1.4 there, a separate "package version is not hardware capability"
trap), and the 16 GB headroom is what makes a 1 GB CMA reservation painless. On an 8 GB board I would
still bump past 256M (try 512M) but keep an eye on free RAM.
Credits: Kwiboo (Jonas Karlman) for the FFmpeg v4l2-request fork; Collabora / Jernej Skrabec for the
mainline stateless decoders; the dongioia/rock5bplus-rkvdec2 writeup for the Chromium-150 flag
findings; beryllium-org for the packaging reference and the VP9/VDPU381 kernel note. I only assembled
and measured; the hard part is theirs.
Happy to answer questions or hand over the packaging scripts if it is useful.
 
Peace,
Defcom5-Rockchip

"Got 2 Claudes and A Turntable"
 
Sorry I got my Flagship baking and excited working on my new Debian build with the above outlined and the honey its f in due list!
2 things I've learned about AI. 
1. Don't Trust Them, you have to tell them like they are children. (They act like they know).
2. Don't Trust Them.

@emor acid You could use the armbian build system to create patches https://docs.armbian.com/Developer-Guide_Build-Commands/#rewrite-uboot-patches. I like to use the git commands and make my own patches.
 
git clone https://github.com/NickAlilovic/build.git --branch v20250306
cd build
./compile.sh
choose "Do not change kernel configuration"
choose "Show CSC/WIP/EOS/TVB"
choose "I understand and agree"
choose "x98h"
choose "edge"
rest is up to you.
 

 
Stop the build after the kernel patches are applied in the middle of the kernel build. Use "ctrl c" keys.
ctrl c
 
Patch your u-boot dts.
cd cache/sources/u-boot-worktree/u-boot/v2025.01
sudo pico dts/upstream/src/arm64/allwinner/sun50i-h618-x98h.dts
 
Delete this.
ethernet0 = &emac1; &emac1 { pinctrl-names = "default"; pinctrl-0 = <&rmii_pins>; phy-mode = "rmii"; phy-handle = <&rmii_phy>; phy-supply = <&reg_aldo1>; allwinner,rx-delay-ps = <3100>; allwinner,tx-delay-ps = <700>; status = "okay"; }; &mdio1 { rmii_phy: ethernet-phy@16 { compatible = "ethernet-phy-ieee802.3-c22"; reg = <16>; }; };  
Add this
ethernet0 = &emac0; ethernet1 = &emac1; &emac0 { compatible = "allwinner,sun50i-h616-emac"; pinctrl-names = "default"; pinctrl-0 = <&ext_rgmii_pins>; phy-mode = "rgmii"; phy-handle = <&ext_rgmii_phy>; phy-supply = <&reg_gmac_3v3>; phy-io-supply = <&reg_dldo1>; allwinner,rx-delay-ps = <3100>; allwinner,tx-delay-ps = <700>; status = "okay"; }; &mdio0 { ext_rgmii_phy: ethernet-phy@1 { /* rtl8211F compatible string for mdio and phy */ compatible = "ethernet-phy-id001c.c916"; reg = <1>; reset-assert-us = <20000>; reset-deassert-us = <100000>; reset-gpios = <&pio 8 16 GPIO_ACTIVE_LOW>; /* PI16 */ }; }; &emac1 { compatible = "allwinner,sunxi-gmac"; status = "disabled"; }; &mdio1 { rmii_phy: ethernet-phy@1 { compatible = "ethernet-phy-ieee802.3-c22"; reg = <1>; }; }; sudo git add dts/upstream/src/arm64/allwinner/sun50i-h618-x98h.dts
sudo git commit
 
This opens up an editor. First line is your Title. The rest is your description. Remember to save when you are done.
 
Title
Description
 
sudo git format-patch -1
 
Your new patch.
0001-Title.patch
 
Rename 0001-Title.patch to 172-Title.patch
Copy your patch into the build/patch/u-boot/u-boot-h616 directory.
 
 
 
Patch your kernel dts.
cd cache/sources/linux-kernel-worktree/6.12__sunxi64__arm64
sudo pico arch/arm64/boot/dts/allwinner/sun50i-h618-x98h.dts
Same changes as above. sudo git add arch/arm64/boot/dts/allwinner/sun50i-h618-x98h.dts
sudo git commit
 
Title
Description
 
sudo git format-patch -1
 
Rename 0001-Title.patch to 2002-Title.patch.
Copy your patch into the build/patch/kernel/archive/warpme-6.12 directory.
 

I apologize. I have not read what you wrote earlier.
Please write whatever you see fit your work can be very useful. Success to you in your endeavor.

Recommended to upgrade U-Boot to version v2025.07
This version has big changes for allwinner (sunxi) chips. This concerns the initialization of a non-standard size of RAM (1.5; 2.5 GB), downloads from eMMC.....

Self compiled Armbian Bookworm + XFCE with Linux Edge 6.15.x
 
Then follow all the instructions in https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/#findComment-176981
 
 
Then add extraargs=cma=256M to armbianEnv.txt

This will be fixed soon.

I'm a beginner and I'm really afraid that my work won't be wasted and I won't have to set everything up from scratch again. I installed on the BPI-M5 Armbian_25.2.1_Bananapim5_noble_current_6.12.13_ubuntu-server. But I need the server to simply log in when it reboots and start working without my participation. Please tell me if it would be correct to set up autologin as described below???
 
Step-by-step manual configuration of autologin, user "pi"
 
Step 1: Verify that the pi user exists
If you haven't created a pi user yet, do it.:
sudo adduser pi
 
If there is already a user, proceed to the next step.
 
Step 2: Create an override for the getty@tty1 service
Do it:
sudo systemctl edit getty@tty1.service
 
This command opens the editor (nano or vim by default) and creates an override.conf file.
 
Step 3: Paste the following contents into the opened file:
 
[Service]
ExecStart=
ExecStart=-/sbin/agetty --autologin pi --noclear %I $TERM
 
📌 Explanation:
ExecStart= — an empty line resets the standard getty launch.
The second line is a new startup command with an autologin for pi.
 
Step 4: Save the file and log out
In the nano editor:
Press Ctrl+O, then Enter to save.
Press Ctrl+X to exit.
 
Step 5: Restart systemd services
 
sudo systemctl daemon-reexec
sudo systemctl daemon-reload
 
Step 6: Make sure the service is enabled
 
sudo systemctl enable getty@tty1.service
 
Step 7: Reboot the system
 
sudo reboot
✅ Result
After restarting, Armbian will automatically log into the console (tty1) under the user pi, without asking for a password.

This is going to be a rough tutorial on how to get PWM working on a OrangePi Zero 3 running armbian. Just got this working thanks to (https://forum.armbian.com/profile/9748-going/). I am no expert when it comes to PWM and kernel overlays but this should get you something that works. Enjoy!


Install all 4 of the deb's from this link (https://github.com/The-going/PKG_test/tree/master/sunxi64-6.13) after rebooting you should be on 6.13.11. You can check with "uname -r"

Edit the file at /boot/armbianEnv.txt and add "pwm1-ph3", "pwm1-pi11", "pwm4-ph1" or "pwm4-pi14" depending on which pwm pin you want to use. Use the included pinout.png for reference.

After enabling the overlay I used the gpio command which should be preinstalled on armbian, if not this wiki page tells you how to install. (http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_Zero_3#How_to_install_wiringOP)
 
"gpio readall" this will print out an ascii diagram of the physical pins on the board as shown in ascii.png. In this case I am using physical pin 10, which corresponds to wPi pin 4 which is what we need for the next commands. (The pin names/number here are going to be different than the ones used previously, it is best to just use the ascii diagram and find what pin you are using instead of basing off of previous pin names)

"gpio mode 4 pwm" replace 4 with whatever wPi pin you are using, do this for all following commands. This will set the pin mode in the software to pwm

The following information I just learned from doing some googling so it may NOT be 100% correct but it was enough to get it working in my case.

"gpio pwmc 4 25" this sets the clock frequency of the PWM pin. The clock frequency is equal to 19200000 divided by the last number specified in the command. So in this case the clock frequency is 768000=19200000/25.

"gpio pwmr 4 50" this sets the pwm range and output frequency. range is essentially the resolution of pwm adjustment, higher range means finer control. your final pwm frequency is equal to 19200000/clockvalue/rangevalue. So in this case my pwm frequency is 15360=19200000/25/50.

"gpio pwm 4 25" this sets your pwm duty cycle, this is the value you will most likely be changing to control whatever device you have connected to your pwm pin. this number cant be more than your set pwm range, so in this case i have 51 steps because I have any number from and including 0 to 50 to work with.

Again I am far from an expert in PWM so I cant guarantee this is all correct but at the very least this shows how to set the needed values with the gpio commands and get PWM working on this board.

@jock Thank you for the opportunity.

I don't think this will increase verbosity even higher. 7 is max
https://www.kernel.org/doc/html/v6.12/admin-guide/kernel-parameters.html
 
 
Edit: Actually 8 is max. I think I've misread the manual. 

The patches posted above and @jock ffmpeg-v4l2request. H264 hardware decoding now works. I'm using debian bookwarm, X11, xfce. Just follow jocks install instructions in the link below.
 
Getting errors with 1080p mp4 video's. I fixed this before by changing the cma to a higher value (cma=512M) in the boot.cmd file. 
 
720p works ok.
 

patch/kernel/archive/sunxi-6.1 It will be deleted tomorrow.
patch/kernel/archive/sunxi-6.6 This is frozen on version v6.6.75 as stable.
It will be moved to LEGACY tomorrow and will no longer be supported.

Hi All,
 
Good to hear that the cedrus driver appears to be initialized correctly. It has been a while since I last tried hardware accelerated playback and unfortunately did not have much success. From what I remember from another topic is that in order to utilize the cedrus, ffmpeg has to be compiled with v4l2m2m (--enable-v4l2-m2m) support in place. From what I can tell this is not set in the system packaged version of ffmpeg.
 
Hope this helps
 
Ryzer

Yes that works fine.
 
I have to edit this post as the video only works "fine" on a small window with a lower bit rate avi file (H264). Other videos I tested stuttered and got worse as the window size was increased. Most videos would not play in full screen mode (1920x1080), filling only 1/4 of the screen.
I watched the system monitor while playing a video and cpu usage was very high 80-100% on all cores.
 
Ok so I did some more investigation. The first quick test I did was with Celluloid and Media Player, the programs that come with Mate.  I then installed vlc, because I wanted to see the codec info about the media. It is vlc that is a cpu hog!  Both Celluloid and Media Player work well even at full screen.  The cpu usage is around 50%.

[ 9.527925] videodev: Linux video capture interface: v2.00 [ 9.539551] panfrost 1800000.gpu: clock rate = 432000000 [ 9.539593] panfrost 1800000.gpu: bus_clock rate = 200000000 [ 9.540215] panfrost 1800000.gpu: mali-g31 id 0x7093 major 0x0 minor 0x0 status 0x0 [ 9.540250] panfrost 1800000.gpu: features: 00000000,000027f7, issues: 00000000,00000400 [ 9.540262] panfrost 1800000.gpu: Features: L2:0x07100206 Shader:0x00000000 Tiler:0x00000209 Mem:0x1 MMU:0x00002821 AS:0xff JS:0x7 [ 9.540274] panfrost 1800000.gpu: shader_present=0x1 l2_present=0x1 [ 9.544584] [drm] Initialized panfrost 1.2.0 for 1800000.gpu on minor 1 Thank you for the information provided!
A simple clarification. Does it work on an h616 processor with the patch disabled?
 
For the h618 processor, I was unable to get the GPU to work with or without this patch.
It remains to be seen whether this patch plays a positive role for the h6 processor.
If there is no positive effect, then I'd better turn it off.

thank you very much guys, both two method is works. i successfully patched.

To do this, you will need to open two sessions in the terminal.
The test here is my configuration file
1 session ~/armbian$ ./compile.sh test kernel-patch ...... # build system printed: [✨] Starting [ interactive patching process for kernel ] [🌱] Creating commit to start from clean source [🌱] Patches will be created [ with the following maintainer information ] [🌱] MAINTAINER (Real name): [ The-going ] [🌱] MAINTAINERMAIL (Email): [ 48602507+The-going@users.noreply.github.com ] [🌿] If those are not correct, set them in your environment, command line, or config file and restart the process [🚸] Make your changes in this directory: [ /home/leo/armbian/cache/sources/linux-kernel-worktree/6.13__sunxi64__arm64 ] [🚸] Press <ENTER> after you are done [ editing files in /home/leo/armbian/cache/sources/linux-kernel-worktree/6.13__sunxi64__arm64 ] Press ENTER to show a preview of your patch, or type 'stop' to stop patching... The build system will apply all the patches and make a commit that will include all the changes.
Leave this session alone.
In the second session, you make your changes and record the results.
2 session leo@armbuild:~/armbian$ cd /home/leo/armbian/cache/sources/linux-kernel-worktree/6.13__sunxi64__arm64 ### open root session leo@armbuild:~/armbian/cache/sources/linux-kernel-worktree/6.13__sunxi64__arm64$ sudo su root@armbuild:/home/leo/armbian/cache/sources/linux-kernel-worktree/6.13__sunxi64__arm64# ls arch/arm64/boot/dts/rockchip/rk3399-* linux-kernel-worktree/6.13__sunxi64__arm64# nano arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts linux-kernel-worktree/6.13__sunxi64__arm64# git add --all linux-kernel-worktree/6.13__sunxi64__arm64# git commit -m "Add a comment" ###close root session: linux-kernel-worktree/6.13__sunxi64__arm64# exit linux-kernel-worktree/6.13__sunxi64__arm64$ git format-patch -1 -o /home/leo/armbian/userpatches/ /home/leo/armbian/userpatches/0001-Add-a-comment.patch linux-kernel-worktree/6.13__sunxi64__arm64$ cat /home/leo/armbian/userpatches/0001-Add-a-comment.patch From 4dad6a3fa967235ea7eef35f81733bdafd806b53 Mon Sep 17 00:00:00 2001 From: The-going <48602507+The-going@users.noreply.github.com> Date: Tue, 18 Mar 2025 12:54:11 +0000 Subject: [PATCH] Add a comment --- arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts b/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts index 2ddd4da15..29eec7e65 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts +++ b/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts @@ -78,6 +78,7 @@ keys: gpio-keys { compatible = "gpio-keys"; autorepeat; + /* key-power */ key-power { debounce-interval = <100>; gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>; -- 2.34.1 What should I do with the first session?
Decide for yourself!!

# Europe/Moscow - 2000 Mbit/s - server: stpete-mirror.armbian.com/beta/ rules: - field: location.country.iso_code not_in: - UA latitude: 59.9417 longitude: 30.3096 weight: 10  
# Europe/Kiev - 1000 Mbit/s - server: fastmirror.pp.ua/armbian/ rules: - field: location.country.iso_code not_in: - RU latitude: 50.458 longitude: 30.5303 weight: 10  
After this change, our redirector blocks access to Russian mirrors for users in Ukraine and vice versa. Hopefully, this feature will become obsolete soon.

leo@bananapim64:~$ sudo nano /etc/apt/sources.list.d/armbian.list http://apt.armbian.com =>> https://stpete-mirror.armbian.com/apt leo@bananapim64:~$ cat /etc/apt/sources.list.d/armbian.list deb [signed-by=/usr/share/keyrings/armbian.gpg] https://stpete-mirror.armbian.com/apt bookworm main bookworm-utils bookworm-desktop leo@bananapim64:~$ sudo apt update Сущ:1 http://deb.debian.org/debian bookworm InRelease Сущ:2 http://security.debian.org bookworm-security InRelease Сущ:3 http://deb.debian.org/debian bookworm-updates InRelease Сущ:4 http://deb.debian.org/debian bookworm-backports InRelease Сущ:5 https://github.armbian.com/configng stable InRelease Пол:6 https://stpete-mirror.armbian.com/apt bookworm InRelease [53,3 kB] Пол:7 https://stpete-mirror.armbian.com/apt bookworm/main all Packages [17,5 kB] Пол:8 https://stpete-mirror.armbian.com/apt bookworm/bookworm-utils arm64 Packages [37,4 kB] Пол:9 https://stpete-mirror.armbian.com/apt bookworm/bookworm-desktop all Packages [7 526 B] Пол:10 https://stpete-mirror.armbian.com/apt bookworm/main arm64 Packages [1 168 kB] Пол:11 https://stpete-mirror.armbian.com/apt bookworm/bookworm-desktop arm64 Packages [15,9 kB] Пол:12 https://stpete-mirror.armbian.com/apt bookworm/bookworm-utils all Packages [3 965 B] Получено 1 304 kB за 9с (149 kB/s) Чтение списков пакетов… Готово Построение дерева зависимостей… Готово Чтение информации о состоянии… Готово Может быть обновлено 4 пакета. Запустите «apt list --upgradable» для их показа.  

hi @jock
 
I agree that changing the SMD 0201 parts is a real challenge - for this reason I used 0402's soldered them direct to the level shifter and run a tiny wire to the 5V source.
I'm thinking that an SoC side strong pull-up would do the trick eventually and remove R90611/12 entirely. But I haven't test this - but will do that with the next PCB I get on my table.
 
The Level-shifter is a Texas Instruments TX0102DCU with and with OE is high the internal 10K pull ups are enabled.  That might me not enough for the external monitor so the 6.8k has been applied.
Same for the SoC side, 10K only , so I support the internal SDA/SCL lines with the light diving strength of 2ma.
Datasheet:
8.3.5 Pullup or Pulldown Resistors on I/O Lines Each A-port I/O has an internal 10-kΩ pullup resistor to VCCA, and each B-port I/O has an internal 10-kΩ pullup resistor to VCCB. If a smaller value of pullup resistor is required, an external resistor must be added from the I/O to VCCA or VCCB (in parallel with the internal 10-kΩ resistors). Adding lower value pull-up resistors will effect VOL levels, however. The internal pull-ups of the TXS0102 are disabled when the OE pin is low.  
I would say it doesn't hurt to add the changes to the DTS for the i2c7_xfer pinctrl. But without fixing the Pull-up value on the 5V it will not improve anything.
 
Yes it is tiny tiny.

after many tryings I thought of connecting other (more powerful) supply when the one dedicated for C2 didn't work nor any micro USB helped
 
I connected heavy supply to GPIO pins and this time it didn't hang when SD and eMMC were present at the same time
the board booted from SD and this time it was possible to make chroot
 
I don't see any logical explanation for this situation but it worked my old os C2 is alive 😸

Out of curiosity I build an image based on the official repo (default options, just selecting the board, result was Armbian-unofficial_24.11.0-trunk_Orangepipc2_bookworm_edge_6.11.9.img)  and it booted fine, too. I guess the issue is already solved in git?

This will be a fork that will return the code to the parent project https://github.com/armbian/build ?
Or is it planned to be developed as an independent project based on this branch?

PR: https://github.com/armbian/build/pull/7442

I'm fine with this subject edit.