Jump to content

Orange Pi Zero 3

ag123

By ag123
in Allwinner sunxi

 Share

Recommended Posts

Gunjan Gupta

Gunjan Gupta

Posted
Posted
21 minutes ago, pixdrift said:

Is your patch for zero 2 that I just tested the same as what you have in zero 2w?

 

Its same, but is in different file. The changes that you tested on zero2 impacts both zero2 and zero3. If you use the edge kernel deb file from that build on zero3, wifi will work on zero3 as well.

0
ag123

ag123

Posted
  • Author
Posted

have been caught out in other matters hence have not caught up with the progress.

as for the Wifi driver with a load of 1, I'd think it is partly a problem in the design of the driver. Which practically means it may take a re-write of the driver at least those parts that causes it to do away with the constant load of 1.

But guess is that rather then being 'event' or 'interrupt' driven, it resorts to polling lets just say go into an infinite while loop doing the poll e.g. 

while(pin_has_not_changed());

 

that in itself may be good enough to keep it at a load of 1, but that I'm not sure if that is after all a possible cause.

 

note that those codes are actually *spinlocks*

https://en.wikipedia.org/wiki/Spinlock

which may not necessarily cause a load. But that indefinite spinlock say monitors a change in state of a pin / bit can be trouble.

the alternatives are to place delays between the polls or switch to an event or interrupt driven design.

 

as in your post, i'm not too sure if the codes literally disabled interrupts while staying in an indefinite spinlock, i.e. it goes in a perpetual busy loop and cannot be interrupted. that is really bad design.

 

I think interrupts is another thing that is poorly documented for these SOCs, and the devices.

 

for the time being, I think we'd 'ignore' it, it is good enough that 'it works' for a start

 

0
pixdrift

pixdrift

Posted
Posted
22 minutes ago, Stephen Graf said:

I have been able to use @Gunjan Gupta repository to build the wifi changes for orangepi zero3.  It works on both 2.4 and 5Ghz bands. I am also experiencing the higher load reported by @pixdrift.


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.

1
pixdrift

pixdrift

Posted
Posted (edited)

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>;
};

 

Edited by pixdrift
0
pixdrift

pixdrift

Posted
Posted (edited)
8 hours ago, Stephen Graf said:

The comment in mmc0 is in the original dts from linux and has not caused any problems that I know of so far.

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)

 

Edited by pixdrift
0
ag123

ag123

Posted
  • Author
Posted

@pixdrift yes dtsi are dts includes while dts alone are device tree source.

and i think dts would override the includes

e.g. dtsi can have a status = "disabled" while dts have a status = "okay"

https://elinux.org/Device_Tree_Linux#disabled_nodes

but i think it is probably unnecessary to include the full template if it is defined in the include

 

I think after it is compiled into the binary using dtc , the resulting dtb file would be the net single definitions

0
pixdrift

pixdrift

Posted
Posted (edited)

I moved my Armbian build setup to an M2.. and it's much quicker to iterate now!
 

It only needed to be included in the dtsi. I think I will also attempt to move the HDMI and USB configuration back up into the sun50i-h616-orangepi-zero.dtsi file (only) as this is then common to both zero2 and zero3 and will remove the double handling and add zero2 HDMI support for free.


Everything now working together, I have built the following image if people want to test (THAT HAS NO WARRANTY WHATSOEVER!, USE AT YOUR OWN RISK). Please provide any feedback here (even if it's "works for me", and please include any details on your device etc.)

https://armdev.pixeldrift.net/orangepi/zero3/Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.6.4.everything.tar.xz

What _should_ be working:

- HDMI video output

- Gigabit wired networking
- WiFi (with the known load issue with the driver)
- USB ports on the expansion board

 

What may not be working (need ways to test/validate this):
GPIO
IR Receier

Anything to do with sound.. haven't looked at this yet
 

I will update the GitHub fork I have for the zero3 with the latest wifi patch and post a link soon (want to clean it up a little)
 

Thanks to @Stephen Graf and @wast3d55 for their assistance in testing different parts of the image, and for their detailed feedback. Thanks to everyone else in this thread that has helped me get to this stage, it's been quite the learning experience.. and appreciate all the assistance I have received so far :)

Edited by pixdrift
0
Gunjan Gupta

Gunjan Gupta

Posted
Posted
8 hours ago, pixdrift said:

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

Look at the path of the patch and you will understand why. In the PR I have patched both 6.1 and 6.6 kernel. In 6.1 kernel, there is no sun50i-h616-orangepi-zero.dtsi and hence changes were needed in sun50i-h616-orangepi-zero2.dts. However, as 6.6 kernel has sun50i-h616-orangepi-zero.dtsi, changes were done in the same.

1
pixdrift

pixdrift

Posted
Posted (edited)

I have updated the Zero 3 image with a few minor updates

1. The build now uses the u-boot upstream repository tag v2024.01-rc5 instead of the specific commit for the merge of the zero3 defconfig
2. The default configuration now includes the bluetooth tools installation to match zero2 in mainline armbian repository (if someone could test bluetooth and provide feedback it would be appreciated)

3. Kernel bumped from 6.6.4 to 6.6.7 and all patches apply cleanly and build works as expected (and CLI bookworm version has been tested).

I have built some new images (bookworm cli and xfce) with this configuration using 6.6.7 here that you are welcome to use at your own risk :)
https://armdev.pixeldrift.net/orangepi/zero3/
 

