pixdrift Posted January 2 Posted January 2 4 minutes ago, Gunjan Gupta said: Looks ok, but its just a diff and is not in git format-patch format similar to other patches. Also instead of saying blocklist, it should be something like add h618 to matchlist Use ./compile BOARD=orangepizero3 BRANCH=current kernel-patch to create the patch 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. 0 Quote
iun cuim Posted January 2 Posted January 2 (edited) I also made a manjaro image for zero3 based on the warpme patches. If anyone wants to compare with armbian and use something for it, there is a link: https://drive.google.com/file/d/10z1Kq6_7NXE4p3n8QfV8MWFcKlicx_9t/view From the very beginning, many things will not work, you need to update the kernel with the command sudo pacman -U ./linux-blahblah.zst : https://drive.google.com/file/d/1Rv7NS364Pc8ZCgyEuN-nnwuI2lINR5W4/view?usp=sharing After the update the kernel mostly things works. For wifi to work, you additionally need to download firmware files. GTA Vice City (PC version) game video: https://drive.google.com/file/d/10WkmibRqYXEb6IzarZRU6FPXSl8BxT-c/view?usp=drive_link Edited January 2 by iun cuim 0 Quote
Gunjan Gupta Posted January 2 Posted January 2 @pixdriftLets just patch dts instead of patching driver. I think that is the better solution 0 Quote
pixdrift Posted January 2 Posted January 2 8 hours ago, Gunjan Gupta said: @pixdriftLets just patch dts instead of patching driver. I think that is the better solution 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. 0 Quote
Stephen Graf Posted January 3 Posted January 3 @Gunjan GuptaWould you please fit just one more small patch into some convenient dtsi. I2c is sort of half baked for i2c3, the only i2c brought out to the external headers. The correct pins are set aside but they are not referenced in the i2c3 definition and without that the port does not work. I have used armbian-config dtb edit to add the definitions and tested the port and it works. From sun50i-h616.dtsi, one can see the i2c pin definitions: i2c3_ph_pins: i2c3-ph-pins { pins = "PH4", "PH5"; function = "i2c3"; But there is no reference to them in the i2c3 definition: 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>; What needs to be added is : 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>; + pinctrl-names = "default"; + pinctrl-0 = <&i2c3_pins>; status = "disabled"; #address-cells = <1>; #size-cells = <0>; With the current state of patches I am not sure of where to put these two lines. 0 Quote
ALIGMSTEN Posted January 3 Posted January 3 On 1/2/2024 at 9:18 AM, pixdrift said: whoever wrote the original code should be commended Hello All, Good to see all the progress. I wrote and tested the dvfs code for zero2, however did not have enough time spare to optimize as would have liked. Was a bit surprised that it was also adopted by others including the Vendor. There are two ways to incorporate dvfs, the xlate method which I decided to eventually adapt, and v2 opp points. xlate is as example. v2 you can use in tri-state, which avoids the driver patching. I haven't had interest to examine the h618 soc, however am assuming that variants should be addressed as it is supposed to be h616 similar. 0 Quote
Gunjan Gupta Posted January 3 Posted January 3 8 minutes ago, ALIGMSTEN said: I wrote and tested the dvfs code for zero2, however did not have enough time spare to optimize as would have liked. Was a bit surprised that it was also adopted by others including the Vendor. Your patch seems to be base of https://lore.kernel.org/all/20231128005849.19044-1-andre.przywara@arm.com/ as well. Though there is no reference in the patch series that it came from your patch 0 Quote
ALIGMSTEN Posted January 3 Posted January 3 9 minutes ago, Gunjan Gupta said: Though there is no reference in the patch series that it came from your patch Oh well it was open source, would have liked to have had some discussions at the time to optimise though! 0 Quote
pixdrift Posted January 3 Posted January 3 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. 0 Quote
pixdrift Posted January 3 Posted January 3 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. 1 Quote
ag123 Posted January 4 Author Posted January 4 I made some progress to run armbian build *compile.sh* in a systemd-nspawn container https://gist.github.com/ag88/05245121cce37cb8f029424a20752e35 It did create the loop devices in systemd-nspawn, but it still fail subsequently in accessing the partitions in the loop device. -- I'd try out the test binaries from @pixdrift for the time being 0 Quote
pixdrift Posted January 4 Posted January 4 (edited) 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/ Edited February 2 by pixdrift 0 Quote
ag123 Posted January 4 Author Posted January 4 @pixdrift thanks, I tried PR6127_20240103_919ec9a62_Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.0-rc7.tar.xz from 2024-01-04 on a 2GB OrangePi Zero 3 board cpufreq-info works, thanks for the dts patches: armbian@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:85.58%, 600 MHz:1.60%, 792 MHz:0.08%, 1.01 GHz:0.26%, 1.20 GHz:0.22%, 1.51 GHz:12.26% (173) analyzing CPU 1: ... armbian@orangepizero3:~$ armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq Tcpu C.St. 18:13:16 1512 MHz 1.08 5% 1% 2% 0% 1% 0% 41.3 °C 0/5 18:13:21 480 MHz 1.08 0% 0% 0% 0% 0% 0% 41.3 °C 0/5 18:13:26 480 MHz 1.07 0% 0% 0% 0% 0% 0% 40.9 °C 0/5 other stuff looks good the login: ___ ____ _ _____ _____ / _ \| _ \(_) |__ /___ _ __ ___|___ / | | | | |_) | | / // _ \ '__/ _ \ |_ \ | |_| | __/| | / /| __/ | | (_) |__) | \___/|_| |_| /____\___|_| \___/____/ 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: 26% Up time: 3 min Memory usage: 7% of 1.94G IP: 192.168.1.173 CPU temp: 37°C Usage of /: 7% of 29G RX today: 72.6 MiB armbian@orangepizero3:~$ ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 02:00:6c:53:f7:f9 brd ff:ff:ff:ff:ff:ff 3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state DORMANT mode DORMANT group default qlen 1000 link/ether 80:a0:53:73:a3:89 brd ff:ff:ff:ff:ff:ff Ethernet / Wifi works as prior, only tested in console (e.g. serial) as well as ssh over ethernet. 0 Quote
pixdrift Posted January 4 Posted January 4 (edited) On 1/3/2024 at 2:44 PM, Stephen Graf said: With the current state of patches I am not sure of where to put these two lines. 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. Edited January 4 by pixdrift 0 Quote
pixdrift Posted January 4 Posted January 4 (edited) @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 Edited February 2 by pixdrift 0 Quote
Stephen Graf Posted January 4 Posted January 4 @pixdrift said 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. Yes it was a typo. Your patch should be correct. I would expect the zero2 would benefit with the same change. I will try to build and retest. 0 Quote
pixdrift Posted January 4 Posted January 4 4 hours ago, Stephen Graf said: I would expect the zero2 would benefit with the same change. I will try to build and retest. 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 0 Quote
Stephen Graf Posted January 4 Posted January 4 I just finished testing with the build you supplied and it worked as expected. I have a temperature & pressure sensor on an 12c device that I connect to the zero3 header and then read it with rust code. There are i2c tools installed on the image that you can use to interrogate the i2c system: root@orangepizero3:~# i2cdetect -l i2c-0 i2c mv64xxx_i2c adapter I2C adapter i2c-1 i2c DesignWare HDMI I2C adapter i2c-2 i2c mv64xxx_i2c adapter I2C adapter root@orangepizero3:~# i2cdetect 2 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-2. I will probe address range 0x08-0x77. Continue? [Y/n] y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- root@orangepizero3:~# I think there are 2 i2c systems used internally by the zero3. The i2c3 that we are working on became i2c-2 as enumerated by linux. My device shows up as address 38 on the scan. Thank you for your work adding the patch. 1 Quote
Stephen Graf Posted January 5 Posted January 5 @pixdrift On the i2c patch you enabled the device in the dts. Normally these devices are left disabled and I use armbian-config, system, hardware to enable the devices I require. However, this menu option is currently not working on my zero3. It just comes up with a blank list. Can you try it on a zero2? 0 Quote
pixdrift Posted January 5 Posted January 5 51 minutes ago, Stephen Graf said: @pixdrift On the i2c patch you enabled the device in the dts. 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 0 Quote
Stephen Graf Posted January 5 Posted January 5 The patch for i2c3 is fine. There is no need to change anything, although the armbian developers might want to leave i2c3 disabled. The armbian-config issue is a separate item. I just want you to look at the system-hardware item in armbian-config to see it there are any items listed. My zero3 list if blank. The armbian-config is a utility for a number of things and one is to enable and disable hardware items. root@orangepizero3:~# armbian-config then System then Hardware On the Zunlong image all the devices, spi, 12c, serial etc are listed as they should be, even when they are disabled in the dtb. I suspect armbian-config does not know about H618 and is not reading the dtb. The dtb for zero3 in Zunlong is labeled with H616!? 0 Quote
Gunjan Gupta Posted January 5 Posted January 5 Its possible armbian-config might be looking for files starting with sun50i-h618 as that is the compatible string in zero3.dts. Try adding symlinks or renaming h616 overlay files present in /boot/dtb/overlay and see if armbian-config starts listing those files 0 Quote
Stephen Graf Posted January 5 Posted January 5 The overlay_prefix in armbianEnv.txt is not defined so I added overlay_prefix=sun50i-h616. Then I get: I was hoping that i2c3 would be there, but only the following exist. Who decides what goes into the overlays? root@orangepizero3:/boot# ls -al dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616* -rwxr-xr-x 1 root root 4203 Jan 4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-fixup.scr -rwxr-xr-x 1 root root 268 Jan 4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-ir.dtbo -rwxr-xr-x 1 root root 512 Jan 4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-light.dtbo -rwxr-xr-x 1 root root 339 Jan 4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-mcp2515.dtbo -rwxr-xr-x 1 root root 661 Jan 4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-spidev0_0.dtbo -rwxr-xr-x 1 root root 661 Jan 4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-spidev1_0.dtbo -rwxr-xr-x 1 root root 661 Jan 4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-spidev1_1.dtbo -rwxr-xr-x 1 root root 661 Jan 4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-spidev1_2.dtbo -rwxr-xr-x 1 root root 808 Jan 4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-spi-spidev.dtbo -rwxr-xr-x 1 root root 616 Jan 4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-tft35_spi.dtbo -rwxr-xr-x 1 root root 272 Jan 4 13:23 dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-ws2812.dtbo 0 Quote
pixdrift Posted January 5 Posted January 5 7 minutes ago, Stephen Graf said: The overlay_prefix in armbianEnv.txt is not defined so I added overlay_prefix=sun50i-h616. 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. 0 Quote
pixdrift Posted January 5 Posted January 5 (edited) 5 hours ago, aleda said: will this work for the opi2w 4gb? 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 Edited January 5 by pixdrift 0 Quote
Gunjan Gupta Posted January 5 Posted January 5 6 minutes ago, pixdrift said: How is ArmbianEnv.txt generated? Its generated based on the options specified in the board config file. You can add OVERLAY_PREFIX=sun50i-h616 in orangepizero3.conf and that should get replicated in armbianEnv.txt in your next build 0 Quote
Gunjan Gupta Posted January 5 Posted January 5 As h616 and h618 are suppose to be pin compatible, same overlays should work between the same 1 Quote
pixdrift Posted January 5 Posted January 5 (edited) 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>; Edited January 5 by pixdrift 0 Quote
pixdrift Posted January 5 Posted January 5 4 hours ago, Gunjan Gupta said: Its generated based on the options specified in the board config file. You can add OVERLAY_PREFIX=sun50i-h616 in orangepizero3.conf and that should get replicated in armbianEnv.txt in your next build 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? 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.