pixdrift

So to confirm, this is also what you patched version looks like? Looking at the zero2 patch from @Gunjan Gupta https://github.com/armbian/build/pull/6040/commits/0620c16dd36168b255b82205ee9b375a642c3254 I am a little unsure as to why the wifi configuration is added to both: sun50i-h616-orangepi-zero.dtsi sun50i-h616-orangepi-zero2.dts Am I right that sun50i-h616-orangepi-zero2.dts should inherit this configuration from sun50i-h616-orangepi-zero.dtsi? If so, is there a reason for declaring it directly in the .dts file? Or am I misunderstanding how that inheritance works? The converse is also true, if it is declared in the .dts what is the value of repeating it in the .dtsi (if it's the same configuration)? Specifically these values: reg_vcc33_wifi: vcc33-wifi reg_vcc_wifi_io: vcc-wifi-io wifi_pwrseq: wifi-pwrseq My understanding is thesun50i-h616-orangepi-zero.dtsi is only consumed by the zero2 and zero3 dts files, can't it just be declared once in the sun50i-h616-orangepi-zero.dtsi? @Gunjan Gupta are you able to provide advice on this? Sorry I didn't pick this up in the PR.. probably would have been a better spot to discuss it. -edit- @Gunjan Gupta provided the answer in this post (two different kernel versions, different method/approach used in 6.1)