Source repo with the changes is here, use zero3 branch for latest stable of these changes.. I will try and make sure that this branch remains deployable :)

https://github.com/pixdrift/armbian_build/tree/zero3
 

I think the next step is really to look at getting Zero 3 into the mainline Armbian repository, even if it's in a reduced state of configuration due to patch issues.. this would at least set the ground work for when the components included in these builds mature. @Gunjan Gupta as you have been through this before for other boards, I was hoping to get some of your time to assist (I will see how far I get first :) )



Speaking of which, @Gunjan Gupta I had a quick look at adding HDMI for the Zero 2 (to the main Armbian repo, not your fork) based off a conversation you had in another thread, but unfortunately I am having issues with the HDMI patch when adding it to the main branch in the armbian repo (fails to build/patch). Have you had any success building with this patch on the current main Armbian branch? I was going to have a closer look at it tonight, but thought I'd ask if you had already looked at it.
 

Failing patch is the main HDMI driver patch:
drivers-wip-H616-hdmi-video-output
 

Edited by pixdrift
1
Gunjan Gupta

Gunjan Gupta

Posted
Posted
28 minutes ago, pixdrift said:

Speaking of which, @Gunjan Gupta I had a quick look at adding HDMI for the Zero 2 (to the main Armbian repo, not your fork) based off a conversation you had in another thread, but unfortunately I am having issues with the HDMI patch when adding it to the main branch in the armbian repo (fails to build/patch). Have you had any success building with this patch on the current main Armbian branch? I was going to have a closer look at it tonight, but thought I'd ask if you had already looked at it.
 

There are five different patches that are imported from megous kernel tree (xff.cz) that conflicts with hdmi patch. The hdmi patch has to be rewritten to fix the same. I haven't started working on it yet, but I will do it soon. Most likely within next 2 weeks window as I would be bumping the allwinner kernel versions. Legacy kernel will be moved o 6.1, current to 6.6 and edge kernel to 6.7

2
Gunjan Gupta

Gunjan Gupta

Posted
Posted
36 minutes ago, pixdrift said:

2. The default configuration now includes the bluetooth tools installation to match zero2 in mainline armbian repository (if someone could test bluetooth and provide feedback it would be appreciated)

 

Bluetooth is not going to work. Its currently broken in zero2 as well. The kernel has the required driver, but the hciattach binary and corresponding service file for the same is missing. I am going to create a extension for uwe5622 wireless module that should make it easy to set this thing in the future

2
Benedito Portela

Benedito Portela

Posted
Posted

Hi, I already use tvbox with rk3228 chipset , and now, i buyed a Orange pi zero 3, arrived yesterday, i make a card with "Armbian_23.08.0-trunk_Orangepizero3_bookworm_current_6.1.31-1GB-2GB.img.xz", this work, i don't have MicroHDMI cable, i use by SSH, I need use Debian Buster, i did image with "armbian_build-0f9820ff2238ab15fdbfef9adfefca47b031a757.zip" it's work but no audio driver ! Alsamixer don't open, no sound! The audio driver only work in last debian version? This board is new, debian buster can install audio driver? 

Thank you!

0
pixdrift

pixdrift

Posted
Posted (edited)
10 hours ago, Gunjan Gupta said:

There are five different patches that are imported from megous kernel tree (xff.cz) that conflicts with hdmi patch. The hdmi patch has to be rewritten to fix the same. I haven't started working on it yet, but I will do it soon. Most likely within next 2 weeks window as I would be bumping the allwinner kernel versions. Legacy kernel will be moved o 6.1, current to 6.6 and edge kernel to 6.7


Thanks. I did see these patches were patching the same file and likely causing the conflict, I wasn't aware that megous directory refereed to a different kernel tree, I will go read up on that, thanks for the information. The hdmi patch only has a couple of hunks that fail, I will try and find some time to take a closer look too... I didn't want to start unpicking the patching failure if I was missing something obvious :)
 

10 hours ago, Gunjan Gupta said:

Bluetooth is not going to work. Its currently broken in zero2 as well. The kernel has the required driver, but the hciattach binary and corresponding service file for the same is missing. I am going to create a extension for uwe5622 wireless module that should make it easy to set this thing in the future


