pixdrift

I notice that the orangepizero2.conf file doesn't include OVERLAY_PREFIX, is this because the board defined in the dts/dtb already correctly matches so doesn't need explicit overwrite?

Interested in some feedback here. As the i2c3 component is confirmed working, and it's the same for all h616, I was considering adding the following lines to the sun50i-h616.dtsi pinctrl-names = "default"; pinctrl-0 = <&i2c3_ph_pins>; ...and then for zero2 and zero3 (or using the zero dtsi) just enabling the i2c3 components with status = "okay" at the board level But I have a concern that there are several boards including the sun50i-h616.dtsi file, and not sure if this change is going to impact these boards. So interested in feedback.. perhaps @Gunjan Gupta you can advise on what level (file) I should add these two lines?, then I will update the patch before the PR. pinctrl-names = "default"; pinctrl-0 = <&i2c3_ph_pins>;

Hi @aleda, welcome to the forum. Not yet, we haven't started discussing/targeting the zero2w in this thread yet, although a lot of the work being done here for zero2 and zero3 will benefit the zero2w and likely make the process of adding the zero2w straightforward. I have recently purchased a zero2w myself, so it's good to know there are other people in this thread potentially available for testing if/when we do add the board. @Gunjan Gupta did some work in his own branch to test/validate the zero2w, you could potentially build off this branch while you wait, but this isn't supported in any way. https://github.com/viraniac/armbian_build/tree/zero2w

Thanks for this clarification @Stephen Graf, once again this is something I haven't seen before being new to Armbian. This raises an interesting point because there is going to be crossover here, so anything that is shared between 616/618 should probably be 616, and then specific 618 configuration with 618.. so the prefix could technically be 'overlay_prefix=sun50i-h61'.. but this doesn't accomodate configuration that is in h616 that may be dropped from h618. Should we just replicate everything into a new set of files for h618? Is everything listed for h616 there valid h618? How is ArmbianEnv.txt generated? I am happy to add a patch to fix this for zero3 so at least we're getting some kind of menu out of the box.

My understanding is that this just includes it in the kernel device tree, but I may be wrong, I am fairly new to this. It would be quick to fork my repo, change the patch file to remove the status=okay, or just replace it was status=disabled and rebuild and see if that resolves your issue? I can take a look on zero2, but as I mentioned, I would need hardware to test no? otherwise I should be expecting a blank list

That's sounds good, I think the challenge is going to be getting the zero2 changes validated. That being said, as I am not too familiar with i2c because I use these boards primarily as servers for varying purposes, would you be able to recommend some tests I could do to validate the i2c changes myself (and other GPIO tests you are doing). I am looking for both hardware and software (code sample) recommendations for the testing. Happy to buy hardware components so I can validate these changes too. I have posted a link to a build with the i2c3 changes above for the orangepizero3 to avoid you needing to rebuild, but all good if you want to build it

@Stephen Graf this has what I think should fix it, please build using edge and let me know https://github.com/pixdrift/armbian_build/tree/zero3_i2c3 I decided to try and patch the zero3 dts to avoid potential impacts to other boards (for now), the patch file can be found in the repo under the zero3_i2c3 branch. arm64-dts-sun50i-h618-orangepi-zero3-Enable-i2c3 -edit- It compiled cleanly, there is a test build here if you want to use that: https://armdev.pixeldrift.net/orangepi/zero3/Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.0-rc7.i2c3.test.tar.xz

Hi @Stephen Graf, sorry for the slow follow up. In the edge kernel, I found that this patch appears to add the i2c3 configuration for h6: arm64-dts-allwinner-h6-Add-AC200-EPHY-nodes.patch It adds it to the following h6 dtsi /arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi But the h616 and h618 boards don't inherit this h6 dtsi.. it looks like the configuration is set for the zero3 in the sun50i-h616.dtsi include file here: /arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi Here is a rough diagram I put in Graphviz, sorry for the size: That block in /arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi looks like the following post patching i2c3: i2c@5002c00 { compatible = "allwinner,sun50i-h616-i2c", "allwinner,sun8i-v536-i2c", "allwinner,sun6i-a31-i2c"; reg = <0x05002c00 0x400>; interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_I2C3>; resets = <&ccu RST_BUS_I2C3>; status = "disabled"; #address-cells = <1>; #size-cells = <0>; }; I will write a quick patch for you, and we can see if that fixes it, then I can figure out how to graft it in more formally once you've tested it . @Stephen Graf looking at your code block, the reference should be 'i2c3_ph_pins', not 'i2c3_pins' as 'i2c3_pins' isn't defined in the h616.dtsi, can you confirm tha makes sense and it was a typo? I notice the h6 dtsi doesn't have 'ph' in the name.