This is my combined dts file (with all patching applied) including the changes for wifi.. that isn't currently working.. interested to compare notes. Note: I haven't changed mmc0 configuration, so this may be the issue.. keen to hear any other feedback on what else may be missing. The comment that exists in mmc0 makes me nervous, wondering if anyone has a comment on that? or we are comfortable the new patch correctly supersedes this mmc0 configuration? (and concern raised in the comment). The patch doesn't change the dtsi at all, just the dts.. and adds the module line to the defconfig for the wifi drives. // SPDX-License-Identifier: (GPL-2.0+ OR MIT) /* * Copyright (C) 2023 Arm Ltd. */ /dts-v1/; #include "sun50i-h616-orangepi-zero.dtsi" / { model = "OrangePi Zero3"; compatible = "xunlong,orangepi-zero3", "allwinner,sun50i-h618"; connector { compatible = "hdmi-connector"; type = "d"; port { hdmi_con_in: endpoint { remote-endpoint = <&hdmi_out_con>; }; }; }; reg_vcc5v: vcc5v { /* board wide 5V supply directly from the USB-C socket */ compatible = "regulator-fixed"; regulator-name = "vcc-5v"; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; regulator-always-on; }; reg_vcc3v3: vcc3v3 { /* SY8089 DC/DC converter */ compatible = "regulator-fixed"; regulator-name = "vcc-3v3"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; vin-supply = <&reg_vcc5v>; regulator-always-on; }; reg_vcc33_wifi: vcc33-wifi { /* Always on 3.3V regulator for WiFi and BT */ compatible = "regulator-fixed"; regulator-name = "vcc33-wifi"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; regulator-always-on; vin-supply = <&reg_vcc5v>; }; reg_vcc_wifi_io: vcc-wifi-io { /* Always on 1.8V/300mA regulator for WiFi and BT IO */ compatible = "regulator-fixed"; regulator-name = "vcc-wifi-io"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; regulator-always-on; vin-supply = <&reg_vcc33_wifi>; }; wifi_pwrseq: wifi-pwrseq { compatible = "mmc-pwrseq-simple"; clocks = <&rtc 1>; clock-names = "osc32k-out"; reset-gpios = <&pio 6 18 GPIO_ACTIVE_LOW>; /* PG18 */ post-power-on-delay-ms = <200>; }; }; &de { status = "okay"; }; &hdmi { //hvcc-supply = <&reg_bldo1>; status = "okay"; }; &hdmi_out { hdmi_out_con: endpoint { remote-endpoint = <&hdmi_con_in>; }; }; &gpu { mali-supply = <&reg_dcdc1>; status = "okay"; }; &ehci0 { status = "okay"; }; &ehci1 { status = "okay"; }; &ehci2 { status = "okay"; }; &ehci3 { status = "okay"; }; &ohci0 { status = "okay"; }; &ohci1 { status = "okay"; }; &ohci2 { status = "okay"; }; &ohci3 { status = "okay"; }; &emac0 { allwinner,tx-delay-ps = <700>; phy-mode = "rgmii-rxid"; phy-supply = <&reg_dldo1>; }; &ext_rgmii_phy { motorcomm,clk-out-frequency-hz = <125000000>; }; &mmc0 { /* * The schematic shows the card detect pin wired up to PF6, via an * inverter, but it just doesn't work. */ broken-cd; vmmc-supply = <&reg_dldo1>; }; &mmc1 { vmmc-supply = <&reg_vcc33_wifi>; vqmmc-supply = <&reg_vcc_wifi_io>; mmc-pwrseq = <&wifi_pwrseq>; bus-width = <4>; non-removable; mmc-ddr-1_8v; status = "okay"; }; &r_i2c { status = "okay"; axp313: pmic@36 { compatible = "x-powers,axp313a"; reg = <0x36>; #interrupt-cells = <1>; interrupt-controller; interrupt-parent = <&pio>; interrupts = <2 9 IRQ_TYPE_LEVEL_LOW>; /* PC9 */ vin1-supply = <&reg_vcc5v>; vin2-supply = <&reg_vcc5v>; vin3-supply = <&reg_vcc5v>; regulators { /* Supplies VCC-PLL, so needs to be always on. */ reg_aldo1: aldo1 { regulator-always-on; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; regulator-name = "vcc1v8"; }; /* Supplies VCC-IO, so needs to be always on. */ reg_dldo1: dldo1 { regulator-always-on; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; regulator-name = "vcc3v3"; }; reg_dcdc1: dcdc1 { regulator-always-on; regulator-min-microvolt = <810000>; regulator-max-microvolt = <990000>; regulator-name = "vdd-gpu-sys"; }; reg_dcdc2: dcdc2 { regulator-always-on; regulator-min-microvolt = <810000>; regulator-max-microvolt = <1100000>; regulator-name = "vdd-cpu"; }; reg_dcdc3: dcdc3 { regulator-always-on; regulator-min-microvolt = <1100000>; regulator-max-microvolt = <1100000>; regulator-name = "vdd-dram"; }; }; }; }; &pio { vcc-pc-supply = <&reg_dldo1>; vcc-pf-supply = <&reg_dldo1>; vcc-pg-supply = <&reg_aldo1>; vcc-ph-supply = <&reg_dldo1>; vcc-pi-supply = <&reg_dldo1>; };

This is great news. I made an attempt at this last night but unfortunately it didn't work as expected.. and I haven't had a chance to have a closer look yet. The configuration for mmc0 concerned me, so I would be keen to see your patch/changes to see what I may have wrong? Reason I was slow to the wifi patches was I was provided some feedback by @wast3d55 that the expansion board USB ports weren't working on my latest build, so I have added configuration for these two additional ports and @wast3d55 has just provided confirmation that they are working correctly (thanks!). I will have an expansion board in the not too distant future so will add that to my testing in future Updates for USB ports added in this commit: https://github.com/pixdrift/armbian_build/blob/zero3/patch/kernel/archive/sunxi-6.6/patches.armbian/arm64-dts-sun50i-h618-orangepi-zero3-enable-HDMI-and-USB.patch So the only thing pending now I think is to get wifi working. @Stephen Graf would you be able to link to your repo (private message is fine) or maybe try your patches against my latest zero 3 commit above and share them? once we can confirm they are working, I will merge them in. I am happy to build a test image and share it for others on here to test too.

For anyone following this thread, the load issue with the wifi driver has also been mentioned on the Orange Pi forum here (with no resolution): http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=10454

Interesting, well at least it's a known issue! I have updated my zero 3 branch with the Ethernet stability patch (this also impacts zero 2). https://github.com/viraniac/armbian_build/commit/6af178324c8b4f2407f263f3f2b35d8b1e977da9 I should probably raise a PR back to your zero2w branch soon.. was thinking of adding wifi to the zero 3. Is your patch for zero 2 that I just tested the same as what you have in zero 2w?

I can confirm the wifi is working @Gunjan Gupta in the Zero2 image in your pull request. It prompts on initial configuration.. and works out of the box.. I tested both 2.4 Ghz and 5 Ghz, got DHCP address, connected to the Internet etc. all good. Only odd things I have noticed about the image (not likely introduced by these changes) 1. The image doesn't like rebooting and appears to get stuck waiting.. not sure if wifi related (once again, unlikely to be kernel change). I have had this every time I attempt to reboot it, and have to hard power cycle it. [ OK ] Finished systemd-reboot.service - System Reboot. [ OK ] Reached target reboot.target - System Reboot. [ 820.749967] systemd-shutdown[1]: Failed to set timeout to 10min: Invalid argument [ 830.901508] systemd-shutdown[1]: Waiting for process: 788 (armbian-hardwar), 771 (lscpu), 828 (lscpu) [ 920.929626] systemd-shutdown[1]: Waiting for process: 828 (lscpu), 788 (armbian-hardwar), 771 (lscpu) [ 1000.964547] (sd-remount)[2373]: Failed to remount '/' read-only: Device or resource busy [ 1000.978516] systemd-shutdown[1]: Failed to finalize file systems, ignoring.
 2. The load average seems to remain pretty constant at 1.00 when it's idle.. it does drop and go up occasionally.. not sure what's going on there.. doesn't appear to be in process time or iowait top - 14:42:06 up 41 min, 1 user, load average: 1.00, 1.00, 1.00 Tasks: 193 total, 1 running, 192 sleeping, 0 stopped, 0 zombie %Cpu0 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu1 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu2 : 0.7 us, 1.0 sy, 0.0 ni, 98.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu3 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 919.2 total, 631.5 free, 183.6 used, 173.2 buff/cache MiB Swap: 459.6 total, 459.6 free, 0.0 used. 735.6 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1837 root 20 0 11540 4864 2816 R 1.3 0.5 0:06.05 top 1 root 20 0 169416 12384 8416 S 0.0 1.3 0:04.42 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pool_wo+ 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker+ 5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker+ 6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker+ 7 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker+ 12 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker+ 13 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tas+ 14 root 20 0 0 0 0 S 0.0 0.0 0:00.04 ksoftir+ 15 root 20 0 0 0 0 I 0.0 0.0 0:00.28 rcu_sch+ 16 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migrati+ 17 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0 Happy to provide feedback in the PR that it's all good.. I will try and drag these changes across into the Zero3 config I have.

Hu @Gunjan Gupta, I would prefer to fix/text HDMI first (or at the same time) if we can. For some reason the Zero2 configuration in Armbian doesn't include video, likely because it was built from the original zero configuration that doesn't have HDMI? It also defaults the console to serial... I guess there is also the point that the H616 dtsi hasn't had HDMI configuration until about now https://github.com/armbian/build/blob/8da1805f9081e85dc3016e3e357e5f4836374e6a/config/boards/orangepizero2.conf#L8-L9 With your changes to the H616 dtsi, this should be a simple case of adding the GPU/HDMI configuration to the DTS, I was planning to test this next.. keen to hear your thoughts on that. Regarding wifi on the zero2 board (and testing in general), is there a test harness/test script you want to run on it to validate it? Should we take this opportunity to formalise a few tests for this and the zero3? Not sure how testing/CI is currently carried out on updated board configuration and images (other than they build cleanly!). 'bats' is my go to for this usually. https://github.com/bats-core/bats-core I don't know the ins and outs of getting wifi working (keen to understand all the components), so I haven't included it in the current zero3 config in my repo.. not sure if it's just a copy of the zero2w config? (it's lower down my list as it's not my primary use case tbh). Also, interested to know where you get details on the ehci/ochci devices, and the physical devices they map to on the board. I notice that the zero2 config mentions two are on the expansion board.. so I am deducing that there is one on the board, one via the GPIO pins and then two on the zero expansion board.. interested to know how I can map this configuration to the physical layout on the different boards (if anyone can explain it, or send docs I would appreciate it!)

I have added the required patches so this will now build cleanly for the Orange Pi Zero 3 for anyone that wants to build images for testing (still have testing of other components) To build your own image (Debian 12 tested so far) git clone https://github.com/pixdrift/armbian_build.git cd armbian_build git checkout zero3 ./compile.sh Then select orangepizero3 from the menu, and then select your image build options. Now that we are at this stage, wonder if it's worth moving this into a forum thread rather than the current 'question' format? and we can then work on testing/validating the build. I am happy to build/host some images if that would be testing easier for others who may not have the build environment setup. I think this would be better in a forum thread now though. I also saw @Stephen Graf mention Zero2 in another thread (not to be confused with Zero2W). I have a Zero2 here so can take a look at getting the HDMI working on there too (I don't believe it's currently enabled, but can discuss that in a separate chat.. it shouldn't be too difficult now all the 616 groundwork is in)

Thanks @Gunjan Gupta I have forked your github zero2w repo and will add everything I have (patches/config) to get zero 3 working so it's based off your existing work with minimal changes... hoping we can then work to get both boards into the mainline Armbian https://github.com/pixdrift/armbian_build/tree/zero3 I will post back here when I have all the changes tidied up, merged in, and building cleanly.

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.

Thanks @Gunjan Gupta, I hadn't taken a look at the Zero2w, I thought it was a basic variant of the Zero2, but it's an H618 with DDR4, basically the same as the Zero3.. which makes this information very relevant. The Zero2W is a pretty amazing board with the expansion.. I just ordered one Rather than testing this on Zero2, I will take a closer look at your patches for Zero3.. thanks!

Thanks for the information and the repo link @Gunjan Gupta, I have Zero2 here and will be able to test it. I am assuming you went down this route (getting video working on Zero2) because the current configuration in Armbian only provides serial for the Zero2? I will build off your repo for the Zero2 and see what results I get. Thanks again, great information!

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.

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.

@ag123 interesting to mentioned mali in the dtb, I found some kernel patches which refer to enabling mali for h616 that are specific to the zero2 board in Armbian.. looking at adding this patch to zero 3 and seeing if mali works. The patch is: /patch/kernel/sunxi-edge/patches.armbian/arm64-dts-sun50i-h616-orangepi-zero2-Enable-GPU-mali (modifies sun50i-h616-orangepi-zero2.dts) I think I have found what we need https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-6.1-sun50iw9/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero3.dts#L109-L123 I think swapping the .dts for the Orange Pi Zero 3 in mainline with the sunxi version would be a good test.. if not, just patch in the hdmi/gpu config lines.. see what happens with this now.

@Stephen Graf I have posted some info about a config I am working on here. This config is a drop in for Armbian and references the mainline u-boot commit that includes the Orange Pi Zero 3 defconfig, so no patching of u-boot is required (but agreed, will be good when they tag with a release). I also detail the single patch I have to remove for the image to build correctly on 'edge', but it doesn't appear to be the same image you mentioned? I built against 6.6.5 for my 'edge' image, I will rebuild now and see if I have similar results to yourself. My issue with the image currently is that it doesn't provide any video out via HDMI, but I can login via serial console and confirm it's working.

Hi ag123, I did take a look at this. The sunxi-cedrus module is already present in my Armbian image and loaded, you can confirm this from the lsmod output from the build I posted above. From the docs, cedrus looks to be specifically for video encoding/decoding acceleration not display. I don't believe it's related to my display issue. Regarding mainline support listed in: https://linux-sunxi.org/Linux_mainlining_effort H616 is listed with '?' for the HDMI elements, which is 'status unknown' not explicitly unsupported, and HDMI Video (assuming this is video output) for the H6 shows '5.0', so there may be some hope there. My goal at the moment is to replicate the HDMI output that is in the Orange Pi SDK build (even if it requires kernel patching) in the clean Armbian build, I can confirm this works (just figuring out _how_ it works). I have looked through the Orange Pi SDK Linux/u-boot source and haven't found anything specific yet.. I will keep looking

Thanks for posting those links @ag123, I will read them tomorrow. Only a quick update from me. I booted the Orange Pi released version of Debian Bookworm (Orangepizero3_1.0.2_debian_bookworm_server_linux6.1.31) for a comparison, and it has HDMI out, at least for the framebuffer... not currently looking at acceleration... just any video output on HDMI from the Armbian build tool build. These are the dmesg lines related to HDMI from the Orange Pi Debian image [ 0.032022] platform 6000000.hdmi: Fixed dependency cycle(s) with /soc/tcon-top@6510000 [ 0.034437] platform 6000000.hdmi: Fixed dependency cycle(s) with /connector [ 1.436612] sun8i-dw-hdmi 6000000.hdmi: supply hvcc not found, using dummy regulator [ 1.436839] sun8i-dw-hdmi 6000000.hdmi: Detected HDMI TX controller v2.12a with HDCP (DWC HDMI 2.0 TX PHY) [ 1.437282] sun8i-dw-hdmi 6000000.hdmi: registered DesignWare HDMI I2C bus driver [ 1.437669] sun4i-drm display-engine: bound 6000000.hdmi (ops 0xffff800008e84f08) This is the lsmod output orangepi@orangepizero3:~$ uname -a Linux orangepizero3 6.1.31-sun50iw9 #1.0.2 SMP Thu Sep 28 12:01:45 CST 2023 aarch64 GNU/Linux orangepi@orangepizero3:~$ lsmod Module Size Used by overlay 126976 0 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 712704 29 btrtl,btqca,btintel,hci_uart,btbcm,bnep ecdh_generic 16384 2 bluetooth ecc 32768 1 ecdh_generic sunrpc 286720 1 lz4hc 16384 0 lz4 16384 0 sprdbt_tty 36864 2 polyval_ce 16384 0 polyval_generic 16384 1 polyval_ce sunxi_cedrus 45056 0 sunxi_cir 20480 0 videobuf2_dma_contig 24576 1 sunxi_cedrus dw_hdmi_cec 16384 0 rc_core 49152 2 sunxi_cir v4l2_mem2mem 36864 1 sunxi_cedrus videobuf2_memops 20480 1 videobuf2_dma_contig 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 mc 53248 5 sunxi_cedrus,videodev,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem display_connector 20480 0 zram 28672 3 binfmt_misc 24576 1 sprdwl_ng 352256 0 sunxi_addr 20480 1 sprdwl_ng cfg80211 372736 1 sprdwl_ng rfkill 36864 7 sprdbt_tty,bluetooth,cfg80211 uwe5622_bsp_sdio 208896 2 sprdbt_tty,sprdwl_ng fuse 126976 1 dm_mod 131072 0 motorcomm 24576 1 dwmac_sun8i 28672 0 mdio_mux 16384 1 dwmac_sun8i Interestingly, for the images I tested, one of my monitors complained about the HDMI input timing of the signal coming from the Orange Pi Zero 3, so I re-validated with the monitor that was happy to display the output (and confirmed again the image I built with Armbian build tool doesn't have HDMI output.. yet). After looking at bit closer at the patches that were being applied in Armbian (15 in total, with 1 set to ignore), I found the following, which I think may be relevant. /patch/u-boot/u-boot-sunxi/allwinner-h616-GPU-enable-hack.patch This looks to specifically enable the GPU on H616 boards and is enabled for any build that passes the CONFIG_MACH_SUN50I_H616 option, which the Orange Pi Zero 3 configuration does (in the defconfig file). The hack is only a single call to a write function, but I am wondering if the h616 and h618 SoCs may differ enough (like the DRAM timing configuration) that this value needs to be configured specifically for h618 boards.. I will chase this up and see if I can find an answer. + /* enable GPU */ + writel(0, 0x7010254);

I started to investigate the display issue and why it's not producing anything. Looking at the Zero 2 configuration the HAS_VIDEO_OUTPUT has been set to 'no' and DEFAULT_CONSOLE is set to 'serial' which means it won't output anyway. Not sure if this is intentional in the Zero 2, I was wondering why the Zero 2 board didn't display anything when I tested Armbian on a Zero 2 board. I might contact that board maintainer and try and get some history to save myself some time researching. https://github.com/armbian/build/blob/main/config/boards/orangepizero2.conf#L9 I enabled these display options in the Zero 3 configuration I posted, but as mentioned, it doesn't appear to work. I confirmed in the boot configuration in the final image that these settings were added correctly, and console should be output to display (if it's there). If anyone has an Orange Pi SDK build (or DietPi) running, would be good to see an lsmod from there (if you have HDMI display working) to compare, otherwise I will start picking through what the Orange Pi SDK image build does to get the display working in that image, it may still need patching on edge because required changes aren't in mainline yet. In terms of getting it working for 6.1, I personally don't have any real motivation to get it working on a previous kernel, but can understand the benefits of having it connected to an LTS version. Will look at that as a lower priority, getting a working display is my focus now. I expect the same configuration that is posted above will work for 1GB/2GB/4GB boards, there only seems to be modifications in configuration for the 1.5GB variant.

Well sorry for the quick double post, I found a serial cable and can confirm that the Orange Pi Zero 3 image boots with the above configuration and works over serial cable (red blinking is disk IO of boot process). Stepped through the Armbian configuration, it's picked up the correct memory configuration (I only have 4G model to test). I have also confirmed that network (wired) works 'out of the box' and plugged into a network, got DHCP address.. all working without issues (not stress tested, but validated). root@orangepizero3:~# uname -a Linux orangepizero3 6.6.5-edge-sunxi64 #1 SMP Fri Dec 8 07:52:25 UTC 2023 aarch64 GNU/Linux root@orangepizero3:~# free total used free shared buff/cache available Mem: 4027112 251964 3623560 5500 292596 3775148 Swap: 2013552 0 2013552 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 sunxi_cedrus 49152 0 v4l2_mem2mem 28672 1 sunxi_cedrus videobuf2_dma_contig 20480 1 sunxi_cedrus videobuf2_memops 16384 1 videobuf2_dma_contig polyval_ce 12288 0 videobuf2_v4l2 20480 2 sunxi_cedrus,v4l2_mem2mem polyval_generic 12288 1 polyval_ce videodev 221184 3 sunxi_cedrus,videobuf2_v4l2,v4l2_mem2mem videobuf2_common 45056 5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_v4l2,v4l2_mem2mem,videobuf2_memops mc 57344 5 sunxi_cedrus,videodev,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem fuse 126976 1 dm_mod 131072 0 motorcomm 24576 1 dwmac_sun8i 24576 0 mdio_mux 12288 1 dwmac_sun8i Above is using bookworm: Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.6.5.img

So I feel I have made some progress but currently have very little to show for it. Sharing some of what I have tested here in the hopes that someone else can take a look and fill in any missing pieces. I have managed to get the following orangepizero conf building cleanly in Armbian using 'edge' (6.6.5) and 'current' (6.1.66) but unfortunately neither of the generated images boots. The 'edge' image shows a green LED with blinking red LED after about 10 seconds, but 'current' seem to be a non-starter. I have currently only tested both images with HDMI, so may just been a display configuration issue. I was going to post a link to a github repo, but decided it's probably just as easy to post the single config file here for discussion. I have added the following orangepi zero 3 config to my local copy of the current Armbian build framework. This file references the specific commit in mainline u-boot where the Orange Pi defconfig was merged (discussed above) and also references the Orange Pi defconfig. The build correctly downloads u-boot from mainline and finds the defconfig and builds cleanly (from what I can see). /build/config/boards/orangepizero3.conf # Allwinner H618 quad core 1GB/2GB/4GB RAM SoC WiFi SPI USB-C BOARD_NAME="Orange Pi Zero3" BOARDFAMILY="sun50iw9" BOARD_MAINTAINER="XXXX" BOOTCONFIG="orangepi_zero3_defconfig" BOOTSOURCE="https://github.com/u-boot/u-boot.git" BOOTBRANCH="commit:e9742cb67ffb174759c0536860fedf4c6a3dff82" DEFAULT_CONSOLE="both" HAS_VIDEO_OUTPUT="yes" SERIALCON="ttyS0" KERNEL_TARGET="current,edge" FORCE_BOOTSCRIPT_UPDATE="yes" There was also an issue with applying one of the sunxi patches with the 'edge' kernel, so I have renamed that patch for the time being as I haven't had a chance to dig too deeply into this, but it appears others have reported similar issues with the patch, and the patching issue doesn't look related to the above configuration. By looking at the ignored patch, it's primarily defconfig changes for DRAM timings, but doesn't include anything orangepizero specific. All the other patches in this directory appear to apply cleanly so haven't looked any closer at them. Renamed broken patch so Armbian ignores it: /boot/patch/u-boot/u-boot-sunxi/allwinner-adjust-default-dram-clockspeeds.patch -> /boot/patch/u-boot/u-boot-sunxi/allwinner-adjust-default-dram-clockspeeds.patch.ignore I will check the 'edge' image with a serial cable to see if it's producing anything while the lights are blinking, but keen to hear if anyone else has had success with this.

After reading this thread I spent some time trying to understand what would be required to get this board officially into Armbian (there is lots to read). I am very new to this project, but have been attempting to collate the information available and find out where the current gaps are. To that end, I had a look at the Orange Pi SDK which appears to be the source of the majority of the not-actually-armbian images mentioned and linked here, and the SDK itself is extensively documented by Orange Pi. http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_Zero_3#Linux_SDK.E2.80.94.E2.80.94orangepi-build_instruction This SDK uses what seems to be a heavily modified version of the armbian build tool/scripts. It successfully builds a u-boot image, and has a dtc/defconfig onfiguration in an Orange Pi hosted u-boot repo. Unfortunately the u-boot version they are using is fairly dated.. so my approach was: 1. Determine if configuration would work with u-boot mainline (rather than the Orange Pi repo) 2. Remove any other Orange Pi repo specific requirements in preference for upstream tools (compilers/tools) 3. Try and unpick the required elements from the build scripts and see if I can get them working with Armbian (a little bit off this step yet, but consider this aspirational) So with item 1. I moved the Orange Pi defconfig into the mainline repo and modified the Orange Pi SDK to build off mainline. After working through a few issues I determined that the configuration for the H616 board had changed (new options) that weren't in the old Orange Pi version of the repo, I made an issue here with some of the specifics (although this may not have been the correct place to raise it): https://github.com/orangepi-xunlong/u-boot-orangepi/issues/14#issue-2030521840 Note: Looking at the differences to what has been contributed below to the sunxi repo, and the information I was seeking. in the above thread. I think I was still miles off getting it working with my trial/error I also noticed in the mainline version of u-boot that the Orange Pi Zero 2 board configuration had been updated with these additional options, so I contacted the contributor that made the changes for the Pi Zero 2 in an attempt to find out how to get this information (I won't mention their name here to avoid them getting sent questions, but I am extremely grateful). They very gracefully provided advice on the where to find this information for sunxi boards: IRC: OFTC, #linux-sunxi) Mailing List: linux-sunxi@lists.linux.dev In a somewhat coincidental turn of events, they also advised that a patch had just been submitted to the mailing list to add mainline u-boot support for the Orange Pi Zero 3. https://patchwork.ozlabs.org/project/uboot/patch/20231207135240.2070795-1-andre.przywara@arm.com/ The defconfig is here (line from the above email), but please check the entire patch as several other files are also updated: https://source.denx.de/u-boot/custodians/u-boot-sunxi/-/blob/master/configs/orangepi_zero3_defconfig?ref_type=heads So with that in mind, my next step is to try using the Orange Pi SDK + u-boot mainline repository with the Orange Pi Zero 3 patch applied. One thing I have learnt starting this process is that there are many extremely talented individuals contributing every step of the way, and it's humbling to look through their code and contributions and see just how much work is involved! -edit- Good news, Orange Pi SDK + mainline u-boot with patch worked and built uboot + spl image cleanly (although haven't had a chance to test it yet).

Thanks for all your updates to date @ag123 (and others in the thread), I have several Orange Pi boards including the Zero 3, and have been following your updates on upstream progress here. I will check out the DietPi images you have linked and see how they go. Thanks again for all the information you have collated here.

Hi Julien, I suspect you are hitting the bug that I commented on in the following thread. There is a bug in the installer version on the current Odroid M1 download. When the installer lists potential target NVMe drives, unless that NVMe drive has a valid filesystem on it, it won't show up in the list (this is fixed in the upstream code, but a new build hasn't occurred to include this fix). The fix is to create a partition with an empty filesystem on the NVMe drive, it will then be detected by the installer. In my case, I just created a partition the full size of the NVMe and use mkfs.ext4, it was then detected by the Armbian installer running on the SD card, and worked as expected from then on (installing root on NVMe, leaving /boot on the SD card).

Hi everyone, New to the forum, so apologies if the questions are answered elsewhere, but please redirect me if they are. I have identified a bug in the `armbian-install` script in the current Bullseye Edge image (Dec 19,2022) that prevents it showing NVMe targets in the installation prompt if they don't have a valid filesystem on them. This appears to have been fixed on the 19th of December in this commit (the grep for filesystems was removed from the lsblk command that returns valid partitions). https://github.com/armbian/build/commit/893ed2347d97af574becf69dee1166a1bf933081#diff-8752ea87e0340f217187b70f7b08735d872a14c0467d02a6285222e594db3299L635-R635 I am not sure if it's a coincidence that these are the same date, but the Bullseye image downloaded today still has the older version of the script that includes the 'grep' for filesystems. I have a workaround for my immediate issue (mkfs.ext4 on the NVMe partition so the installer detects it), but thought this may be impacting other users of Odroid M1 as they are likely installing on the NVMe. If I need to raise this elsewhere, eg. github issue etc. please let me know the process. Thanks!