Search the Community

@fabiobassa and @RaptorSDS the issue isnt due to the desktop environment or it not booting, My system works with the 4.4 legacy, it just doesn't use the Mali400 chip for graphics. I provided the image of what happens when I use anything other than the legacy kernal as extra context, that doesnt happen when I update or upgrade, when I set up a desktop environment myself it works fine. I will try @fabiobassa's rootfs just to see what its about, and if it some how allows me to used the Lima, panfrost, or built in Mali drivers I will stick with it, thanks!

Yes Yes, but you won't get any lima or panfrost anyway, 4.4 is way too old kernel. Also Panfrost is of no use, since it does not support Utgard (Mali-400) but only Midgard and above

@jock yes it is indeed NAND, I have also read through the first page a few times when I first came across it, (thanks for the Quick installation instructions on NAND btw) I do want to use the internal flash rather than an external sd card or usb, (just for the fun of it tbh as its not like this is a mission critical device), I assume this basically has me locked off to the lima or panfrost drivers then? is it possible to compile my own on the device itself?

Hi, im having some GPU driver issues - RK-3229 - 4.4.194-legacy-rk322x some info: The image I am using on my device is; Armbian_22.02.0-trunk_Rk322x-box_bullseye_legacy_4.4.194_minimal.img I chose this, as any of the other images from here; https://users.armbian.com/jock/rk322x/armbian/stable/ other than the xfce desktop image would lead to this happening: (if there's a fix for this I'd rather use one of the more up to date images) with the bullseye legacy minimal image set up on my device I then did this: yes | sudo apt update yes | sudo apt dist-upgrade yes | sudo apt --fix-missing yes | sudo apt install neofetch chromium xorg xfce4 lightdm sudo reboot heres the neofetch output if it helps with anything: user@rk322x-box:/lib/modules/4.4.194-legacy-rk322x/kernel/drivers/gpu/drm/rockchip$ neofetch _,met$$$$$gg. user@rk322x-box ,g$$$$$$$$$$$$$$$P. --------------- ,g$$P" """Y$$.". OS: Debian GNU/Linux 11 (bullseye) armv7l ,$$P' `$$$. Host: Generic RK322x TV Box board ',$$P ,ggs. `$$b: Kernel: 4.4.194-legacy-rk322x `d$$' ,$P"' . $$$ Uptime: 58 mins $$P d$' , $$P Packages: 564 (dpkg) $$: $$. - ,d$$' Shell: bash 5.1.4 $$; Y$b._ _,d$P' Resolution: 1920x1080p60 Y$$. `.`"Y$$$$P"' Terminal: /dev/pts/0 `$$b "-.__ CPU: Generic DT based system (4) @ 1.200GHz `Y$$ Memory: 228MiB / 962MiB `Y$$. `$$b. `Y$$b. `"Y$b._ `""" when looking into the drivers I can find these: user@rk322x-box:/lib/modules/4.4.194-legacy-rk322x/kernel/drivers/gpu/arm/mali400/mali$ ls mali.ko user@rk322x-box:/lib/modules/4.4.194-legacy-rk322x/kernel/drivers/gpu/drm/rockchip$ ls rockchip_drm_tve.ko this is expected. I am aware from other posts and threads in the forums that for Mali400 I should install the Lima driver for it; when trying to use mesa to set up both Lima and Panfrost it typically fails because of missing dependencies (that when I try to manually install cannot be found) or has no issues but when I look into the drivers/gpu/(arm or drm) directories there is nothing different from what I previously showed and if I look for lima or panfrost within lsmod the modules are not in the list. appears like this: user@rk322x-box:/lib/modules/4.4.194-legacy-rk322x/kernel/drivers/gpu/drm/rockchip$ lsmod Module Size Used by lz4 16384 4 lz4_compress 16384 1 lz4 gpio_ir_recv 16384 0 mali 233472 0 snd_soc_rk3228 16384 1 lzo 16384 4 zram 24576 2 fuse 94208 1 ip_tables 24576 0 autofs4 32768 2 as a side note: user@rk322x-box:~$ export "DISPLAY=:0" user@rk322x-box:~$ xset -dpms user@rk322x-box:~$ LIBGL_ALWAYS_SOFTWARE=1 glxinfo | grep "OpenGL vendor\|OpenGL renderer" OpenGL vendor string: Mesa/X.org OpenGL renderer string: llvmpipe (LLVM 11.0.1, 128 bits) (output is the same when the command does not contain LIBGL_ALWAYS_SOFTWARE=1) (this is how I would check the renderer, I typically check from ssh as its easier to type commands from my pc due to the small amount of space I have in my setup, however even when im using the terminal on the tv box without ssh the result it the same) any help would be appreciated. thank you