The latest mainline builds after PR6127 merge are up, CLI only, if people want XFCE please let me know. This fixes CPU frequency scaling on the Zero3. https://armdev.pixeldrift.net/orangepi/zero2/pr_testing/ https://armdev.pixeldrift.net/orangepi/zero3/pr_testing/

For those that may just be following this thread and not the GitHub repository, my changes for CPU Frequency on the zero3 were merged into the main Armbian Build repository last night, so rebuilding from armbian/build:main will add working CPU Frequency on zero3 I will build images at this PR for people to use (will let you know when they are up). https://github.com/armbian/build/pull/6127 I will take a look at the I2C issue you've raised next @Stephen Graf as it looks like a fairly quick fix.

Just a note for anyone that was using my armbian repository, I have re-created it to re-establish the fork relationship with the mainline armbian project, as it was becoming difficult to track changes derived off @Gunjan Gupta's repo (ie. I was two steps away). Apologies if this causes any issues, I am hoping now I will have some consistency and can better contribute to the mainline project.

Can you provide more specific details on why you believe this is better? is there a policy in Armbian or something I can refer to to determine how it should be handled? My concern with modifying the .dts is that it feels like a 'step backwards' as we are essentially reverting a change that should be there, where as the change to the driver is moving to a more likely target state for that driver (but I can only speculate). I appreciate the driver is probably more likely to change in mainline, which may deprecate the patch more quickly. Would you be able to give me a run through of your full patch generation workflow for Armbian so I can generate a patch that meets PR requirements (or link to a doc)? Do you checkout the full kernel source and generate the patch there? or do you pull the generated/patched kernel source out of Armbian build into a git repository and then modify and generate from there? I have my own workflows for these things, but it's a little obtuse when applied to Armbian due to the amount of patching/changes that occur during the build process. My current patch generation workflow for Armbian is to pull resultant files from the build cache (after a build), modify them and generate patches from there using git diff.

