going

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!!

Try to set the disabled status for the GPU node.
or temporarily disable this patch:
patch/kernel/archive/sunxi-6.12/series.conf#L472

# 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.

Thanks for the pointers. Here is my patch (I tested it by dropping it into the right userpatches directory, compiling the kernel and then booting):
 
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 From: Steinar H. Gunderson <steinar+kernel@gunderson.no> Date: Mon, 4 Nov 2024 15:35:38 +0000 Subject: Fix broken allwinner,sram dependency on CB1 On BigTreeTech CB1, the thermal sensor has an allwinner,sram property pointing to <&syscon>. However, Armbian has an out-of-tree kernel patch that creates dependencies based on allwinner,sram properties, which assumes that they point to sram nodes exactly two levels below the syscon node (instead of the syscon itself). This manifests itself as the thermal sensor refusing to load with a nonsensical error message: [ 23.775976] platform 5070400.thermal-sensor: deferred probe pending: platform: wait for supplier Note that it does not say _which_ supplier it is waiting for (the message ends in a space and then no supplier). The patch was unproblematic in the 5.6 megous patch set, where it was introduced, and in 6.6, which is current for Armbian, but in 6.8, the sun8i-thermal driver got mainlined, with this extra property compared to the out-of-tree version we used before (since it wants to clear a special bit at 0x300000 instead of relying on the firmware to do so before kernel boot). Fix by being a bit more flexible when we walk up the tree, so that we always stop at the syscon node. Tested on a Sovol SV08, which is CB1-based. Signed-off-by: Steinar H. Gunderson <steinar+kernel@gunderson.no> --- drivers/of/property.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/of/property.c b/drivers/of/property.c index 6fcfcda9d..f00f2b129 100644 --- a/drivers/of/property.c +++ b/drivers/of/property.c @@ -1368,12 +1368,13 @@ static struct device_node *parse_allwinner_sram(struct device_node *np, if (index > 0) return NULL; sram_node = of_parse_phandle(np, prop_name, 0); - sram_node = of_get_parent(sram_node); - sram_node = of_get_parent(sram_node); + while (sram_node && !of_node_is_type(sram_node, "syscon")) { + sram_node = of_get_parent(sram_node); + } return sram_node; } static const struct supplier_bindings of_supplier_bindings[] = { -- Created with Armbian build tools https://github.com/armbian/build I'm going to mark this as solved; I hope it can go upstream at some point.
 
Note that I think the most sensible thing to do is still just to delete the patch in question, not to patch it further. But I don't understand 100% why it was added in the first place; maybe there is some reason that is still valid for some platform.

I removed the patch, and the resulting kernel booted and found its thermal zones. So I think the basic issue is that the patch just is doing of_get_parent() twice without checking that this makes sense.
sesse@amalie:~$ uname -a Linux amalie 6.11.2-edge-sunxi64 #2 SMP Fri Oct  4 14:38:57 UTC 2024 aarch64 GNU/Linux sesse@amalie:~$ ls -l /sys/class/thermal/ total 0 lrwxrwxrwx 1 root root 0 Nov  3 20:28 cooling_device0 -> ../../devices/virtual/thermal/cooling_device0 lrwxrwxrwx 1 root root 0 Nov  3 20:25 thermal_zone0 -> ../../devices/virtual/thermal/thermal_zone0 lrwxrwxrwx 1 root root 0 Nov  3 20:25 thermal_zone1 -> ../../devices/virtual/thermal/thermal_zone1 lrwxrwxrwx 1 root root 0 Nov  3 20:25 thermal_zone2 -> ../../devices/virtual/thermal/thermal_zone2 lrwxrwxrwx 1 root root 0 Nov  3 20:25 thermal_zone3 -> ../../devices/virtual/thermal/thermal_zone3  

Thank you very much.
I collect in a notebook all possible bugs when using this utility.
I want to redo it.

@going https://github.com/orangepi-xunlong/u-boot-orangepi/tree/v2017.09-rk3588

the original system that started the thread, after (failed) armbian-install run, looks like this with the USB stick used to boot the system:
 
acas@uefi-arm64:~$ df Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 1605708 12816 1592892 1% /run /dev/sda2 59094688 5773640 52631248 10% / tmpfs 8028524 0 8028524 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock efivarfs 64 42 23 65% /sys/firmware/efi/efivars tmpfs 8028524 0 8028524 0% /tmp /dev/sda1 258094 150 257945 1% /boot/efi /dev/zram1 47960 2152 42224 5% /var/log tmpfs 1605704 60 1605644 1% /run/user/1000 acas@uefi-arm64:~$ fdisk -l Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors Disk model: Fanxiang S501Q 1TB Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: A3C2AE18-4086-48D2-B1F9-90B315BAB1FA Device Start End Sectors Size Type /dev/nvme0n1p1 2048 2000408575 2000406528 953.9G Linux filesystem Disk /dev/sda: 57.62 GiB, 61865984000 bytes, 120832000 sectors Disk model: USB Flash Drive Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 611F458A-F35E-B04A-9F22-8E04707F1E17 Device Start End Sectors Size Type /dev/sda1 8192 532479 524288 256M EFI System /dev/sda2 532480 120831966 120299487 57.4G Linux root (ARM-64) Disk /dev/zram0: 7.66 GiB, 8221212672 bytes, 2007132 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/zram1: 50 MiB, 52428800 bytes, 12800 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes  
note how there is no EFI partition on the NVME drive. But the image from the armbian build framework has an EFI system partition and is what i'm using to boot the system right now via the USB stick.

the box i was referring to has the following -
acas@opi2:~/build$ fdisk -l Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors Disk model: Fanxiang S500Pro 1TB Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x4f11c8df Device Boot Start End Sectors Size Id Type /dev/nvme0n1p1 2048 411647 409600 200M ef EFI (FAT-12/16/32) /dev/nvme0n1p2 411648 2000409263 1999997616 953.7G 83 Linux Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: ASM1153USB3.0TOS Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 33553920 bytes Disklabel type: dos Disk identifier: 0x2eeae39f Device Boot Start End Sectors Size Id Type /dev/sda1 2048 8390655 8388608 4G b W95 FAT32 /dev/sda2 8390656 50333695 41943040 20G 83 Linux /dev/sda3 50333696 3907029167 3856695472 1.8T 83 Linux Disk /dev/zram0: 3.74 GiB, 4014276608 bytes, 980048 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/zram1: 50 MiB, 52428800 bytes, 12800 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes  
ah... i have a USB connected sata adapter ssd as /dev/sda - forgot about that. Maybe that is accidentally providing boot (used to be connected to an rpi4)

@Nick A I understand you.
Working with the source code and making patches within the framework of the build system is a sad business.
 
Let's try to sort it out.
I'm writing this for everyone. Don't read it if it's familiar to you.
First, basic knowledge about git:
A git is a chain of related git objects.
The git object is the compressed difference between the current state and the previous one.
The Git object has a name in the form of a 40-digit hexadecimal numeric word.
Each object is tightly linked to the previous (parent) and subsequent (child) objects.
Concepts such as HEAD, tag, branch are references to a specific git object.
The working tree is the git state extracted to the working directory.
 
In previous posts, we talked about u-boot. Let's check what we have in the build system.
My build system is located in the VM in the folder: /home/leo/armbian
 
leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ git branch + master * u-boot-edge-bananapim3 leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ git log --pretty=oneline -3 866ca972d6c3cabeaf6dbac431e8e08bb30b3c8e (HEAD -> u-boot-edge-bananapim3, tag: v2024.01) Prepare v2024.01 82750ce44226e5f2b3bbcd79cf7b3ba3dfd3de4d arm: dts: iot2050: Fix by syncing from Linux dbb124cf6888da9581834a3c17b02f958a8afacf configs: j7200: Remove HBMC_AM654 config  
Enter your data from the github here.
It is important.
git config --global user.email "you@example.com" git config --global user.name "Your Name"  
Let's add all the changed files to the monitored state and make a commit:
leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ sudo git add --all leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ sudo git commit -m "The Armbian changes" [u-boot-edge-bananapim3 dcf395c104] The Armbian changes 52 files changed, 682 insertions(+), 16 deletions(-) create mode 100644 arch/arm/dts/sun50i-a64-recore.dts create mode 100644 arch/arm/dts/sun50i-h313-x96q-lpddr3.dts create mode 100644 configs/recore_defconfig create mode 100644 configs/x96q_lpddr3_defconfig  
Now we will see:
leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ git log --pretty=oneline -3 dcf395c1044533320913373b3b8da980ac49ac73 (HEAD -> u-boot-edge-bananapim3) The Armbian changes 866ca972d6c3cabeaf6dbac431e8e08bb30b3c8e (tag: v2024.01) Prepare v2024.01 82750ce44226e5f2b3bbcd79cf7b3ba3dfd3de4d arm: dts: iot2050: Fix by syncing from Linux The HEAD and branch links point to the new git object.
But the v2024.01 tag continues to point to 866ca972d6c3cabeaf6dbac431e8e08bb30b3c8e
 
Let's add the debugging code and make a commit:
leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ sudo nano drivers/mmc/sunxi_mmc.c leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ sudo git add drivers/mmc/sunxi_mmc.c leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ sudo git commit -m "define DEBUG macros for sunxi mmc"  
Look at the last commit. This is what will be extracted using the command "git format-patch -1":
leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ git log -p -1 commit c5a54a85e206c32c4a17aa573c8f409899c2a77a (HEAD -> u-boot-edge-bananapim3) Author: The-going <48602507+The-going@users.noreply.github.com> Date: Wed Sep 25 09:09:47 2024 +0000 define DEBUG macros for sunxi mmc diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c index 8b684929e0..c32c9bda28 100644 --- a/drivers/mmc/sunxi_mmc.c +++ b/drivers/mmc/sunxi_mmc.c @@ -33,6 +33,8 @@ #include "sunxi_mmc.h" +#define DEBUG + #ifndef CCM_MMC_CTRL_MODE_SEL_NEW #define CCM_MMC_CTRL_MODE_SEL_NEW 0 #endif  
We will extract these changes to the target directory:
leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ git format-patch -1 -o /home/leo/armbian/patch/u-boot/u-boot-sunxi/ /home/leo/armbian/patch/u-boot/u-boot-sunxi/0001-define-DEBUG-macros-for-sunxi-mmc.patch leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ mv /home/leo/armbian/patch/u-boot/u-boot-sunxi/0001-define-DEBUG-macros-for-sunxi-mmc.patch /home/leo/armbian/patch/u-boot/u-boot-sunxi/define-DEBUG-macros-for-sunxi-mmc.patch leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ cat /home/leo/armbian/patch/u-boot/u-boot-sunxi/define-DEBUG-macros-for-sunxi-mmc.patch From c5a54a85e206c32c4a17aa573c8f409899c2a77a Mon Sep 17 00:00:00 2001 From: The-going <48602507+The-going@users.noreply.github.com> Date: Wed, 25 Sep 2024 09:09:47 +0000 Subject: [PATCH] define DEBUG macros for sunxi mmc --- drivers/mmc/sunxi_mmc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c index 8b684929e0..c32c9bda28 100644 --- a/drivers/mmc/sunxi_mmc.c +++ b/drivers/mmc/sunxi_mmc.c @@ -33,6 +33,8 @@ #include "sunxi_mmc.h" +#define DEBUG + #ifndef CCM_MMC_CTRL_MODE_SEL_NEW #define CCM_MMC_CTRL_MODE_SEL_NEW 0 #endif -- 2.34.1 I have removed the prefix number of the patch file name so that the patch is applied last.
 
If I do git format-patch -1 v2024.01 I will get the changes that are stored in the git object referenced by this v2024.01 tag.
 
Do I need to write here how to correctly add multiple changes to the kernel?
 

install in system:
sudo apt-get install network-manager try this in terminal
nmcli device wifi list nmcli device wifi connect "$SSID" password "$PASSWORD" I know it's not recommended by developers / @Igor connecting to wifi on Armbian FW ... but I did it like on standard Linux and it also works on FW from OrangePi suppliers 🙂

Quite interesting!
If you try to explain your ultimate goal and the reasons that led you to this decision, perhaps I can give you some advice.