Ahh, this is good to know, thanks again for the information :)

Edited by pixdrift
0
pixdrift

pixdrift

Posted
Posted (edited)
4 hours ago, Benedito Portela said:

Hi, I already use tvbox with rk3228 chipset , and now, i buyed a Orange pi zero 3, arrived yesterday, i make a card with "Armbian_23.08.0-trunk_Orangepizero3_bookworm_current_6.1.31-1GB-2GB.img.xz", this work, i don't have MicroHDMI cable, i use by SSH, I need use Debian Buster, i did image with "armbian_build-0f9820ff2238ab15fdbfef9adfefca47b031a757.zip" it's work but no audio driver ! Alsamixer don't open, no sound! The audio driver only work in last debian version? This board is new, debian buster can install audio driver? 

Thank you!


Unfortunately these images aren't from Armbian, or related to this thread so I think your best option for support is to raise this request on the site that you downloaded these images from.

Yes this board is new, and as a result it's not fully supported so not all components are currently working.

Edited by pixdrift
2
ag123

ag123

Posted
  • Author
Posted

@pixdrift

Thanks, I tried:

https://rpmbuild.pixeldrift.net/armbian/orangepi/zero3/

the file from 2023-12-17 22:14 427M

https://rpmbuild.pixeldrift.net/armbian/orangepi/zero3/Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.6.4.everything.tar.xz

it boots to the prompt (monitored from serial console) and I've got both ethernet and wifi up. 5ghz

I got a throughput at about 90 Mbps running hostapd on OrangePi Z3 this armbian build as a WiFI hotspot.

 

The hostapd.conf is like such:

https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3

I found out something about selecting frequencies at 5ghz:

first run sudo iw list, it'd give a pretty big report with in addition frequencies at 2.4ghz and 5ghz, the available channels are given in [] (square brackets).

selecting a channel in the [] (square brackets) do work in hostapd.conf

 

Ethernet is running at 100 Mbps partly due to my upstream hub i'd guess, but otherwise, network seemed good both ethernet and wifi.

I'd think if you have ethernet at 1 Gbps, the wifi hotspot can operate at throughput higher than 100 Mbps.

I've not tested other stuff (display etc).

 

Need to work on my own build environment as well, to fix it so that i can build it from source.

 

a small blurb though, it seemed the cpu-frequency drivers are not built into the kernel? 

root@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:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 4294.55 ms.
analyzing CPU 1:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 4294.55 ms.
analyzing CPU 2:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 4294.55 ms.
analyzing CPU 3:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 4294.55 ms.

 

 

0
pixdrift

pixdrift

Posted
Posted (edited)
23 hours ago, Gunjan Gupta said:

There are five different patches that are imported from megous kernel tree (xff.cz) that conflicts with hdmi patch. The hdmi patch has to be rewritten to fix the same. I haven't started working on it yet, but I will do it soon. Most likely within next 2 weeks window as I would be bumping the allwinner kernel versions. Legacy kernel will be moved o 6.1, current to 6.6 and edge kernel to 6.7


I started going through this patch and updated the failed hunks, and managed to resolve all of them except the failures in sun8i_ui_layer.c as it appears to have changed significantly. Not sure how to approach that. I can share my diff to the patch if you're interested (to save some work), but unfortunately I think sun8i_ui_layer.c fixes will need significant work (with understanding of the code base / patches) to resolve... which is beyond me currently. :unsure:

Edited by pixdrift
0
pixdrift

pixdrift

Posted
Posted (edited)
3 hours ago, ag123 said:

a small blurb though, it seemed the cpu-frequency drivers are not built into the kernel?


Thanks for the feedback.

This is interesting, looking at the kernel config for the build, the following is configured, and I assumed this is correct for this board.

If anyone has any feedback/advice on this it would be appreciated.. happy to update the image if we can find a fix. I will do some reading myself :)
  

  │ Symbol: ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM [=y]                                                                                                       │
  │ Type  : tristate                                                                                                                                      │
  │ Defined at drivers/cpufreq/Kconfig.arm:32                                                                                                             │
  │   Prompt: Allwinner nvmem based SUN50I CPUFreq driver                                                                                                 │
  │   Depends on: CPU_FREQ [=y] && (ARM || ARM64 [=y]) && ARCH_SUNXI [=y] && NVMEM_SUNXI_SID [=y]                                                         │
  │   Location:                                                                                                                                           │
  │     -> CPU Power Management                                                                                                                           │
  │       -> CPU Frequency scaling                                                                                                                        │
  │         -> CPU Frequency scaling (CPU_FREQ [=y])                                                                                                      │
  │ (3)       -> Allwinner nvmem based SUN50I CPUFreq driver (ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM [=y])                                                    │
  │ Selects: PM_OPP [=y]


-edit-
 