Thanks for the feedback @Gunjan Gupta. The patch was generated by git diff, if it wasn't I don't think the Armbian patching utility would parse it (ie. doesn't support straight diff). The patch is called blocklist because that is what is being updated/changed, but sure, that can change, it's only a label. Not following on what the ./compile command is going to do for me? am I providing my patch to it? where am I putting the patch for that command to 'work'? I will take a look when I get some more time, cheers.

I have come up with a cleaner way to patch in CPU Frequency support in for the zero3. Essentially it adds the h618 device to the compatibility list, then maps the h618 configuration to the same as the h616. This was the least invasive method to get support (two lines changed total in two driver source files) https://github.com/pixdrift/armbian_build/commit/c9fdd448d729406f651131a428fa0027543a884a I am considering raising a PR back to Armbian mainline for this after I also get a working patch for the 'current' kernel (should be roughly the same). To test this CPU Frequency patch for the zero3, you can build off the mainline_cpufreq_driver branch in my repo here: https://github.com/pixdrift/armbian_build/tree/mainline_cpufreq_driver

As suspected the hack to the zero3.dts files fixed CPU Scaling on the zero3. I applied it to your mainline patches @Gunjan Gupta rather than my forked zero3 repo. This basically ensures the CPU scaling code executes because it passes the compatibility check which checks for h6 and h616 (but not h618 currently). https://github.com/viraniac/armbian_build/compare/main...pixdrift:armbian_build:mainline_cpufreq This leaves me in a weird spot, there are a few options here. I looked at the code and the h618 compatibility configuration defined in the zero3.dts doesn't appear to be used or referenced anywhere else in the code, so there is no real harm in setting it to h616. That being said, in the future this may change and trip us up. I can replicate the configuration from h616 in the code for h618, but that feels like unnecessary duplication, so another method would potentially be to redefine the h616 configuration as h61X and reference it for both boards in the CPU Frequency code. So options are: 1. Merge as is with h616 definition in zero3.dts and deal with the consequences when h618 specific code turns up in the kernel 2. Create kernel patch to also add h618 definitions replicating the h616 definitions so both are defined and separate 3. Modify existing kernel patch to change CPU h616 configuration to h61x, and reference that from both h616 and h618 compatible boards I haven't uploaded any OS images using the above patch, but if people would like it for testing etc. I can upload it, or you can build directly off my mainline_cpufreq branch in my github repository. I have checked this fairly thoroughly with some background load tests and the scaling up/down was all working really well, so whoever wrote the original code should be commended. Here is the output from the board with the above patch applied. ___ ____ _ _____ _____ / _ \| _ \(_) |__ /___ _ __ ___|___ / | | | | |_) | | / // _ \ '__/ _ \ |_ \ | |_| | __/| | / /| __/ | | (_) |__) | \___/|_| |_| /____\___|_| \___/____/ Welcome to Armbian-unofficial 24.2.0-trunk Bookworm with bleeding edge Linux 6.7.0-rc7-edge-sunxi64 No end-user support: built from trunk System load: 29% Up time: 1:46 Memory usage: 5% of 3.84G IP: XXX.XXX.XXX.XXX CPU temp: 50°C Usage of /: 3% of 58G RX today: 1.9 MiB pixdrift@orangepizero3:~$ 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 480 MHz (asserted by call to hardware). cpufreq stats: 480 MHz:64.13%, 600 MHz:2.89%, 792 MHz:1.56%, 1.01 GHz:0.00%, 1.20 GHz:0.00%, 1.51 GHz:31.42% (2650) 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 480 MHz (asserted by call to hardware). cpufreq stats: 480 MHz:64.13%, 600 MHz:2.89%, 792 MHz:1.56%, 1.01 GHz:0.00%, 1.20 GHz:0.00%, 1.51 GHz:31.42% (2650) 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 480 MHz (asserted by call to hardware). cpufreq stats: 480 MHz:64.13%, 600 MHz:2.89%, 792 MHz:1.56%, 1.01 GHz:0.00%, 1.20 GHz:0.00%, 1.51 GHz:31.42% (2650) 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 480 MHz (asserted by call to hardware). cpufreq stats: 480 MHz:64.13%, 600 MHz:2.89%, 792 MHz:1.56%, 1.01 GHz:0.00%, 1.20 GHz:0.00%, 1.51 GHz:31.42% (2650)

Feel free to add a patch and test it out. Its a single line change after all. Yeah sorry, that was my plan, I was just sharing the theory of why it may not be working based on some investigation. I am low on time at the moment too, but as you mention, it's a quick one to validate and I will give feedback on results when I have a minute, cheers

@Gunjan Gupta I think what is significant about the feedback from @fizban is that they are comparing the build from my opizero3 branch, to the mainline PR6116 build and seeing a difference. The BT fixed image that @fizban is referring to is built from here https://github.com/pixdrift/armbian_build/tree/zero3 I would expect the patches to provide similar outcomes (as I think they are essentially the same patches?). Regarding CPU Frequency on the zero3, I am more convinced the code that branches based on H616/H618 I mentioned earlier in the thread is causing the issues. This change here in the warpme repo changes the zero3 compatibility configuration to 616 from 618 in the CPU frequency patch. I am not sure if this is the best approach (I think I prefer to add logic for 618 to the CPU Frequency code, or change the logic slightly), but it means the CPU Frequency code works without modification for the zero3 as it changes the code path if it's 616 to essentially work like the zero2. (my theory) - compatible = "xunlong,orangepi-zero3", "allwinner,sun50i-h618"; + compatible = "xunlong,orangepi-zero3", "allwinner,sun50i-h616"; https://github.com/warpme/minimyth2/blob/67c1dec6e93743c8f4de1d5299d06f4036a8ea2b/script/kernel/linux-6.6/files/0631-arm64-dts-allwinner-h616-OrangePI-Zero23-enable-ths-hdmi-audio.patch#L215-L216

@Gunjan Gupta There are minor glitches that I would characterise as artefacting. It isn't hard to reproduce, I could see it when XFCE first launched and when I select the drop down menu and open a terminal, I get glitching around where the terminal window draws. It is like a 'flash' of different bits and pieces of window components etc. in the middle of the screen, almost like video RAM isn't refreshed before being drawn or something. I have only tested this on the Zero2, I can do a comparison with the Zero3 XFCE PR6116 image here and confirm it's not anything to do with hardware. I would still be interested if you could test it on your Zero2, because it may just be a hardware issue with my device?

Welcome to the forum @johndo100, sorry I missed this post. Which board and configuration are you using? If it's a Zero2 or Zero3, you will now be able to use the main Armbian repository as @Gunjan Gupta's latest changes (viraniac repository) have been merged.

Welcome to the forum @jokakilla, @jiggle24, and @Sean Perez and Happy NY! @jokakilla thanks for this feedback, it's great information and how I generally use my SBCs too (small servers with no X windows). Great to hear it's been stable for you.. one thing I haven't done much of is run images for much longer than testing components work, so this is good information @jiggle24, great work getting you own image built if you're new to all this!. Are you able to provide some more details on which github repository you built from specifically? (ie. repository and commit id), this is interesting feedback about the NIC, I haven't seen any issues with the NIC myself except for the initial issue with speed which I thought was resolved with a patch, so if you can let us know the specifics and perhaps provide a reproducer (steps to reproduce) it would help. Also, try with different cable + network configuration perhaps to rule out hardware issues unrelated to the SBC? Are you able to test the network with the PR6116 build I posted from @Gunjan Gupta and see if it has the same network issue? https://armdev.pixeldrift.net/orangepi/zero3/pr_testing/PR6116_20231230_8504bd650_Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.0-rc7_xfce_desktop.tar.xz @fizban thanks for that feedback. It does sound like a bad write to the SD card, and glad to hear a re-image of the card resolved it. I use a few different methods to write my images, but have ended up using balenaEtcher as my primary tool now as it also verifies the image after writing. Great to hear you got it working, and let us know if you come across any other issues. Hi @Sean Perez, thanks for the long post. @Gunjan Gupta are across all these sources and the requirements and differences to build zero2, zero3 and zero2w. This thread is more around Armbian specifics than just getting a working image, ie. the xunlog images exist, but this thread is about building working Aembian images and testing these images specifically. This includes merging the configuration from multiple different sources (patches, other repositories, and work from various communities) into Armbian so it works correctly for all the H61* boards as well. @Gunjan Gupta did some earlier work to get the zero2w working in Armbian and that is available in his branch here and may provide some additional insight: https://github.com/viraniac/armbian_build/tree/zero2w This is the work I am discussing merging, as it's known working with Armbian, and the H618 is shared by the zero3 and the pattern used for zero2/zero3 @Gunjan Gupta has used reduces the rework for some of the shared components and will benefit the Armbian project when more H618 boards come onto the market as @Gunjan Gupta has mentioned. I assume from your post you have a zero2w? One of the challenges we have had is that no one has had zero2w hardware to test, but I bought one over the break (with an expansion board) so will look at it more closely now I can actually test the images. My zero2w is still sealed as I have been keen to work through zero2 and zero3 issues while @Gunjan Gupta is merging. We may need a new thread for zero2w board specifically.

Going through your patch set in GitHub on the zero2w branch, it looks fairly straightforward, but I think I would prefer that it inherits configuration from the shared orangepi zero dtsi now that it has matured with your latest updates, similar to how zero2 and zero3 currently are so I may move it in a PR, can you see any reason not to do this considering it's H618 based and shares some commonality? On a similar note, I think that dtsi is named fairly poorly (this is a kernel issue I guess) because the orangepizero device (not 2 or 3, the original) doesn't really share any commonality and it looks like the dtsi is for that Another update @Gunjan Gupta.. I tested your PR6116 build on the Zero 2 and video is working but there is still some glitches in the display, but it does work. @Stephen Graf good question about zram/zswap.. I will dig a little deeper but not sure on how modular turning on features are like this (I have seen feedback about Armbian mentioning similar issues of configurability). I had a similar experience to you on the Zero2, as it's only 1G of RAM and quickly OOM'd / locked up in testing with XFCE/desktop. I really wonder if MicroSD with a low kernel swapiness value configured is still as much of an issue as it was originally when people started using SBCs and were concerned about wear and premature memory card failure?

@Gunjan Gupta with key pieces going in to the orange pi zero shared config, it may be a good time to add your zero2w patches? I notice u-boot still lacks an entry for zero2w, and there are some minor differences with zero3, but now that I have the zero2w hardware I am happy to test/iterate and provide feedback with you on a PR.

Builds for PR6116 from @Gunjan Gupta are now up, but this has been merged into mainline now I see. Either way, you can provide feedback on the current status of Zero2 / Zero3 in Armbian with these images. Note: CPU Frequency not working in zero3 is a known issue, as is load average due to the WiFi driver. https://armdev.pixeldrift.net/orangepi/zero2/pr_testing/ https://armdev.pixeldrift.net/orangepi/zero3/pr_testing/

@Gunjan Gupta Checked this on zero2 and Plymouth looks great (perfect), but XFCE is unfortunately all over the place. As you mention, I get the top menu in XFCE, and I appear to have mouse input because parts of the display flicker and menus open, but I can't see the cursor. Regularly the screen fills with a single block colour eg. red/grey (full screen).

Sorry, I should clarify that.. CLI only.. did you want me to test XFCE on bookworm edge and see if I get the same half screen issue as your testing?