I managed to get one of my helios64 crash with the above code indeed, with linux-u-boot-edge-helios64_22.02.1_arm64.deb on kernel 5.15.93 indeed. Armbian 23.8.1 bullseye ttyS2 [ 115.729058] Internal error: Oops: 86000005 [#1] PREEMPT SMP [ 115.729568] Modules linked in: bluetooth unix_diag veth nft_masq nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 bridge dm_mod ipt_REJECT nf_reject_ipv4 xt_multiport nft_compat nft_counter nf_tables nfnetlink binfmt_misc rfkill lz4hc lz4 zram raid456 async_memcpy async_raid6_recov async_pq async_xor async_tx md_mod r8152 cdc_acm snd_soc_hdmi_codec snd_soc_rockchip_i2s snd_soc_rockchip_pcm leds_pwm pwm_fan snd_soc_core gpio_charger panfrost snd_pcm_dmaengine snd_pcm gpu_sched snd_timer snd soundcore realtek rockchip_vdec(C) hantro_vpu(C) rockchip_iep rockchip_rga v4l2_h264 videobuf2_dma_contig videobuf2_vmalloc videobuf2_dma_sg v4l2_mem2mem videobuf2_memops fusb302 sg videobuf2_v4l2 videobuf2_common dwmac_rk tcpm stmmac_platform typec videodev mc stmmac pcs_xpcs adc_keys gpio_beeper cpufreq_dt ledtrig_netdev lm75 sunrpc ip_tables x_tables autofs4 [ 115.736491] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G C 5.15.93-rockchip64 #23.02.2 [ 115.737279] Hardware name: Helios64 (DT) [ 115.737631] pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 115.738252] pc : 0xffff8004080d5e8c [ 115.738573] lr : 0xffff8004080d5e8c [ 115.738887] sp : ffff800009df3e60 [ 115.739185] x29: ffff800009df3e60 x28: ffff00000078bb00 x27: 0000000000000000 [ 115.739826] x26: ffff800009eebc80 x25: 0000000000000001 x24: ffff000000404300 [ 115.740467] x23: 00000000000000c0 x22: ffffffffffffffd0 x21: ffff8000095504a8 [ 115.741105] x20: ffff0000f77ab980 x19: ffffffffffffffd0 x18: 0000000000000000 [ 115.741744] x17: ffff8000ee06c000 x16: ffff800009df4000 x15: 00001f1e8e1e9e92 [ 115.742384] x14: 00000000000003f6 x13: 0000000000000056 x12: 0000000000000000 [ 115.743023] x11: 0000000000000001 x10: 0000000000000000 x9 : 0000000000000056 [ 115.743662] x8 : ffff0000f77aba00 x7 : ffff0000f77aba30 x6 : 0000000000000001 [ 115.744301] x5 : ffff8000ee06c000 x4 : 0000000000010002 x3 : 000000000001b663 [ 115.744940] x2 : ffffffffffffa88d x1 : 00000000ffff4b2f x0 : 000000000000d5ba [ 115.745580] Call trace: [ 115.745802] 0xffff8004080d5e8c [ 115.746088] flush_smp_call_function_queue+0x114/0x250 [ 115.746557] generic_smp_call_function_single_interrupt+0x14/0x20 [ 115.747103] ipi_handler+0x7c/0x340 [ 115.747423] handle_percpu_devid_irq+0xa0/0x240 [ 115.747830] handle_domain_irq+0x90/0xd8 [ 115.748187] gic_handle_irq+0xb8/0x134 [ 115.748528] call_on_irq_stack+0x28/0x50 [ 115.748883] do_interrupt_handler+0x58/0x68 [ 115.749261] el1_interrupt+0x30/0x78 [ 115.749585] el1h_64_irq_handler+0x18/0x28 [ 115.749954] el1h_64_irq+0x74/0x78 [ 115.750261] arch_cpu_idle+0x18/0x28 [ 115.750584] default_idle_call+0x40/0x184 [ 115.750949] do_idle+0x1fc/0x270 [ 115.751245] cpu_startup_entry+0x28/0x50 [ 115.751602] secondary_start_kernel+0x164/0x178 [ 115.752011] __secondary_switched+0x90/0x94 [ 115.752396] Code: bad PC value [ 115.752677] ---[ end trace 0ceb9c6e6a618ff5 ]--- [ 115.753092] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 115.753699] SMP: stopping secondary CPUs [ 116.920717] SMP: failed to stop secondary CPUs 0,5 [ 116.921146] Kernel Offset: disabled [ 116.921458] CPU features: 0x800820f1,20000846 [ 116.921847] Memory Limit: none [ 116.922129] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---

If you’re still taking suggestions there for overlays … don’t forget the g_ether (usb gadget Ethernet support) a good reference for overlays would just be the raspberry pi overlays directory… just got to change the actual settings of the pins and what not… but it’s a good base that’s well documented, including things like the hdmi hot plug etc, the video memory… one thing I noticed if you are doing the dtc with the gpu “okay” thing… it works on the “beta” 6.1 Debian from OrangePi, but I noticed that the CMA memory ? Could be wrong acronym … but I didn’t find it in the DTB /DTC when I was changing the gpu from disabled to okay… but when you run the command `dmesg | grep cma` in terminal it shows in the “beta” 6.1 Debian is only 128mB … but I think The CMA is shared with everything not specific to the GPU, but that would most likely need to be raised maybe by like 64mBs or more for mesa / Mali panfrost driver? But if your up to making that an overlay then depending on users need they can just set whatever value they need… ref: https://developer.toradex.com/software/linux-resources/linux-features/contiguous-memory-allocator-cma-linux/#intended-audience https://lwn.net/Articles/396707/ oh and there is something with the ETH or EMAC that’s kinda strange but if you look at bottom of page 16 it references 2 interfaces emac0 10/100/1000 and emac1 10/100, which really doesn’t make sense to me, ( I have an OrangePi zero2w ) I don’t have the external adapter board but it claims it’s 10/100… but if you read in that datasheet ( I know it says h616 … but that’s what pops up when you click h618), it says that the 10/100 (emac1) interface is internal only… so that means the 10/100/1000 (emac0) is what’s actually exposed to the pins, why they need a second IC for the 10/100/1000 on OrangePi zero 3 🤷‍♂️or why the zero2w only has 10/100 ( maybe the pcb design or w/e couldn’t be routed for the 1000 speed 🤷‍♂️) But maybe something there that they might have missed that might address the Ethernet bugs or issues you had encountered / patched ? Like maybe something is mapped incorrectly that the internal 10/100 is being used ? I assume the internal one would be for bridging / vlans like maybe for the g_ether I mentioned above ? So it has its own dedicated phy / bus 🤷‍♂️ another thing, remember the mail GPU is just the 3d acceleration hardware it really doesn’t address anything about the other hardware on the chip ref: page 12, the 2d graphics (G2D) or the “display engine”, 🤷‍♂️heh a lot of random things like that I don’t understand or is not clearly documented anywhere but the datasheet, but then if you look at the arm website for Mali-g31 ref: https://developer.arm.com/downloads/-/mali-drivers/bifrost-kernel notice it mentions: “Note that these components are not a complete driver stack. To build a functional OpenGL ES you need access to the full source code of the Mali GPU DDK, which is provided under the standard Arm commercial licence to all Mali GPU customers.” So if Sunix / allwinner doesn’t provide that then I guess we out of luck for that part of it… or maybe it’s just already in the mainline kernel or panfrost mesa driver 🤷‍♂️… I also tried installing Wayland GNOME as an alternative login / desktop manager option, but that just crashes after awhile and the CPU usage is madness just moving the mouse across the screen heh. But according to the docs I think it specifically says the Mali supports x11 Wayland Vulcan and the non windowed one (can’t find that doc ATM) but also I think you mentioned you looked at this , but this might address the hdmi issues etc in the case you were referring to something else in cedrus video graphics docs https://linux-sunxi.org/Display

Kinda a long one ... but it's been like 1 week trying to get u-boot and all this stuff correct on my own not specific to armbian. But, been searching all over for all sorts of things, made comments on the uboot/uboot github etc.. I'm learning this whole linux uboot etc... maybe this might be useful, any input or corrections etc let me know. The uboot/uboot github you got to pay attention to the branches... The orangepi_zero3 is almost identical to the orangepi_zero2w. but in no way is the orangepi_zero2 and zero2w compatible don't even bother looking at that, except for maybe the the eth phy , but since the 2w doesn't have that, I don't see a chip in docs, or on the board (maybe on the expansion board but I don't have one, those docs, same don't really show anything unless its built into the rj45 board connector or just uses the SoC). The zero3 does have a `motorcomm=y` the chip (10/100/1000) that is in the defconfig from uboot/uboot.. the zero2 has some `rtl8211f=y` in the defconfig, that might be the only thing (maybe) that the zero2 and zero2w might have in common. So the DDR4 if you look at the schematics side by side orangepi_zero3 and 2w they are the same (not just ddr4 but everything - the eth ic). the PMIC are the same and the busses and voltages are all the same ( one of them the schematic shows extra capacitors but the voltage / "bus" address all the same) The WiFi chip is the same power / pins etc, I saw someone mentioned the WiFi no working but on the official (beta build 6.1 debian) I've had no issues with it (haven't benched marked it or anything), on the older debian it gave me issues, like on first boot I could get my apt updates, after that restart it wouldn't connect, but it would after a second reboot... ( not sure I remember some of those helium miners I messed around with had issues like that, and a lot of the time it was the 2.4ghz and 5ghz home routers, would have the same SSID name and for whatever reason some of those drivers / chips would get stumped on that). As I was looking around I finally stumbled on the "next" branch in the the `1.`orangepi-build github directory, and that things been getting updates like every week and is like a year ahead of the master branch. There are no instructions there... But for the past 10 hours I been going threw it and banging out the headaches of figuring it out... but its kind of different and I'm just learning what all this different parts of uboot / linux build are structured. ref `1.` : https://github.com/orangepi-xunlong/orangepi-build/tree/next This seems to be the files you might need to compare here with what you got ( just referencing the wifi area since I noticed that was an issue a lot of people were having) zero2w https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/packages/pack-uboot/sun50iw9/bin/dts/orangepizero2w-u-boot-current.dts#L2707 zero3 - should be same note the difference in line number... https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/packages/pack-uboot/sun50iw9/bin/dts/orangepizero3-u-boot-current.dts#L2688 Some other files here that have settings, other board in the parent folder... https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/packages/pack-uboot/sun50iw9/bin/sys_config/sys_config_orangepizero2w.fex But also in the above files notice the HDMI ( someone was saying something about that) I had an issue with an armbian I downloaded 2-3 of the community versions for the 2w and it kinda worked... but I had issues with the HDMI with a DVI converter, I could see stuff it was just all glitching out, and would stall out on me. I tried it with just plugging it in HDMI to the TV HDMI (no dvi adapter + 1080) and it wasn't glitching out, I think the GNOME and the video drivers crash it im guessing, I did try to install GNOME on the official working xfce debian "beta" 6.1 and it was lagging hard, I tried to figure out wayland but leaving that for after I build this kernel to have "full control" of my debuging etc.. The orange pi beta 6.1 debian worked fine with the HDMI to DVI at any res, and the 6.1 mainline kernel I think already has the support for the Mali gpu, ( I still had to build it, with mesa etc for getting gstreamer ffmpeg codecs etc... I built that like 3 different ways... via the debian-mali method, with the ARM docs method, and random stuff I first found. As I've been going through the orangepi-build files / build I'm pretty sure there was a setting / option already set for PanfrostLima ... debian-mali https://wiki.debian.org/PanfrostLima#Hardware_support Mesa-mali https://docs.mesa3d.org/drivers/panfrost.html ARM-mali https://developer.arm.com/downloads/-/mali-drivers/bifrost-kernel But if you go into the orangepi-build/external/ you'll find all the things I mentioned above, and how I have been confirming all my random configs I been hacking together over the week. That repo is actually very well organized vs the other things I been going through, just files seem to have different names, and/or are structured more for whiptail style config / build system (actually really nice once you figure out how to get it to run (I even made / currently debuging a windows 11 Dockerfile that lets me use build on windows using linux docker, with the whole 'docker in docker' method). So you might not find like a defconfig (I'm not sure how armbian does this), but all the settings are there, even if they are mixed into a file that just builds those files out... but its actually convenient because you see the orangepi_zero3 and zero2w on the same page or directory without 10000 files in it, separated by whatever if statement / setting that is different. for example https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/config/sources/families/include/sunxi64_common.inc#L69 https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/config/sources/families/sun50iw9.conf#L118 Like it all works, I'm just in that stage of trying to update it to newer mainline kernels, fixing w.e errors pop up on my windows docker build attempt... but if your happy with what they got already there 6.1 and 5.4... and the ./build.sh just runs a menu config, that lets you build each part separate , uboot / kernel / fs .. and it has option for updating the kernel through the standard menuconfig. Preset configs that auto load into the menuconfig for orangepi_zero2w /zero3 and be completely adjusted from the whiptail menu... ref: - check parent folder for the other models https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/config/kernel/linux-6.1-sun50iw9-next.config So there are no instructions for that thing but this is what I was able to do, but then ran into, and still debugging some stuff (just for my windows docker container) 1. `git clone https://github.com/orangepi-xunlong/orangepi-build.git` 2. `cd ./orangepi-build` 3. `sudo chmod +x build.sh` (if necessary) 4. `./build.sh` - Note the build process makes a docker image and downloads all the build dependencies, so you shouldn't need to. But if you are building on x86_64 linux it has some function in there that will throw an error `You are running on an unsupported system [ bookworm<distro> ]` , the function that causes this has a note 'Ubuntu 21.04.x (Hirsute) x86_64 is the only fully supported host OS release', but you can use this ENV / VAR in the console or maybe the ./build <arg> `export NO_HOST_RELEASE_CHECK=yes`, which will bypass that, but with no gaurentee if it will work. 5. from the whiptail menu pick what you want to build uboot, kernel, fs, etc.. - Note that once you go into that option, its going to build the option at the end, it does not go back to the main menu for you to pick the next build option, it builds 1 at a time, then at the end theres another option to put it together, ( this is where you can either switch to armbian or w.e @least you hopefully* got a working u-boot) - Note when you are going through each step of the build option you made it will give you a list, to pick which board -> the ram -> what branch you want to use "master" or "next", next is like 1 year ahead of master, especially for orangepi_zero2w / orangepi_zero3 Thats pretty much it you just repeat step 5 untill you build everything you want, then combine it with armbian, or w.e ( havent ever built a U-boot before), but it spits each step out to some output folder in that orangepi-build directory, if it works then just go copy the settings and update the armbian repo or w.e I know it was alot, but I got alot of info from this forum, and others so I figure I post where I'm at , where I Noticed an active thread dealing with this. Again I've never built U-boot before but I'm sure alot of us haven't so to save someone from 1-2 weeks of reading 5 year old post and what not thats what I've gathered. Happy Newyears eve ... dunno if im going to finish this build for a day or 2

Hello everyone, I've recently started migrating a project for Banana Pi M5 from Debian 10 Buster to Armbian, because I've found that the latest versions of it now support the GPU, Mali G31, and come with Panfrost OpenGL driver, which is crucial for this project. Everything was perfect until I had to implement two features: operating with TV via CEC and showing boot logo. Quickly about the last one - as I've understood, we have to use Plymouth, but I didn't really get how to do it, I've tried to activate it but had no success (how exactly see under paragraph). However, it doesn't work on Server Images (even on those that were compiled with build tools and activated option BOOT_LOGO in kernel conf), but in GUI Images everything is fine with it. Also I've tried using uBoot logo (boot-logo.bmp.gz), but also no success. # Adding "splash quiet loglevel=0 logo.nologo" to extraargs in "/boot/armbianEnv.txt" # Activating bootlogo in "/boot/boot.cmd" (am I even supposed to edit this file?) sudo plymouth-set-default-theme -R customtheme # It contains our logo # sudo update-initramfs -c -u # In fact, it runs automatically sudo reboot # ... sudo plymouthd sudo plymouth --show-splash Now about CEC. I've made some observations: CEC Under Debian # Sorry, there is no support for Shell syntax highlighting apparently. pi@TEST:~$ uname -a Linux TEST 4.9.312-BPI-M5 #1 SMP PREEMPT Wed Mar 1 01:44:35 UTC 2023 aarch64 GNU/Linux pi@TEST:~$ cec-client -l libCEC version: 4.0.4, compiled on Linux-4.9.0-8-arm64 ... , features: P8_USB, DRM, P8_detect, randr, Exynos, AOCEC Found devices: 1 device: 1 com port: AOCEC vendor id: 0000 product id: 0000 firmware version: 5 type: unknown pi@TEST:~$ ls -l /dev/*cec* crw-rw-rw- 1 root root 503, 0 Feb 14 2019 /dev/aocec pi@TEST:~$ echo 'standby 0' | cec-client -s -d 1 opening a connection to the CEC adapter... pi@TEST:~$ # Works fine. pi@TEST:~$ echo 'on 0' | cec-client -s -d 1 opening a connection to the CEC adapter... pi@TEST:~$ # Works fine. pi@TEST:~$ sudo lsmod | grep cec pi@TEST:~$ sudo find /lib/modules/ -name "*cec*" pi@TEST:~$ # No CEC module in lsmod or modules overall, but works fine. pi@TEST:~$ It uses AOCEC on 4.9 Linux kernel. Works flawlessly. All the parts in "/boot/boot.ini" concerning CEC: ... ### voutmode : hdmi or dvi setenv voutmode "hdmi" # setenv voutmode "dvi" # HPD enable/disable option setenv disablehpd "false" # Enable/Disable CEC setenv cec "true" ... ### Normal HDMI Monitors if test "${display_autodetect}" = "true"; then hdmitx edid; fi if test "${hdmimode}" = "custombuilt"; then setenv cmode "modeline=${modeline}"; fi if test "${cec}" = "true"; then setenv cec_enable "hdmitx=cec3f"; fi ... # Boot Args setenv bootargs "...${cec_enable} sdrmode=${sdrmode}" ... If I set cec "false" this happens: pi@TEST:~$ cec-client -l libCEC version: 4.0.4, compiled on Linux-4.9.0-8-arm64 ... , features: P8_USB, DRM, P8_detect, randr, Exynos, AOCEC Found devices: 1 device: 1 com port: AOCEC vendor id: 0000 product id: 0000 firmware version: 5 type: unknown pi@TEST:~$ ls -l /dev/*cec* crw-rw-rw- 1 root root 503, 0 Feb 14 2019 /dev/aocec pi@TEST:~$ echo 'standby 0' | cec-client -s -d 1 opening a connection to the CEC adapter... unable to open the device on port AOCEC ERROR: [ 2233] AllocateLogicalAddresses - failed to allocate device '0', type 'recording device' ERROR: [ 2233] failed to find a free logical address for the client ERROR: [ 2233] failed to register the new CEC client - cannot allocate the requested device types ERROR: [ 2233] failed to register a CEC client pi@TEST:~$ # Doesn't work pi@TEST:~$ Here, "/dev/aocec" doesn't sweep away when setting CEC to false. It just becomes unaccesible. CEC Under Armbian pi@TEST:~$ uname -a Linux TEST 6.6.8-edge-meson64 #1 SMP PREEMPT Wed Dec 20 16:02:07 UTC 2023 aarch64 GNU/Linux pi@TEST:~$ cec-client -l libCEC version: 6.0.2, compiled on Linux ... , features: P8_USB, DRM, P8_detect, randr, Exynos, Linux, AOCEC Found devices: NONE pi@TEST:~$ ls -l /dev/*cec* ls: cannot access '/dev/*cec*': No such file or directory pi@TEST:~$ echo 'standby 0' | cec-client -s -d 1 autodetect FAILED pi@TEST:~$ echo 'on 0' | cec-client -s -d 1 autodetect FAILED pi@TEST:~$ sudo lsmod | grep cec pi@TEST:~$ sudo find /lib/modules/ -name "*cec*" /lib/modules/6.6.8-edge-meson64/kernel/drivers/media/cec /lib/modules/6.6.8-edge-meson64/kernel/drivers/media/cec/usb/pulse8/pulse8-cec.ko /lib/modules/6.6.8-edge-meson64/kernel/drivers/media/cec/usb/rainshadow/rainshadow-cec.ko /lib/modules/6.6.8-edge-meson64/kernel/drivers/media/cec/platform/cec-gpio /lib/modules/6.6.8-edge-meson64/kernel/drivers/media/cec/platform/cec-gpio/cec-gpio.ko /lib/modules/6.6.8-edge-meson64/kernel/drivers/media/cec/platform/meson/ao-cec.ko /lib/modules/6.6.8-edge-meson64/kernel/drivers/media/cec/platform/meson/ao-cec-g12a.ko /lib/modules/6.6.8-edge-meson64/kernel/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.ko pi@TEST:~$ sudo modprobe cec pi@TEST:~$ sudo modprobe cec-gpio pi@TEST:~$ sudo modprobe ao-cec pi@TEST:~$ sudo modprobe ao-cec-g12a pi@TEST:~$ sudo modprobe dw-hdmi-cec pi@TEST:~$ sudo modprobe pulse8-cec pi@TEST:~$ sudo modprobe rainshadow-cec pi@TEST:~$ sudo lsmod | grep cec rainshadow_cec 16384 0 pulse8_cec 24576 0 dw_hdmi_cec 12288 0 ao_cec_g12a 12288 0 ao_cec 16384 0 cec_gpio 12288 0 pi@TEST:~$ # cec.ko isn't in libs so in lsmod there is no such module, but why "modprobe cec" gives no error? pi@TEST:~$ ls -l /dev/*cec* ls: cannot access '/dev/*cec*': No such file or directory pi@TEST:~$ # And activating modules just doesn't help, there is still no any "/dev/*cec*" device pi@TEST:~$ It doesn't use any of CEC on 6.6.8 Bleeding Edge Linux kernel (I've tested it before on stable 6.1 kernel, but it didn't work as well, I've activated some modules concerning CEC in kernel config and built using the latest possible kernel, thinking it will change something). Just doesn't work. AOCEC module is compiled and launched though, but it doesn't use it at all since there is no "/dev/*cec*" device. All the parts in "/boot/boot.cmd" concerning CEC: ... setenv sdrmode "auto" setenv voutmode "hdmi" setenv disablehpd "false" setenv cec "false" ... if test -e ${devtype} ${devnum} ${prefix}zImage; then ... setenv bootargs "...${cec_enable} sdrmode=${sdrmode}" ... Somehow, it misses the part where we should set "cec_enable" variable. What if I restore it and set to true? But I don't really think it will change something, as "/dev/aocec" existed on Debian even when CEC was disabled. That didn't work, as well as adding "hdmitx=cec3f" to extraargs in "/boot/armbianEnv.txt". There is just no CEC device in "/dev/", I don't know which type of problem is that - module, overlay, kernel?? Yes, I've used v4l, and it also fails because it doesn't find any "/dev/*cec*". Anyway, I hope this problem can be resolved and thanks to everyone for attention, have a happy new 2024 year!

Sorry @Gunjan Gupta not having much luck with these images unfortunately. I did a quick test of both kernel versions on a Zero2, and neither had HDMI output, although interestingly after the kernel boots it appears to send an HDMI signal (monitor detects it) but doesn't have any output. I tested both kernel versions using Bookworm as the OS. I noticed in your branch, you haven't enabled console output 'both' or marked display as 'yes', so I rebuilt after updating the configuration and unfortunately I still didn't get anything displaying on HDMI out. https://github.com/viraniac/armbian_build/blob/h616-hdmi/config/boards/orangepizero2.conf#L7-L8 I did test CPU Freq though and that appears to be working correctly. Here is some debugging output from the 6.1 Bookworm build. root@orangepizero2:~# uname -a Linux orangepizero2 6.1.69-current-sunxi64 #1 SMP Wed Dec 20 16:00:29 UTC 2023 aarch64 GNU/Linux root@orangepizero2:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 244 us. hardware limits: 480 MHz - 1.51 GHz available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 1.51 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.51 GHz (asserted by call to hardware). cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31% (333) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 244 us. hardware limits: 480 MHz - 1.51 GHz available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 1.51 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.51 GHz (asserted by call to hardware). cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31% (333) analyzing CPU 2: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 244 us. hardware limits: 480 MHz - 1.51 GHz available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 1.51 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.51 GHz (asserted by call to hardware). cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31% (333) analyzing CPU 3: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 244 us. hardware limits: 480 MHz - 1.51 GHz available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 1.51 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.51 GHz (asserted by call to hardware). cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31% (333) root@orangepizero2:~# lsmod Module Size Used by algif_hash 16384 1 algif_skcipher 16384 1 af_alg 24576 6 algif_hash,algif_skcipher bnep 28672 2 hci_uart 135168 1 btqca 24576 1 hci_uart btrtl 28672 1 hci_uart btbcm 20480 1 hci_uart btintel 40960 1 hci_uart bluetooth 724992 29 btrtl,btqca,btintel,hci_uart,btbcm,bnep ecdh_generic 16384 2 bluetooth ecc 32768 1 ecdh_generic sprdwl_ng 352256 0 sunxi_addr 20480 1 sprdwl_ng cfg80211 376832 1 sprdwl_ng sunrpc 290816 1 snd_soc_hdmi_codec 24576 0 lz4hc 16384 0 lz4 16384 0 polyval_ce 16384 0 sunxi_cedrus 45056 0 polyval_generic 16384 1 polyval_ce v4l2_mem2mem 36864 1 sunxi_cedrus videobuf2_dma_contig 24576 1 sunxi_cedrus videobuf2_memops 20480 1 videobuf2_dma_contig dw_hdmi_cec 16384 0 dw_hdmi_i2s_audio 16384 0 videobuf2_v4l2 24576 2 sunxi_cedrus,v4l2_mem2mem videobuf2_common 49152 5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_v4l2,v4l2_mem2mem,videobuf2_memops videodev 204800 4 sunxi_cedrus,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem panfrost 69632 0 mc 53248 5 sunxi_cedrus,videodev,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem gpu_sched 28672 1 panfrost dump_reg 24576 0 apple_mfi_fastcharge 20480 0 drm_shmem_helper 20480 1 panfrost display_connector 20480 0 cpufreq_dt 20480 0 zram 28672 3 binfmt_misc 24576 1 sprdbt_tty 36864 2 uwe5622_bsp_sdio 208896 2 sprdbt_tty,sprdwl_ng rfkill 36864 7 sprdbt_tty,bluetooth,cfg80211 fuse 126976 1 dm_mod 131072 0 hid_apple 28672 0 realtek 32768 1 dwmac_sun8i 28672 0 mdio_mux 16384 1 dwmac_sun8i root@orangepizero2:~# dmesg | grep -i hdmi [ 1.444604] sun8i-dw-hdmi 6000000.hdmi: Detected HDMI TX controller v2.12a with HDCP (DWC HDMI 2.0 TX PHY) [ 1.445267] sun8i-dw-hdmi 6000000.hdmi: registered DesignWare HDMI I2C bus driver [ 1.445657] sun4i-drm display-engine: bound 6000000.hdmi (ops 0xffff800008ea4d48) [ 96.336072] sun8i-dw-hdmi 6000000.hdmi: EVENT=plugin [ 96.336102] sun8i-dw-hdmi 6000000.hdmi: read_hpd result: 1 [ 103.529860] sun8i-dw-hdmi 6000000.hdmi: EVENT=plugin [ 189.979691] sun8i-dw-hdmi 6000000.hdmi: EVENT=plugin It seems very close, just not displaying anything. I will do some more testing and let you know if I get something to work. If anyone else has a Zero2 and wants to validate my testing, I have posted the images built from @Gunjan Gupta's HDMI testing branch here https://armdev.pixeldrift.net/orangepi/zero2/viraniac/

@piter75@ebin-dev Feel free to confirm the rockchip emmc phy pulldown dts indeed fixes emmc write in hs400es mode (I believe on most rk3399 boards, not only helios64). Likely on kernel up and above 6.1 (for the regulator fixes). Thanks to @RussianNeuroMancer I found: arm64: dts: rockchip: add enable-strobe-pulldown to emmc phy on nanopi4 https://github.com/torvalds/linux/commit/463be3cb357dab7d7e4d8dcc7c15c642e10c5bef and: phy: rockchip: set pulldown for strobe line in dts https://github.com/torvalds/linux/commit/8b5c2b45b8f0a11c9072da0f7baf9ee986d3151e which might be related to this emmc issue (as noted in the mainline patch in the rockchip kernel this emmc pulldown setting is always enabled while in mainline it is disabled by default). This patch was introduced in 5.11 which might explain why even with the regulator issue fixed (the one I found by regression testing) with kernel above 5.11 I still had hs400 failing on me. With this emmc_phy pulldown setting in the dts I can now write to the emmc in hs400es mode ! means one have to add "rockchip,enable-strobe-pulldown;" in the emmc_phy node for most boards --- arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts b/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts index 69d76dea35d0..3c1965660fbd 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts +++ b/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts @@ -436,10 +436,11 @@ &cpu_b0 { &cpu_b1 { cpu-supply = <&vdd_cpu_b>; }; &emmc_phy { + rockchip,enable-strobe-pulldown; status = "okay"; }; &gmac { assigned-clocks = <&cru SCLK_RMII_SRC>; @@ -965,13 +966,12 @@ &saradc { &sdhci { assigned-clock-rates = <150000000>; bus-width = <8>; mmc-hs200-1_8v; - // hs400 is broken on Helios64 since 5.10.60 - // mmc-hs400-1_8v; - // mmc-hs400-enhanced-strobe; + mmc-hs400-1_8v; + mmc-hs400-enhanced-strobe; supports-emmc; non-removable; disable-wp; status = "okay"; vqmmc-supply = <&vcc1v8_sys_s0>; -- There is also the regulator fix. Back then I bisected the first bad commit 06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66 which seems to have been a backport of the master branch to commit https://github.com/torvalds/linux/commit/98e48cd9283dbac0e1445ee780889f10b3d1db6a "regulator: core: resolve supply for boot-on/always-on regulators" introduced in 5.13. I am pretty confident the regulator issues were fixed at least in linux 6.1. Note that the emmc phy pulldown code was not backported to 5.10.y (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/phy/rockchip/phy-rockchip-emmc.c?h=linux-5.10.y) So I believe it was first included in 5.11. I no longer have the following CQE errors when writing to emmc in hs400es mode: [ 18.985162] mmc1: running CQE recovery [ 18.988056] ------------[ cut here ]------------ [ 18.988500] mmc1: cqhci: spurious TCN for tag 12 [ 18.989019] WARNING: CPU: 0 PID: 269 at drivers/mmc/host/cqhci-core.c:787 cqhci_irq+0x4b4/0x640 [ 18.989838] Modules linked in: quota_v2 quota_tree r8152 snd_soc_hdmi_codec ftdi_sio usbserial snd_soc_rockchip_i2s leds_pwm snd_soc_rockchip_pcm snd_soc_core snd_pcm_dmaengine snd_pcm pwm_fan gpio_charger snd_timer panfrost gpu_sched snd hantro_vpu(C) soundcore rockchip_vdec(C) v4l2_h264 rockchip_rga rockchip_iep videobuf2_dma_contig videobuf2_vmalloc videobuf2_dma_sg v4l2_mem2mem sg videobuf2_memops videobuf2_v4l2 videobuf2_common fusb302 videodev tcpm typec mc gpio_beeper cpufreq_dt nfsd dm_mod auth_rpcgss nfs_acl lockd grace ledtrig_netdev sunrpc lm75 ip_tables x_tables autofs4 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear raid10 uas realtek md_mod dwmac_rk stmmac_platform stmmac pcs_xpcs adc_keys [ 18.995876] CPU: 0 PID: 269 Comm: kworker/0:1H Tainted: G C 5.15.29-rockchip64 #trunk.0010 [ 18.996740] Hardware name: Helios64 (DT) [ 18.997104] Workqueue: kblockd blk_mq_run_work_fn [ 18.997555] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 18.998182] pc : cqhci_irq+0x4b4/0x640 [ 18.998537] lr : cqhci_irq+0x4b4/0x640 [ 18.998880] sp : ffff800008003d10 [ 18.999179] x29: ffff800008003d10 x28: ffff0000012b8e80 x27: ffff000004c2d580 [ 18.999819] x26: ffff00000652fc98 x25: ffff8000094d0888 x24: ffff800009c975e8 [ 19.000462] x23: ffff8000094f49c8 x22: 0000000000000002 x21: ffff000004c2d000 [ 19.001107] x20: 000000000000000c x19: ffff00000652fc80 x18: 0000000000000010 [ 19.001754] x17: ffff8000ee03c000 x16: ffff800008004000 x15: 00000000000002f6 [ 19.002400] x14: ffff800008003a20 x13: 00000000ffffffea x12: ffff800009abfbc8 [ 19.003047] x11: 0000000000000003 x10: ffff800009aa7b88 x9 : ffff800009aa7be0 [ 19.003694] x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001 [ 19.004338] x5 : ffff8000ee03c000 x4 : 0000000000000000 x3 : 0000000000010004 [ 19.004980] x2 : 0000000000010003 x1 : f94ce7e57b395a00 x0 : 0000000000000000 [ 19.005623] Call trace: [ 19.005852] cqhci_irq+0x4b4/0x640 [ 19.006169] sdhci_arasan_cqhci_irq+0x5c/0x88 [ 19.006564] sdhci_irq+0xcc/0x10c0 [ 19.006876] __handle_irq_event_percpu+0x60/0x250 [ 19.007302] handle_irq_event_percpu+0x38/0x90 [ 19.007705] handle_irq_event+0x48/0xe8 [ 19.008058] handle_fasteoi_irq+0xb8/0x148 [ 19.008430] handle_domain_irq+0x90/0xd8 [ 19.008788] gic_handle_irq+0xb8/0x138 [ 19.009131] call_on_irq_stack+0x28/0x50 [ 19.009492] do_interrupt_handler+0x58/0x68 [ 19.009874] el1_interrupt+0x30/0x78 [ 19.010202] el1h_64_irq_handler+0x18/0x28 [ 19.010575] el1h_64_irq+0x74/0x78 [ 19.010889] preempt_count_sub+0x34/0xc0 [ 19.011251] _raw_spin_unlock_irqrestore+0x20/0x40 [ 19.011686] sdhci_cqe_enable+0x130/0x228 [ 19.012060] sdhci_arasan_cqe_enable+0x94/0xb8 [ 19.012465] cqhci_request+0xd0/0x650 [ 19.012808] mmc_cqe_start_req+0xb4/0x198 [ 19.013177] mmc_blk_mq_issue_rq+0x494/0x9a8 [ 19.013567] mmc_mq_queue_rq+0x114/0x2b0 [ 19.013928] blk_mq_dispatch_rq_list+0x120/0x7e8 [ 19.014355] __blk_mq_sched_dispatch_requests+0xc4/0x1e0 [ 19.014835] blk_mq_sched_dispatch_requests+0x3c/0x78 [ 19.015291] __blk_mq_run_hw_queue+0x64/0xa0 [ 19.015678] blk_mq_run_work_fn+0x20/0x30 [ 19.016042] process_one_work+0x20c/0x4c8 [ 19.016407] worker_thread+0x48/0x478 [ 19.016739] kthread+0x138/0x150 [ 19.017033] ret_from_fork+0x10/0x20 [ 19.017358] ---[ end trace 70e1eee6af816777 ]--- [ 19.020419] mmc1: running CQE recovery [ 19.025922] mmc1: running CQE recovery [ 19.028135] blk_update_request: I/O error, dev mmcblk1, sector 1605640 op 0x1:(WRITE) flags 0x800 phys_seg 57 prio class 0 [ 19.029190] Buffer I/O error on dev mmcblk1p1, logical block 196609, lost sync page write [ 19.029989] EXT4-fs error (device mmcblk1p1): ext4_check_bdev_write_error:218: comm sed: Error while async write back metadata [ 19.030191] Aborting journal on device mmcblk1p1-8. [ 19.032803] EXT4-fs (mmcblk1p1): Remounting filesystem read-only [ 19.033426] EXT4-fs error (device mmcblk1p1) in __ext4_new_inode:1136: Journal has aborted Feel free to submit this patch to Armbian github or even to the mainline helios64 dts on your side.

Success! Will post more details soon, but combining my u-boot mainline config, dts config and the work from @Gunjan Gupta it built a clean working image. Don't have time at the moment to get all the details posted, but here is the lsmod showing it using panfrost. It's built against 6.6.4, was having issues with the sun4i-drm on edge (6.6.7 now), will dig through that later. root@orangepizero3:~# uname -a Linux orangepizero3 6.6.4-edge-sunxi64 #1 SMP Sun Dec 3 06:33:10 UTC 2023 aarch64 GNU/Linux root@orangepizero3:~# lsmod Module Size Used by rfkill 24576 1 sunrpc 290816 1 lz4hc 12288 0 lz4 12288 0 binfmt_misc 20480 1 zram 28672 3 sunxi_cedrus 49152 0 v4l2_mem2mem 28672 1 sunxi_cedrus videobuf2_dma_contig 20480 1 sunxi_cedrus videobuf2_memops 16384 1 videobuf2_dma_contig videobuf2_v4l2 20480 2 sunxi_cedrus,v4l2_mem2mem polyval_ce 12288 0 videodev 221184 3 sunxi_cedrus,videobuf2_v4l2,v4l2_mem2mem snd_soc_hdmi_codec 20480 0 apple_mfi_fastcharge 16384 0 videobuf2_common 45056 5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_v4l2,v4l2_mem2mem,videobuf2_memops panfrost 69632 0 polyval_generic 12288 1 polyval_ce mc 57344 5 sunxi_cedrus,videodev,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem gpu_sched 32768 1 panfrost drm_shmem_helper 16384 1 panfrost dump_reg 20480 0 fuse 126976 1 dm_mod 131072 0 hid_apple 24576 0 motorcomm 24576 1 dw_hdmi_cec 12288 0 dw_hdmi_i2s_audio 12288 0 dwmac_sun8i 24576 0 mdio_mux 12288 1 dwmac_sun8i display_connector 16384 0 Massive thanks @Gunjan Gupta, the sun4i patch was the missing piece.

I created a patch to bring across all the HDMI elements in the Orange Pi SDK dtsi to support the configuration in the dts/dtb file for the zero3. This took a fair bit of effort (cascading dependencies), and the dtb builds cleanly, but still no display.. but I do now get display_connector showing up in lsmod.. so I suspect it's slightly closer again root@orangepizero3:~# lsmod Module Size Used by sunrpc 290816 1 lz4hc 12288 0 lz4 12288 0 zram 28672 3 binfmt_misc 20480 1 polyval_ce 12288 0 polyval_generic 12288 1 polyval_ce panfrost 69632 0 gpu_sched 32768 1 panfrost fuse 126976 1 dm_mod 131072 0 motorcomm 24576 1 dwmac_sun8i 24576 0 mdio_mux 12288 1 dwmac_sun8i display_connector 16384 0 Now I have the following 'hdmi' lines mentioned in dmesg: root@orangepizero3:~# dmesg | grep -i hdmi [ 0.025260] platform 6510000.tcon-top: Fixed dependency cycle(s) with /soc/hdmi@6000000/ports/port@0/endpoint [ 0.029227] platform connector: Fixed dependency cycle(s) with /soc/hdmi@6000000/ports/port@1/endpoint will look for mentions of sun8i-dw-hdmi and sun4i-drm that show up in the hdmi messages in dmesg of the Orange Pi SDK image.

I did more google searches for possible keywords: [v4,0/8] Allwinner H6 Mali GPU support https://patchwork.kernel.org/project/linux-arm-kernel/cover/20190512174608.10083-1-peron.clem@gmail.com/ a DTS for H6 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts?h=v6.6 but note that H6 has a different gpu from H616 but possibly 'similar' from kernel versions 6.6 and above H616, H618 dts (device tree source) is made up of an include template https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi?h=v6.6 and a board specific template for OPi Zero 2 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts?h=v6.6 then for OPi Zero 3 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts?h=v6.6 in the linux sunxi-for-next repository the only things found in the board is addition of dts template for OrangePi Zero 2W https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/for-next mali gpu and hdmi doesn't seemed featured in all 3 of them (Zero 2, Zero 3, Zero 2w). We may need to review how it is done in H6 to see if after all the same driver works similarly some abstracts from H6 dtsi https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi?h=sunxi/for-next // SPDX-License-Identifier: (GPL-2.0+ OR MIT) // Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io> #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/clock/sun50i-h6-ccu.h> #include <dt-bindings/clock/sun50i-h6-r-ccu.h> #include <dt-bindings/clock/sun6i-rtc.h> #include <dt-bindings/clock/sun8i-de2.h> #include <dt-bindings/clock/sun8i-tcon-top.h> #include <dt-bindings/reset/sun50i-h6-ccu.h> #include <dt-bindings/reset/sun50i-h6-r-ccu.h> #include <dt-bindings/reset/sun8i-de2.h> #include <dt-bindings/thermal/thermal.h> / { interrupt-parent = <&gic>; #address-cells = <1>; #size-cells = <1>; cpus { ... line 65 de: display-engine { compatible = "allwinner,sun50i-h6-display-engine"; allwinner,pipelines = <&mixer0>; status = "disabled"; }; ... line 105 soc { compatible = "simple-bus"; #address-cells = <1>; #size-cells = <1>; ranges; bus@1000000 { compatible = "allwinner,sun50i-h6-de3", "allwinner,sun50i-a64-de2"; reg = <0x1000000 0x400000>; allwinner,sram = <&de2_sram 1>; #address-cells = <1>; #size-cells = <1>; ranges = <0 0x1000000 0x400000>; display_clocks: clock@0 { compatible = "allwinner,sun50i-h6-de3-clk"; reg = <0x0 0x10000>; clocks = <&ccu CLK_BUS_DE>, <&ccu CLK_DE>; clock-names = "bus", "mod"; resets = <&ccu RST_BUS_DE>; #clock-cells = <1>; #reset-cells = <1>; }; mixer0: mixer@100000 { compatible = "allwinner,sun50i-h6-de3-mixer-0"; reg = <0x100000 0x100000>; clocks = <&display_clocks CLK_BUS_MIXER0>, <&display_clocks CLK_MIXER0>; clock-names = "bus", "mod"; resets = <&display_clocks RST_MIXER0>; iommus = <&iommu 0>; ports { #address-cells = <1>; #size-cells = <0>; mixer0_out: port@1 { reg = <1>; mixer0_out_tcon_top_mixer0: endpoint { remote-endpoint = <&tcon_top_mixer0_in_mixer0>; }; }; }; }; }; video-codec-g2@1c00000 { compatible = "allwinner,sun50i-h6-vpu-g2"; reg = <0x01c00000 0x1000>; interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_VP9>, <&ccu CLK_VP9>; clock-names = "bus", "mod"; resets = <&ccu RST_BUS_VP9>; iommus = <&iommu 5>; }; video-codec@1c0e000 { compatible = "allwinner,sun50i-h6-video-engine"; reg = <0x01c0e000 0x2000>; clocks = <&ccu CLK_BUS_VE>, <&ccu CLK_VE>, <&ccu CLK_MBUS_VE>; clock-names = "ahb", "mod", "ram"; resets = <&ccu RST_BUS_VE>; interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>; allwinner,sram = <&ve_sram 1>; iommus = <&iommu 3>; }; gpu: gpu@1800000 { compatible = "allwinner,sun50i-h6-mali", "arm,mali-t720"; reg = <0x01800000 0x4000>; interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "job", "mmu", "gpu"; clocks = <&ccu CLK_GPU>, <&ccu CLK_BUS_GPU>; clock-names = "core", "bus"; resets = <&ccu RST_BUS_GPU>; #cooling-cells = <2>; status = "disabled"; }; crypto: crypto@1904000 { compatible = "allwinner,sun50i-h6-crypto"; reg = <0x01904000 0x1000>; interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_CE>, <&ccu CLK_CE>, <&ccu CLK_MBUS_CE>; clock-names = "bus", "mod", "ram"; resets = <&ccu RST_BUS_CE>; }; syscon: syscon@3000000 { compatible = "allwinner,sun50i-h6-system-control", "allwinner,sun50i-a64-system-control"; reg = <0x03000000 0x1000>; #address-cells = <1>; #size-cells = <1>; ranges; sram_c: sram@28000 { compatible = "mmio-sram"; reg = <0x00028000 0x1e000>; #address-cells = <1>; #size-cells = <1>; ranges = <0 0x00028000 0x1e000>; de2_sram: sram-section@0 { compatible = "allwinner,sun50i-h6-sram-c", "allwinner,sun50i-a64-sram-c"; reg = <0x0000 0x1e000>; }; }; sram_c1: sram@1a00000 { compatible = "mmio-sram"; reg = <0x01a00000 0x200000>; #address-cells = <1>; #size-cells = <1>; ranges = <0 0x01a00000 0x200000>; ve_sram: sram-section@0 { compatible = "allwinner,sun50i-h6-sram-c1", "allwinner,sun4i-a10-sram-c1"; reg = <0x000000 0x200000>; }; }; }; ccu: clock@3001000 { compatible = "allwinner,sun50i-h6-ccu"; reg = <0x03001000 0x1000>; clocks = <&osc24M>, <&rtc CLK_OSC32K>, <&rtc CLK_IOSC>; clock-names = "hosc", "losc", "iosc"; #clock-cells = <1>; #reset-cells = <1>; }; dma: dma-controller@3002000 { compatible = "allwinner,sun50i-h6-dma"; reg = <0x03002000 0x1000>; interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_DMA>, <&ccu CLK_MBUS_DMA>; clock-names = "bus", "mbus"; dma-channels = <16>; dma-requests = <46>; resets = <&ccu RST_BUS_DMA>; #dma-cells = <1>; }; ... line 783 hdmi: hdmi@6000000 { compatible = "allwinner,sun50i-h6-dw-hdmi"; reg = <0x06000000 0x10000>; reg-io-width = <1>; interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_SLOW>, <&ccu CLK_HDMI>, <&ccu CLK_HDMI_CEC>, <&ccu CLK_HDCP>, <&ccu CLK_BUS_HDCP>; clock-names = "iahb", "isfr", "tmds", "cec", "hdcp", "hdcp-bus"; resets = <&ccu RST_BUS_HDMI_SUB>, <&ccu RST_BUS_HDCP>; reset-names = "ctrl", "hdcp"; phys = <&hdmi_phy>; phy-names = "phy"; pinctrl-names = "default"; pinctrl-0 = <&hdmi_pins>; status = "disabled"; ports { #address-cells = <1>; #size-cells = <0>; hdmi_in: port@0 { reg = <0>; hdmi_in_tcon_top: endpoint { remote-endpoint = <&tcon_top_hdmi_out_hdmi>; }; }; hdmi_out: port@1 { reg = <1>; }; }; }; hdmi_phy: hdmi-phy@6010000 { compatible = "allwinner,sun50i-h6-hdmi-phy"; reg = <0x06010000 0x10000>; clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_SLOW>; clock-names = "bus", "mod"; resets = <&ccu RST_BUS_HDMI>; reset-names = "phy"; #phy-cells = <0>; }; As gpu includes various blocks, e.g. hdmi, the gpu itself e.g. Mali and panfrost drivers, and DMA, more may be at hand to get display working. The clocks are also important as in these SOCs we may need to enable/setup clocks to the various modules (e.g. HDMI, GPU, DMA etc) to 'turn them on'. And there can be a lot more such as video sync clocks etc, which probably is less relevant to HDMI, but that it is likely the geometry related setup (e.g. the W x H pixels, color depths and refresh rates for the frame buffers needs to be configured. There are very little docs out there about these in that regard. The sram blocks are probably there in h6 but likely not relevant to h616, h618. H6 has a separate processor within the SOC which accordingly is intended for various PMIC functions. e.g. turn off power. In Orange Pi Zero 3, that is probably adequately replaced by the AXP313A PMIC chip. There is also this thing about AC200 which apparently is relevant to H6 as well as H616, H618 https://linux-sunxi.org/AC200 But I think AC200 is mainly relevant to ethernet as the EPHY is there. The other 2 functional blocks in the AC200 is audio and composite video is probably different from HDMI. It is a bit strange as in H618 there is a separate motorcomm YT8531C Gigabit ethernet PHY, it is likely AC200 functionality is not used.

Hi @wast3d55, thanks for the offer.. I will try and get something workable that displays and let you know So a few more minor updates.. just sharing my process! (TLDR, panfrost is loading and detecting the correct mali device, but no HDMI yet) I tried patching in the entire orangepi dts from the orangepi repo, but had compilation failures due to the hdmi references (expected as much, it was a bit of a moon shot). After that experiment I just patched in the 'gpu' block from the orangepi repo dts.. and it's showing some positive results. Note, this is now building with 6.6.6 mainline kernel (as I am using edge and it has bumped up from 6.6.5) with the following patch applied (patched in by armbian build). This patch is basically replicating the zero2 patch that is already in Armbian, but with the updated address from the orangepi repo dts. I have also switched status to "okay" so it loads, but unfortunately this doesn't provide the same magic that is described in the instructions linked by @ag123 because the dts in mainline is missing the HDMI components (my theory). diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts index 00fe28caa..8a80de136 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts +++ b/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts @@ -16,6 +16,11 @@ phy-supply = <&reg_dldo1>; }; +&gpu { + mali-supply = <&reg_dcdc1>; + status = "okay"; +}; + &ext_rgmii_phy { motorcomm,clk-out-frequency-hz = <125000000>; }; Now, no display still, but it is looking promising. I still need to validate if below was because of the 6.6.6 kernel change, or because of my dts patch. @Stephen Graf can you lsmod your 6.6.6 image that doesn't have the patch?, or I can build a clean (no zero3 mali patch) 6.6.6 to compare. root@orangepizero3:~# uname -a Linux orangepizero3 6.6.6-edge-sunxi64 #1 SMP Mon Dec 11 09:40:17 UTC 2023 aarch64 GNU/Linux root@orangepizero3:~# dmesg | grep -i mali [ 6.297358] panfrost 1800000.gpu: mali-g31 id 0x7093 major 0x0 minor 0x0 status 0x0 root@orangepizero3:~# lsmod Module Size Used by rfkill 24576 1 sunrpc 290816 1 lz4hc 12288 0 lz4 12288 0 zram 28672 3 binfmt_misc 20480 1 polyval_ce 12288 0 polyval_generic 12288 1 polyval_ce panfrost 69632 0 gpu_sched 32768 1 panfrost fuse 126976 1 dm_mod 131072 0 motorcomm 24576 1 dwmac_sun8i 24576 0 mdio_mux 12288 1 dwmac_sun8i root@orangepizero3:~# dmesg | grep -i hdmi root@orangepizero3:~# I think the missing piece now is the HDMI configuration that is included in the orangepi repo dts, this appears to be missing in the mainline dts. I am going to see if I can pull that apart next and at least get hdmi modules loading.

more stuff googling for Mali as keyword https://en.wikipedia.org/wiki/Mali_(processor) https://github.com/cwabbott0/mali-isa-docs https://docs.mesa3d.org/drivers/lima.html and now "panfrost" shows up, this apparently is for recent versions of the Mali GPU, and probably include that on Orange Pi Zero 3 https://docs.mesa3d.org/drivers/panfrost.html Panfrost The Panfrost driver stack includes an OpenGL ES implementation for Arm Mali GPUs based on the Midgard and Bifrost microarchitectures. It is conformant on Mali-G52 and Mali-G57 but non-conformant on other GPUs. The following hardware is currently supported: Product Architecture OpenGL ES OpenGL Mali G31 Bifrost (v7) 3.1 3.1 https://linux-sunxi.org/images/b/b9/H616_Datasheet_V1.0_cleaned.pdf Figure 3-1 shows the system block diagram of the H616. GPU G31 and this: https://www.reddit.com/r/OrangePI/comments/16nrvs2/orange_pi_zero_3_gpu_acceleration_on_linux/ GPU is not enabled in the current builds be they 5.4 or 6.1 based, but you can enable it by editing the dtb. dtc -I dtb -O dts /boot/dtb/allwinner/sun50i-h616-orangepi-zero3.dtb >/tmp/op3.dts open /tmp/op3.dts with your favourite editor search for 'mali' - in the section where you find it edit the line status='disabled' to status='okay' - recompile dtc -I dts -O dtb /tmp/op3.dts >zero3.dtb - Then replace the original with this after backing up and reboot. - glxinfo should then show the panfrost driver in action. Needs the 6.1 (next) kernel version for GPU as panfrost is not enabled to about 5.14 hopefully we are 1 step closer

it seem for H616, H618, video (i.e. the gpu, hdmi video) isn't supported yet in mainline https://linux-sunxi.org/Linux_mainlining_effort there is a driver called panfrost https://github.com/hexdump0815/imagebuilder/blob/main/systems/allwinner_h616/readme.md But that I've not researched how to get that

Hello, this quick tutorial is to introduce an experimental Debian and Ubuntu APT repository to install ffmpeg compiled with v4l2request and v4l2drmprime patches developed by Linux kernel, LIbreELEC and Kodi folks to allow hardware video decoding on stateless decoders like those implemented in Rockchip and Allwinner SoCs for h.264, h.265, vp8 and vp9 codecs. The repository introduces a new ffmpeg package that integrates and substitues the base ffmpeg package and its related packages. Preconditions: Mainline kernel 6.1 or more recent armhf or arm64 architecture Supported distributions: Debian 12 - Bookworm Debian 13 - Trixie (only arm64) Ubuntu 22.04 - Jammy Ubuntu 24.04 - Noble Rockchip and Allwinner have already been tested, but this should work on other platforms with stateless decoders supported in kernel APT REPOSITORY SETUP To install the repository, just copy and paste the lines in a terminal: $ sudo wget http://apt.undo.it:7242/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc $ . /etc/os-release && echo "deb http://apt.undo.it:7242 $VERSION_CODENAME main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list $ echo -e "Package: *\nPin: release o=apt.undo.it\nPin-Priority: 600" | sudo tee /etc/apt/preferences.d/apt-undo-it INSTALL FFMPEG AND MPV PACKAGES $ sudo apt update $ sudo apt install ffmpeg mpv SETUP MPV CONFIG FILE $ sudo mkdir -p /etc/mpv $ echo -e "hwdec=drm\ndrm-drmprime-video-plane=primary\ndrm-draw-plane=overlay" | sudo tee /etc/mpv/mpv.conf You can now play your videos using mpv and they should run with hardware decoding if supported, either in virtual terminals or in X11/Wayland windows! Enjoy! Notes: your mileage may vary a lot: the more recent is the kernel version, the better is support (you may need edge kernel) bug: when rendered in X11/Wayland window, video may show scattered tiles during frames bug: Lima driver (Mali 400/450) shows a red/pink tint when video is played in X11/Wayland (see https://github.com/mpv-player/mpv/issues/12968) (workaround below: https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/?do=findComment&comment=177968) you may want to add --gpu-hwdec-interop=drmprime-overlay to the mpv command line if used in pure virtual terminal (no X, no Wayland) to use direct-to-overlay output Panfrost driver should work flawlessy 10 bit HEVC are generally supported on all Rockchip devices (rk322x, rk3288, rk33x8, rk3399), but Allwinner H3 have no hardware support for that

Description This is a follow-up of: https://github.com/armbian/build/pull/5901 It resolves a conflict between the SimpleDRM and Panfrost graphic drivers by blacklisting simpledrm. Other boards of the same family are assumed to have the same issue and will probably benefit from this fix as well. However, the fix has been actually tested only on the Khadas VIM3. I cannot test this change for other boards, as I do not own them. The Banana Pi M5 was also included for this change, because the driver conflict has also been mentioned in another Jira ticket. Note that this board is of the meson-sm1 family! How Has This Been Tested? Perhaps someone else has these boards available for testing? Checklist: [X] My code follows the style guidelines of this project [X] I have performed a self-review of my own code [X] I have commented my code, particularly in hard-to-understand areas [N/A] I have made corresponding changes to the documentation [X] My changes generate no new warnings [N/A] Any dependent changes have been merged and published in downstream modules View the full article

Description Some high-resolution monitors (QHD/4K) will not output the desktop, and will enter sleep mode, directly after booting up an Armbian 23.8.1 desktop image and completing the initial setup questions. When such a monitor is attached, the kernel will auto-detect the SimpleDRM graphics driver, which is then prioritized over the Panfrost graphics driver. However, SimpleDRM outputs to a virtual output, while Panfrost outputs to the actual HDMI port. This causes the monitor to not receive any data. By blacklisting the simpledrm kernel module, Panfrost will take care of accelerated graphics (for any monitor) by default. Advanced users can still access simpledrm if required. Jira reference number [AR-1908] How Has This Been Tested? An Armbian image with a Cinnamon desktop has been build using the default options. That image has been written to a SD-card and tested on both a QHD monitor (that had the initial problem) and an older Full HD monitor (that worked fine before as well). In both test cases, the simpledrm kernel module was not loaded. The desktop was visible on the HDMI output both on initial boot and after subsequent reboots. Checklist: [X] My code follows the style guidelines of this project [X] I have performed a self-review of my own code [X] I have commented my code, particularly in hard-to-understand areas [N/A] I have made corresponding changes to the documentation [X] My changes generate no new warnings [N/A] Any dependent changes have been merged and published in downstream modules View the full article

@Igor No, specifically for the VIM3, at least for now. Topics that relate to SimpleDRM (here and here) always refer to Panfrost as well. I think that there is a conflict between SimpleDRM and Panfrost. I can imagine that SimpleDRM does work out well for other boards, where an accelerated 3D driver is not available. Thanks for that suggestion. I think that blacklisting the module is preferred over not building/including it in the image, so that advanced users have can still have access to SimpleDRM if they require. I just gave it a try: https://github.com/armbian/build/compare/main...sdeleeuw:armbian-build:fix/khadas-vim3-blacklist-simpledrm The resulting image does contain the blacklist file in /etc/modprobe.d, but the simpledrm is still loaded (early) in the initramfs. Just executing `update-initramfs -u` and rebooting fixes the issue. I noticed that there is some caching mechanism inside the Armbian build scripts. Perhaps the initramfs is taken from cache rather that being re-build with the blacklist file in place?

FWIW 23.02.2/5.15.93 crashes on shutdown. [ OK ] Reached target reboot.target - System Reboot. [10787.888857] watchdog: watchdog0: watchdog did not stop! [10788.208644] xhci-hcd xhci-hcd.3.auto: Host halt failed, -110 [10788.209246] ------------[ cut here ]------------ [10788.209658] WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/drm_modeset_lock.c:266 drm_modeset_lock+0xe4/0x108 [10788.210510] Modules linked in: rfkill ip6t_REJECT nf_reject_ipv6 xt_hl ip6_tables binfmt_misc ip6t_rt ipt_REJECT leds_pwm gpio_charger nf_reject_ipv4 xt_LOG pwm_fan panfrost snd_soc_hdmi_codec snd_soc_rockchip_i2s gpu_sched nf_log_syslog snd_soc_rockchip_pcm xt_multiport snd_soc_core hantro_vpu(C) rockchip_vdec(C) rockchip_rga xt_comment rockchip_iep v4l2_h264 snd_pcm_dmaengine videobuf2_dma_contig videobuf2_dma_sg videobuf2_vmalloc v4l2_mem2mem nft_limit snd_pcm videobuf2_memops videobuf2_v4l2 snd_timer xt_limit videobuf2_common xt_addrtype snd lz4hc videodev lz4 mc soundcore xt_tcpudp xt_conntrack nf_conntrack gpio_beeper cpufreq_dt nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nft_counter sg nf_tables nfnetlink zram nfsd auth_rpcgss nfs_acl lockd grace ledtrig_netdev lm75 sunrpc dm_mod ip_tables x_tables autofs4 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear md_mod r8152 realtek cdc_ncm cdc_ether usbnet fusb302 tcpm dwmac_rk typec [10788.210772] stmmac_platform stmmac pcs_xpcs adc_keys [10788.218830] CPU: 1 PID: 1 Comm: systemd-shutdow Tainted: G C 5.15.93-rockchip64 #23.02.2 [10788.219659] Hardware name: Helios64 (DT) [10788.220009] pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [10788.220626] pc : drm_modeset_lock+0xe4/0x108 [10788.221010] lr : drm_modeset_lock+0x40/0x108 [10788.221393] sp : ffff800009e1bb50 [10788.221689] x29: ffff800009e1bb50 x28: ffff000000680000 x27: 0000000000000000 [10788.222326] x26: ffff000000fce490 x25: ffff8000094bfc80 x24: 0000000000000008 [10788.222962] x23: ffff800009d38050 x22: ffff000008bcf000 x21: ffff8000095504a8 [10788.223599] x20: ffff000008bcf188 x19: ffff800009e1bbe0 x18: 0000000000000010 [10788.224236] x17: 0000000000000000 x16: 0000000000000000 x15: 000000000000035d [10788.224872] x14: ffff800009e1b800 x13: 00000000ffffffea x12: ffff800009b2fe58 [10788.225509] x11: 0000000000000003 x10: ffff800009b17e18 x9 : ffff800009e1bb88 [10788.226145] x8 : ffff800009e1bbb0 x7 : ffff800009e1bbb0 x6 : 0000000000000001 [10788.226781] x5 : 0000000000000000 x4 : ffff800009e1bbe0 x3 : ffff000008bcf188 [10788.227418] x2 : 0000000000000000 x1 : ffff000008bcf1b0 x0 : 0000000000000000 [10788.228055] Call trace: [10788.228276] drm_modeset_lock+0xe4/0x108 [10788.228629] drm_modeset_lock_all_ctx+0x28/0xf8 [10788.229037] drm_atomic_helper_shutdown+0x74/0x130 [10788.229468] rockchip_drm_platform_shutdown+0x18/0x28 [10788.229921] platform_shutdown+0x24/0x38 [10788.230275] device_shutdown+0x148/0x240 [10788.230629] kernel_restart_prepare+0x38/0x48 [10788.231023] kernel_restart+0x18/0x68 [10788.231353] __do_sys_reboot+0x220/0x248 [10788.231706] __arm64_sys_reboot+0x24/0x30 [10788.232067] invoke_syscall+0x44/0x108 [10788.232407] el0_svc_common.constprop.3+0x94/0xf8 [10788.232828] do_el0_svc+0x24/0x98 [10788.233127] el0_svc+0x20/0x50 [10788.233406] el0t_64_sync_handler+0x90/0xb8 [10788.233780] el0t_64_sync+0x180/0x184 [10788.234110] ---[ end trace 744dd2aea6b1d549 ]--- [10788.234544] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 [10788.235352] Mem abort info: [10788.235618] ESR = 0x0000000096000004 [10788.235950] EC = 0x25: DABT (current EL), IL = 32 bits [10788.236417] SET = 0, FnV = 0 [10788.236687] EA = 0, S1PTW = 0 [10788.236964] FSC = 0x04: level 0 translation fault [10788.237391] Data abort info: [10788.237645] ISV = 0, ISS = 0x00000004 [10788.237981] CM = 0, WnR = 0 [10788.238244] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000096eb000 [10788.238809] [0000000000000018] pgd=0000000000000000, p4d=0000000000000000 [10788.239408] Internal error: Oops: 96000004 [#1] PREEMPT SMP [10788.239898] Modules linked in: rfkill ip6t_REJECT nf_reject_ipv6 xt_hl ip6_tables binfmt_misc ip6t_rt ipt_REJECT leds_pwm gpio_charger nf_reject_ipv4 xt_LOG pwm_fan panfrost snd_soc_hdmi_codec snd_soc_rockchip_i2s gpu_sched nf_log_syslog snd_soc_rockchip_pcm xt_multiport snd_soc_core hantro_vpu(C) rockchip_vdec(C) rockchip_rga xt_comment rockchip_iep v4l2_h264 snd_pcm_dmaengine videobuf2_dma_contig videobuf2_dma_sg videobuf2_vmalloc v4l2_mem2mem nft_limit snd_pcm videobuf2_memops videobuf2_v4l2 snd_timer xt_limit videobuf2_common xt_addrtype snd lz4hc videodev lz4 mc soundcore xt_tcpudp xt_conntrack nf_conntrack gpio_beeper cpufreq_dt nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nft_counter sg nf_tables nfnetlink zram nfsd auth_rpcgss nfs_acl lockd grace ledtrig_netdev lm75 sunrpc dm_mod ip_tables x_tables autofs4 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear md_mod r8152 realtek cdc_ncm cdc_ether usbnet fusb302 tcpm dwmac_rk typec [10788.240040] stmmac_platform stmmac pcs_xpcs adc_keys [10788.248043] CPU: 4 PID: 1 Comm: systemd-shutdow Tainted: G WC 5.15.93-rockchip64 #23.02.2 [10788.248864] Hardware name: Helios64 (DT) [10788.249209] pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [10788.249819] pc : ww_mutex_lock+0x54/0x88 [10788.250170] lr : drm_modeset_lock+0x40/0x108 [10788.250549] sp : ffff800009e1bb40 [10788.250841] x29: ffff800009e1bb40 x28: ffff000000680000 x27: 0000000000000000 [10788.251470] x26: ffff000000fce490 x25: ffff8000094bfc80 x24: 0000000000000008 [10788.252098] x23: 0000000000000000 x22: ffff000008bcf000 x21: ffff000008bcf2d8 [10788.252724] x20: 0000000000000018 x19: ffff800009e1bbe0 x18: 0000000000000010 [10788.253351] x17: 0000000000000000 x16: 0000000000000000 x15: 000000000000035d [10788.253979] x14: ffff800009e1b800 x13: 00000000ffffffea x12: ffff800009b2fe58 [10788.254607] x11: 0000000000000003 x10: ffff800009b17e18 x9 : ffff800009e1bb88 [10788.255234] x8 : ffff800009e1bbb0 x7 : ffff800009e1bbb0 x6 : 0000000000000001 [10788.255862] x5 : 0000000000000000 x4 : ffff800009e1bbe0 x3 : 0000000000000018 [10788.256489] x2 : ffff000000680000 x1 : 0000000000000000 x0 : 0000000000000018 [10788.257117] Call trace: [10788.257334] ww_mutex_lock+0x54/0x88 [10788.257651] drm_modeset_lock+0x40/0x108 [10788.257999] drm_modeset_lock_all_ctx+0x64/0xf8 [10788.258399] drm_atomic_helper_shutdown+0x74/0x130 [10788.258823] rockchip_drm_platform_shutdown+0x18/0x28 [10788.259269] platform_shutdown+0x24/0x38 [10788.259616] device_shutdown+0x148/0x240 [10788.259963] kernel_restart_prepare+0x38/0x48 [10788.260349] kernel_restart+0x18/0x68 [10788.260673] __do_sys_reboot+0x220/0x248 [10788.261021] __arm64_sys_reboot+0x24/0x30 [10788.261375] invoke_syscall+0x44/0x108 [10788.261708] el0_svc_common.constprop.3+0x94/0xf8 [10788.262123] do_el0_svc+0x24/0x98 [10788.262418] el0_svc+0x20/0x50 [10788.262689] el0t_64_sync_handler+0x90/0xb8 [10788.263058] el0t_64_sync+0x180/0x184 [10788.263384] Code: d50323bf d65f03c0 d2800001 f9800071 (c85ffc60) [10788.263920] ---[ end trace 744dd2aea6b1d54a ]--- [10788.264346] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [10788.265021] Kernel Offset: disabled [10788.265329] CPU features: 0x800820b1,20000846 [10788.265713] Memory Limit: none [10788.265988] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- U-Boot TPL 2022.07-armbian (Aug 22 2023 - 15:26:42) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB 256B stride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate: change freq to 800000000 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2022.07-armbian (Aug 22 2023 - 15:26:42 +0000) Trying to boot from MMC1 mmc_load_image_raw_sector: mmc block read error Trying to boot from SPI Trying to boot from MMC1 mmc_load_image_raw_sector: mmc block read error Trying to boot from MMC2 mmc_load_image_raw_sector: mmc block read error SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###

Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems registered: /dev/sdd registered: /dev/sdb registered: /dev/sde registered: /dev/sdc registered: /dev/sda done. Begin: Will now check root file system ... fsck from util-linux 2.38.1 [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 armbi_root: clean, 56356/1891776 files, 967727/7708672 blocks done. done. Begin: Running /scripts/local-bottom ... /scripts/local-bottom/mdadm: 2: /scripts/local-bottom/mdadm: rm: not found done. Begin: Running /scripts/init-bottom ... done. Welcome to Armbian 23.8.3 bookworm! [...] Starting networking.service - Raise network interfaces... [ 16.458082] Internal error: Oops - Undefined instruction: 0000000002000000 [#1] PREEMPT SMP [ 16.458852] Modules linked in: ip6t_REJECT nf_reject_ipv6 xt_hl ip6_tables ip6t_rt ipt_REJECT nf_reject_ipv4 xt_LOG nf_log_syslog xt_multiport xt_comment lz4hc nft_limit lz4 leds_pwm gpio_charger pwm_fan rockchip_vdec(C) hantro_vpu panfrost snd_soc_hdmi_codec snd_soc_rockchip_i2s v4l2_vp9 videobuf2_dma_contig v4l2_h264 rockchip_rga gpu_sched xt_limit drm_shmem_helper rockchip_rng snd_soc_core xt_addrtype videobuf2_dma_sg v4l2_mem2mem rng_core snd_compress videobuf2_memops snd_pcm_dmaengine xt_tcpudp videobuf2_v4l2 snd_pcm binfmt_misc videobuf2_common xt_conntrack videodev nf_conntrack snd_timer nf_defrag_ipv6 mc snd nf_defrag_ipv4 nft_compat soundcore nf_tables nfnetlink zram gpio_beeper cpufreq_dt sg ledtrig_netdev lm75 nfsd auth_rpcgss nfs_acl lockd grace dm_mod sunrpc ip_tables x_tables autofs4 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear md_mod realtek fusb302 tcpm dwmac_rk stmmac_platform stmmac typec pcs_xpcs adc_keys [ 16.466751] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G C 6.1.50-current-rockchip64 #3 [ 16.467567] Hardware name: Helios64 (DT) [ 16.467920] pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 16.468542] pc : __this_cpu_preempt_check+0x24/0x40 [ 16.468996] lr : ct_nmi_exit+0x80/0x280 [ 16.469348] sp : ffff800009ef3be0 [ 16.469647] x29: ffff800009ef3be0 x28: ffff000000762d00 x27: 0000000000000000 [ 16.470292] x26: ffff000000762d00 x25: 0000000000000000 x24: 0000000000000000 [ 16.470934] x23: ffff0000f779e8f0 x22: ffff800009a3dc70 x21: ffff8000094ea818 [ 16.471575] x20: ffff800009766900 x19: ffff8000097668f0 x18: 0000000000000000 [ 16.472215] x17: ffff8000ee038000 x16: ffff800009d20000 x15: 0000000000000000 [ 16.472857] x14: 0000000000000000 x13: 0000000000000303 x12: 0000000000000000 [ 16.473501] x11: 0000000000000000 x10: 0000000000000000 x9 : ffff0000f77a1f80 [ 16.474142] x8 : 0000000000000005 x7 : ffff0000f77a28f8 x6 : 00000000ffffffff [ 16.474781] x5 : ffff80000959a7e0 x4 : 0000000000000001 x3 : ffff800009757008 [ 16.475422] x2 : ffff000000762d00 x1 : ffff8000094ea818 x0 : 0000000000000005 [ 16.476063] Call trace: [ 16.476286] __this_cpu_preempt_check+0x24/0x40 [ 16.476700] ct_irq_exit+0x10/0x80 [ 16.477014] exit_to_kernel_mode.isra.0+0x20/0x2c [ 16.477440] el1_interrupt+0x58/0x6c [ 16.477766] el1h_64_irq_handler+0x18/0x2c [ 16.478139] el1h_64_irq+0x64/0x68 [ 16.478450] arch_cpu_idle+0x18/0x2c [ 16.478778] default_idle_call+0x38/0x17c [ 16.479143] do_idle+0x23c/0x2b0 [ 16.479442] cpu_startup_entry+0x24/0x30 [ 16.479800] secondary_start_kernel+0x124/0x150 [ 16.480221] __secondary_switched+0xb0/0xb4 [ 16.480627] Code: 9115e040 97ffffa6 a8c17bfd d50323bf (d65f03c0) [ 16.481180] ---[ end trace 0000000000000000 ]--- [ 16.481594] Kernel panic - not syncing: Attempted to kill the idle task! [ 16.482189] SMP: stopping secondary CPUs [ 16.482555] Kernel Offset: disabled [ 16.482869] CPU features: 0x40000,20824084,0000421b [ 16.483308] Memory Limit: none [ 16.483592] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- No luck, see kernel panic above. The missing command can be seen below; `Unknown command 'kaslrseed' - try 'help'`: U-Boot 2022.07-armbian (Aug 22 2023 - 15:26:42 +0000) SoC: Rockchip rk3399 Reset cause: POR DRAM: 3.9 GiB PMIC: RK808 Core: 339 devices, 31 uclasses, devicetree: separate SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB MMC: mmc@fe320000: 1, mmc@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Model: Helios64 Revision: 1.2 - 4GB non ECC Net: dw_dm_mdio_init: mdio node is missing, registering legacy mdio busNo ethernet found. scanning bus for devices... Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 3252 bytes read in 5 ms (634.8 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1 166 bytes read in 4 ms (40 KiB/s) 24417797 bytes read in 1036 ms (22.5 MiB/s) 29792768 bytes read in 1264 ms (22.5 MiB/s) 86670 bytes read in 12 ms (6.9 MiB/s) 2698 bytes read in 8 ms (329.1 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 09000000 Unknown command 'kaslrseed' - try 'help' Moving Image from 0x2080000 to 0x2200000, end=3f00000 ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 24417733 Bytes = 23.3 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f4794000, end f5edd5c5 ... OK Loading Device Tree to 00000000f4716000, end 00000000f4793fff ... OK Starting kernel ...

After two days of testing linux 6.6 seems almost perfect. However, on heavy network loads the 2.5G interface is not really stable yet and is reset several times during operation. It seems that cpu4 is overloaded by the transmission tasks and that those tasks need to be distributed differently between the cpu cores to avoid that. I switched back again to 6.1.60. [11806.608303] ------------[ cut here ]------------ [11806.608336] NETDEV WATCHDOG: end1 (r8152): transmit queue 0 timed out 8180 ms [11806.608512] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:525 dev_watchdog+0x298/0x2a0 [11806.608566] Modules linked in: xt_comment xt_tcpudp nft_compat nf_tables nfnetlink eq3_char_loop(O) rpi_rf_mod_led(O) dummy_rx8130(O) hb_rf_eth(O) generic_raw_uart(O) sunrpc lz4hc lz4 zram binfmt_misc cp210x usbserial hantro_vpu rockchip_vdec(C) rockchip_rga snd_soc_hdmi_codec snd_soc_rockchip_i2s v4l2_vp9 leds_pwm panfrost v4l2_h264 snd_soc_core videobuf2_dma_contig gpio_charger pwm_fan videobuf2_dma_sg v4l2_mem2mem snd_compress gpu_sched videobuf2_memops snd_pcm_dmaengine drm_shmem_helper rk_crypto snd_pcm videobuf2_v4l2 snd_timer videodev snd videobuf2_common mc soundcore cpufreq_dt gpio_beeper sg cfg80211 rfkill ledtrig_netdev lm75 dm_mod ip_tables x_tables autofs4 efivarfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear md_mod cdc_ncm cdc_ether usbnet realtek r8152 dwmac_rk fusb302 tcpm stmmac_platform stmmac typec pcs_xpcs adc_keys [11806.609441] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G C O 6.6.0-edge-rockchip64 #1 [11806.609468] Hardware name: Helios64 (DT) [11806.609483] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [11806.609511] pc : dev_watchdog+0x298/0x2a0 [11806.609543] lr : dev_watchdog+0x298/0x2a0 [11806.609573] sp : ffff800080003dc0 [11806.609586] x29: ffff800080003dc0 x28: ffff800080ea70d4 x27: ffff800080003ec0 [11806.609634] x26: ffff800081818008 x25: 0000000000001ff4 x24: ffff800081b67000 [11806.609680] x23: 0000000000000000 x22: ffff0000075f341c x21: ffff0000075f3000 [11806.609725] x20: ffff000007680c00 x19: ffff0000075f34c8 x18: ffffffffffffffff [11806.609771] x17: 6d20303831382074 x16: 756f2064656d6974 x15: 2030206575657571 [11806.609816] x14: 2074696d736e6172 x13: 0000000000000304 x12: 00000000ffffffea [11806.609862] x11: 00000000ffffefff x10: ffff800081be5f08 x9 : ffff800081b8deb0 [11806.609907] x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000057fa8 [11806.609951] x5 : 0000000000000fff x4 : 0000000000000000 x3 : 0000000000000027 [11806.609994] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800081b74680 [11806.610038] Call trace: [11806.610052] dev_watchdog+0x298/0x2a0 [11806.610083] call_timer_fn+0x34/0x1bc [11806.610113] __run_timers.part.0+0x228/0x2ec [11806.610141] run_timer_softirq+0x48/0x84 [11806.610167] __do_softirq+0x150/0x3e4 [11806.610191] ____do_softirq+0x10/0x1c [11806.610217] call_on_irq_stack+0x24/0x4c [11806.610242] do_softirq_own_stack+0x1c/0x28 [11806.610268] irq_exit_rcu+0xb4/0xe4 [11806.610298] el1_interrupt+0x38/0x68 [11806.610326] el1h_64_irq_handler+0x18/0x24 [11806.610354] el1h_64_irq+0x64/0x68 [11806.610375] default_idle_call+0x38/0x16c [11806.610407] do_idle+0x20c/0x264 [11806.610435] cpu_startup_entry+0x34/0x3c [11806.610461] kernel_init+0x0/0x1e0 [11806.610491] arch_post_acpi_subsys_init+0x0/0x8 [11806.610524] start_kernel+0x734/0x950 [11806.610554] __primary_switched+0xb4/0xbc [11806.610582] ---[ end trace 0000000000000000 ]--- [11806.610611] r8152 2-1.4:1.0 end1: Tx timeout [11806.612779] r8152 2-1.4:1.0 end1: Tx status -2 [11806.612997] r8152 2-1.4:1.0 end1: Tx status -2 [11806.613129] r8152 2-1.4:1.0 end1: Tx status -2 [11806.613246] r8152 2-1.4:1.0 end1: Tx status -2

Hello All, hope someone is fairing better with this. No real success in trying incremental steps. Adjusting regulators does not improve the situation at this point, was also entertaining the remote possibility of a floating pin. Am still trying a few ideas when have a moment. Driver issue or because of missing node (Bluetooth not included in this iteration)? [ 7.726690] WCN_ERR: dts node for bt_wake not found [ 7.851065] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 wifi@orangepizero2:~$ dmesg --level=err,crit,alert,emerg,warn [ 0.000000] The swapaccount= commandline option is deprecated. Please report your usecase to linux-mm@kvack.org if you depend on this functionality. [ 0.003562] cacheinfo: Unable to detect cache hierarchy for CPU 0 [ 2.290558] gpio gpiochip0: Static allocation of GPIO base is deprecated, use dynamic allocation. [ 2.303381] sun50i-h616-r-pinctrl 7022000.pinctrl: supply vcc-pl not found, using dummy regulator [ 2.308407] gpio gpiochip1: Static allocation of GPIO base is deprecated, use dynamic allocation. [ 2.332685] sun6i-spi 5010000.spi: Failed to request TX DMA channel [ 2.332722] sun6i-spi 5010000.spi: Failed to request RX DMA channel [ 2.333895] spi-nor spi0.0: supply vdd not found, using dummy regulator [ 2.391118] usb_phy_generic usb_phy_generic.1.auto: dummy supplies not allowed for exclusive requests [ 2.444911] mmc0: host does not support reading read-only switch, assuming write-enable [ 3.539599] dwmac-sun8i 5020000.ethernet: supply phy-io not found, using dummy regulator [ 3.540154] dwmac-sun8i 5020000.ethernet: Current syscon value is not the default 51fe6 (expect 0) [ 5.808023] (sd-execut[164]: /usr/lib/systemd/system-generators/netplan failed with exit status 1. [ 7.497417] device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log. [ 7.726690] WCN_ERR: dts node for bt_wake not found [ 7.851065] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 10.061599] sunxi_cedrus: module is from the staging directory, the quality is unknown, you have been warned. [ 26.659450] systemd[1150]: memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set wifi@orangepizero2:~$ dmesg | grep mmc* [ 0.000000] Kernel command line: root=UUID=297049c4-c91b-4a71-b5cb-307c6d169e2a rootwait rootfstype=ext4 splash=verbose console=ttyS0,115200 consoleblank=0 loglevel=1 ubootpart=bd833452-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u modules_load=uwe5622_bsp_sdio,sprdbt_tty,sprdwl_ng cgroup_enable=memory swapaccount=1 [ 0.000000] The swapaccount= commandline option is deprecated. Please report your usecase to linux-mm@kvack.org if you depend on this functionality. [ 0.000000] Unknown kernel command line parameters "splash=verbose ubootpart=bd833452-01 modules_load=uwe5622_bsp_sdio,sprdbt_tty,sprdwl_ng cgroup_enable=memory", will be passed to user space. [ 0.000929] Console: colour dummy device 80x25 [ 0.061320] HugeTLB: 0 KiB vmemmap can be freed for a 1.00 GiB page [ 0.061343] HugeTLB: 0 KiB vmemmap can be freed for a 32.0 MiB page [ 0.061364] HugeTLB: 0 KiB vmemmap can be freed for a 2.00 MiB page [ 0.061385] HugeTLB: 0 KiB vmemmap can be freed for a 64.0 KiB page [ 0.678756] iommu: Default domain type: Translated [ 0.678779] iommu: DMA domain TLB invalidation policy: strict mode [ 0.817414] xor: automatically using best checksumming function 32regs [ 0.817457] Key type asymmetric registered [ 0.817466] Asymmetric key parser 'x509' registered [ 0.862546] mousedev: PS/2 mouse device common for all mice [ 2.303381] sun50i-h616-r-pinctrl 7022000.pinctrl: supply vcc-pl not found, using dummy regulator [ 2.333895] spi-nor spi0.0: supply vdd not found, using dummy regulator [ 2.383164] sunxi-mmc 4020000.mmc: Got CD GPIO [ 2.384697] sunxi-mmc 4021000.mmc: allocated mmc-pwrseq [ 2.391118] usb_phy_generic usb_phy_generic.1.auto: dummy supplies not allowed for exclusive requests [ 2.409349] sunxi-mmc 4020000.mmc: initialized, max. request size: 16384 KB, uses new timings mode [ 2.444911] mmc0: host does not support reading read-only switch, assuming write-enable [ 2.446835] mmc0: new high speed SDHC card at address 59b4 [ 2.448328] mmcblk0: mmc0:59b4 SD 29.6 GiB [ 2.451946] mmcblk0: p1 [ 2.617847] sunxi-mmc 4021000.mmc: initialized, max. request size: 16384 KB, uses new timings mode [ 2.636734] mmc1: new high speed SDIO card at address 8800 [ 3.539599] dwmac-sun8i 5020000.ethernet: supply phy-io not found, using dummy regulator [ 4.148366] EXT4-fs (mmcblk0p1): mounted filesystem 297049c4-c91b-4a71-b5cb-307c6d169e2a ro with writeback data mode. Quota mode: none. [ 7.050867] systemd[1]: Listening on systemd-fsckd.socket - fsck to fsckd communication Socket. [ 7.751463] EXT4-fs (mmcblk0p1): re-mounted 297049c4-c91b-4a71-b5cb-307c6d169e2a r/w. Quota mode: none. [ 9.259283] systemd[1]: systemd-machine-id-commit.service - Commit a transient machine-id on disk was skipped because of an unmet condition check (ConditionPathIsMountPoint=/etc/machine-id). [ 16.981325] dwmac-sun8i 5020000.ethernet end0: PHY [stmmac-0:01] driver [RTL8211F Gigabit Ethernet] (irq=POLL) wifi@orangepizero2:~$ ali@orangepizero2:~$ lsmod Module Size Used by sunxi_cedrus 49152 0 polyval_ce 12288 0 v4l2_mem2mem 28672 1 sunxi_cedrus polyval_generic 12288 1 polyval_ce videobuf2_dma_contig 20480 1 sunxi_cedrus videobuf2_memops 16384 1 videobuf2_dma_contig videobuf2_v4l2 20480 2 sunxi_cedrus,v4l2_mem2mem lz4hc 12288 0 videodev 217088 3 sunxi_cedrus,videobuf2_v4l2,v4l2_mem2mem panfrost 69632 0 lz4 12288 0 videobuf2_common 45056 5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_v4l2,v4l2_mem2mem,videobuf2_memops gpu_sched 32768 1 panfrost mc 57344 5 sunxi_cedrus,videodev,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem drm_shmem_helper 16384 1 panfrost cpufreq_dt 16384 0 zram 28672 3 binfmt_misc 20480 1 cfg80211 380928 0 sprdbt_tty 36864 0 rfkill 24576 3 sprdbt_tty,cfg80211 uwe5622_bsp_sdio 204800 1 sprdbt_tty fuse 126976 1 dm_mod 131072 0 realtek 32768 1 dwmac_sun8i 24576 0 mdio_mux 12288 1 dwmac_sun8i ali@orangepizero2:~$ could the platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 be package related?

It was a short-lived satisfaction, the problem resurfaced in the same way after the reboot. # find / -name console /sys/class/tty/console /sys/devices/platform/fe5c0000.i2c/i2c-0/0-003c/graphics/fb0/console /sys/devices/platform/serial8250/tty/ttyS6/console /sys/devices/platform/serial8250/tty/ttyS4/console /sys/devices/platform/serial8250/tty/ttyS0/console /sys/devices/platform/serial8250/tty/ttyS7/console /sys/devices/platform/serial8250/tty/ttyS5/console /sys/devices/platform/serial8250/tty/ttyS3/console /sys/devices/platform/serial8250/tty/ttyS1/console /sys/devices/platform/fe660000.serial/tty/ttyS2/console /sys/devices/virtual/tty/console /dev/console How do i remove the line '/sys/devices/platform/fe5c0000.i2c/i2c-0/0-003c/graphics/fb0/console' which is my OLED display device ? For Usual User this is the result of lsmod without HDMI connected, there is unfortunately nothing about i2c in the modules. # lsmod Module Size Used by sunrpc 364544 1 crct10dif_ce 12288 1 polyval_ce 12288 0 snd_soc_simple_card 20480 0 btusb 69632 0 snd_soc_rk817 40960 1 snd_soc_hdmi_codec 20480 1 snd_soc_rockchip_i2s_tdm 32768 4 btrtl 32768 1 btusb 8821cu 1875968 0 snd_soc_simple_card_utils 32768 1 snd_soc_simple_card btintel 53248 1 btusb polyval_generic 12288 1 polyval_ce hantro_vpu 262144 0 snd_soc_core 270336 5 snd_soc_rockchip_i2s_tdm,snd_soc_hdmi_codec,snd_soc_rk817,snd_soc_simple_card_utils,snd_soc_simple_card btbcm 24576 1 btusb rockchip_rga 24576 0 v4l2_vp9 24576 1 hantro_vpu btmtk 12288 1 btusb snd_compress 28672 1 snd_soc_core ssd1307fb 20480 1 gpio_ir_recv 12288 0 rc_core 57344 2 gpio_ir_recv cfg80211 458752 1 8821cu v4l2_h264 16384 1 hantro_vpu ac97_bus 12288 1 snd_soc_core videobuf2_dma_contig 24576 1 hantro_vpu snd_pcm_dmaengine 16384 1 snd_soc_core bluetooth 819200 6 btrtl,btmtk,btintel,btbcm,btusb snd_pcm 143360 5 snd_soc_hdmi_codec,snd_compress,snd_soc_simple_card_utils,snd_soc_core,snd_pcm_dmaengine v4l2_mem2mem 40960 2 hantro_vpu,rockchip_rga videobuf2_dma_sg 16384 1 rockchip_rga snd_timer 40960 1 snd_pcm rfkill 28672 4 bluetooth,cfg80211 videobuf2_memops 16384 2 videobuf2_dma_contig,videobuf2_dma_sg snd 106496 5 snd_soc_hdmi_codec,snd_timer,snd_compress,snd_soc_core,snd_pcm joydev 24576 0 videobuf2_v4l2 32768 3 hantro_vpu,rockchip_rga,v4l2_mem2mem soundcore 12288 1 snd rk817_charger 20480 0 videobuf2_common 57344 7 videobuf2_dma_contig,videobuf2_v4l2,hantro_vpu,rockchip_rga,videobuf2_dma_sg,v4l2_mem2mem,videobuf2_memops lz4hc 12288 0 lz4 12288 0 zram 28672 3 binfmt_misc 24576 1 sch_fq_codel 16384 6 ip_tables 32768 0 x_tables 57344 1 ip_tables autofs4 45056 2 dw_hdmi_i2s_audio 12288 0 dw_hdmi_cec 12288 0 rockchipdrm 176128 0 dw_mipi_dsi 16384 1 rockchipdrm dw_hdmi 53248 2 dw_hdmi_i2s_audio,rockchipdrm panfrost 77824 0 analogix_dp 45056 1 rockchipdrm drm_display_helper 172032 3 rockchipdrm,dw_hdmi,analogix_dp gpu_sched 36864 1 panfrost display_connector 16384 0 spi_rockchip_sfc 16384 0 sdhci_of_dwcmshc 16384 0 cec 77824 3 dw_hdmi_cec,drm_display_helper,dw_hdmi drm_shmem_helper 20480 1 panfrost drm_dma_helper 20480 1 rockchipdrm drm_kms_helper 208896 8 dw_mipi_dsi,drm_dma_helper,display_connector,drm_display_helper,rockchipdrm,dw_hdmi,analogix_dp drm 651264 12 gpu_sched,drm_kms_helper,dw_mipi_dsi,drm_dma_helper,display_connector,drm_shmem_helper,drm_display_helper,rockchipdrm,dw_hdmi,panfrost,analogix_dp ahci_dwc 12288 0