Your output appears to be an improvement over the current state of the Zero2 (my recent build from Armbian main branch at least).
 

When I run the cpufreq-info command, the Zero2 appears to lock up and never recover 

  ___  ____  _   _____             ____
 / _ \|  _ \(_) |__  /___ _ __ ___|___ \
| | | | |_) | |   / // _ \ '__/ _ \ __) |
| |_| |  __/| |  / /|  __/ | | (_) / __/
 \___/|_|   |_| /____\___|_|  \___/_____|

Welcome to Armbian-unofficial 24.2.0-trunk Bookworm with bleeding edge Linux 6.6.6-edge-sunxi64

No end-user support: built from trunk

System load:   26%              Up time:       0 min
Memory usage:  12% of 919M      IP:            XXX.XXX.XXX.XXX
CPU temp:      41°C             Usage of /:    4% of 58G
RX today:      146.6 MiB

Last login: Fri Dec 15 18:29:24 AEDT 2023 on ttyS0
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:

 

Edited by pixdrift
1
Gunjan Gupta

Gunjan Gupta

Posted
Posted
1 hour ago, pixdrift said:

This is interesting, looking at the kernel config for the build, the following is configured, and I assumed this is correct for this board.

Adjust patch/kernel/archive/sunxi-6.6/patches.armbian/arm64-dts-allwinner-h616-Add-efuse_xlate-cpu-frequency-scaling-v1_6_2.patch to patch arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero.dtsi instead of arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts

 

1 hour ago, pixdrift said:

When I run the cpufreq-info command, the Zero2 appears to lock up and never recover

Interesting. So it happens on h616 as well. Its that wifi driver causing the trouble again. I have encountered this issue on Orange Pi 3 LTS as well. I ended up removing sprdwl_ng from MODULES and loaded it instead using a systemd service. See https://github.com/armbian/build/commit/608618a6f5b341a1a171d3a0841a4807432d8294

1
ag123

ag123

Posted
  • Author
Posted

@pixdrift oops for that cpufreq lockup on zero 2

 

I tried probing the cpufreq modules:

  

 >find /lib/modules -type f -name "*freq*"
/lib/modules/6.6.4-edge-sunxi64/kernel/drivers/cpufreq/cpufreq-dt.ko
/lib/modules/6.6.4-edge-sunxi64/kernel/drivers/cpufreq/scpi-cpufreq.ko
> ls /lib/modules/6.6.4-edge-sunxi64/kernel/drivers/cpufreq
cpufreq-dt.ko  scpi-cpufreq.ko
> sudo modprobe cpufreq-dt scpi-cpufreq
> sudo cpufreq-info 
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 4294.55 ms.
analyzing CPU 1:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 4294.55 ms.
analyzing CPU 2:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 4294.55 ms.
analyzing CPU 3:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 4294.55 ms.

 

perhaps like @Gunjan Gupta

mentioned it may require additional codes e.g. that patch.

 

well no worries, I'd try to get around with my kernel build, hope I can resolve the loop devices nspawn limitations

but that the freeze for orange pi zero 2 isn't good, and i'm half guessing the symptom may be observed on zero 3 if cpufreq is after all patched in and some how work.

possibly a problem with the wifi driver design. I'm not sure where I read about that always 1 load is possibly caused by the uwe5622 wifi driver disabling interrupts and go into a busy polling loop.

if for some reason changing frequencies causes interrupts, it can cause other process to stall/freeze waiting for the interrupt to be served.

 

 

1
ag123

ag123

Posted
  • Author
Posted

@Benedito Portela note that what you read here is *highly experimental*, we are 'playing' with the codes and hope that somehow we'd make it work, and we are testing initial experimental images / builds, but there are no assurances whatsoever. But that if you do run the images e.g. from @pixdrift, do feedback on your findings.

And that Orange Pi do distribute official images if you look in the download section for the board, but that those could be distributions other than Armbian.

 

 

1
pixdrift

pixdrift

Posted
Posted (edited)
7 hours ago, Gunjan Gupta said:

https://github.com/armbian/build/pull/6070 should fix the cpufreq hang issue and should also get bluetooth working for orange pi zero 2


This is a really nice PR @Gunjan Gupta, the move to using an extension is so much cleaner and it's a great consolidation and clean up... very impressed by your work! and learning a lot about Armbian along the way :)

Looking at this code it should work for the zero3 as well, so thanks as always for posting and I will work on merging this into the zero3 fork so it can stay as consistent as possible.

Is anyone able to provide (or devise) a simple test for Bluetooth on these boards? I am heavily in the server space, so don't play much with BT on Linux :)

I was thinking of building out a test script so that people who download the image can run the tests and confirm results so we can get a consolidated summary of feedback from people who are assisting with testing and perhaps feed this into a CI process for validation later down the road.

Edited by pixdrift
0

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept