ag123
-
Posts
233 -
Joined
-
Last visited
Reputation Activity
-
ag123 got a reaction from thuvasooriya in Orange Pi Zero 3
@thuvasooriya wrote
rather than to use HDMI and a monitor, I used a usb-uart (usb-serial) dongle
that lets me connect over the serial console with the debug pins and I'm literally able to boot up in a serial console and (even) configure networking, i.e. I didn't even need network and can change the network interface configurations. That would also be a way to troubleshoot boot up problems if there is. I used the serial debug pins/console to configure networking as more than often, the default setup of network isn't what I want, and playing with the network interfaces will lock me out of ssh.
After I've network configured over usb-uart, I can then ssh remotely into the device over the network.
And that if you use dynamic IP, it may help to install and use avahi-daemon and avahi-tools (i.e. multicast DNS), I installed avahi-daemon on the OPi Z3 Armbian board so that I can find it from my main linux box using avahi-browse -a , and that ssh into there could be simply ssh orangepizero3.local
that's a way to practically use it headless , in fact, after I've setup things, it is now my WiFi AP on the desk.
-
ag123 reacted to robertoj in Orange Pi Zero 3 GPIO
I returned to checking on my opiz3, and saw that there's a kernel update available... with related updated dtb's
I will hold off from updating, and test it first in my non-production opiz3
-
ag123 got a reaction from Dariy in Orange Pi Zero 3, WIFI AP mode: protocol 0000 is buggy, dev wlan0
the 'community' one is here, scroll right to the bottom
https://www.armbian.com/orange-pi-zero-3/
and the kernel version is at least 6.6 and above
apparently someone has seen the same , so it isn't 'new'
https://www.linux.org/threads/protocol-0000-is-buggy-dev-wlan0.42774/
if one google around the web one may stumble into this
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
it could mean a device you have is sending out goofy packets that are not regular IP packets. the normal protocols used are usually TCP, UDP and ICMP.
-
ag123 got a reaction from VioletGiraffe in Orange Pi Zero 3
@Long-Johnny
Rather than to say 'never solved', we (as a community) need to learn about *uboot*
https://docs.u-boot.org/en/latest/
https://linux-sunxi.org/U-Boot
this is practically the *BIOS* for these little boards that we use and that u-boot boots Linux - it is the boot loader.
Once you / we find a way to pass that memory size to *uboot*, then it is a matter of learning to configure a file e.g. edit a DTS overlay to encode the memory size.
And there you have it, a fully supported board.
But that that step/procedure may have to be manually done by hand.
In that sense, once one figures this out, one can manually configure these boards for any arbitrary memory size.
-
ag123 got a reaction from Gunjan Gupta in Orange Pi Zero 3 GPIO
@robertoj, all,
apparently, it may be possible to name the lines in the DTS
https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpio/gpiolib.c?h=v6.7.4#n456
Example: gpio-controller@00000000 { compatible = "foo"; reg = <0x00000000 0x1000>; gpio-controller; #gpio-cells = <2>; ngpios = <18>; gpio-reserved-ranges = <0 4>, <12 2>; gpio-line-names = "MMC-CD", "MMC-WP", "VDD eth", "RST eth", "LED R", "LED G", "LED B", "Col A", "Col B", "Col C", "Col D", "Row A", "Row B", "Row C", "Row D", "NMI button", "poweroff", "reset";
I'm not sure though if the gpio-line-names assignment can be used in pin-control devices that is currently present in the existing DTS.
note also that the line/pin functions are actually defined in the source codes for the pin-control driver, just that this won't automatically appear as gpio-line-names.
you may want to start experimenting, post your findings and perhaps make a PR?
note that there is another source tree to commit though , which is in linux-sunxi - that would be directly mainlining / upstreaming the changes.
https://linux-sunxi.org/Main_Page
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/
they have a google groups here:
https://groups.google.com/g/linux-sunxi
https://linux-sunxi.org/Mailing_list
I'm not too sure about the procedure to commit changes in mainline though.
-
ag123 reacted to robertoj in Orange Pi Zero 3 GPIO
Ok. I got one output pin to work. 😀
This is how to do it in OrangePi Zero 3, pin 8 PH2:
In Bash as root:
# addgroup --system gpio
# chown root:gpio /dev/gpiochip0
# chmod 660 /dev/gpiochip0
# nano /etc/udev/rules.d/61-gpio-tools.rules
{add line SUBSYSTEM=="gpio",KERNEL=="gpiochip*", GROUP="gpio", MODE="0660"}
# usermod -a -G gpio myusername
# apt install python3-dev
# reboot
In a new folder for your Python script, as normal user:
$ python3 -m venv .venv
$ source .venv/bin/activate
$ pip install gpiod
Create script (example in https://pypi.org/project/gpiod/ with one fix):
$ nano blink_pin.py
import time import gpiod #needed in example from gpiod.line import Direction, Value #Calculating PH2 "line" number #H=8 #2=2 #line=(8-1)x32+2=226 #also shown in https://github.com/rm-hull/OPi.GPIO/issues/79 LINE = 226 with gpiod.request_lines( "/dev/gpiochip0", consumer="blink-example", config={ LINE: gpiod.LineSettings( direction=Direction.OUTPUT, output_value=Value.ACTIVE ) }, ) as request: while True: request.set_value(LINE, Value.ACTIVE) time.sleep(1) request.set_value(LINE, Value.INACTIVE) time.sleep(1)
Run script:
$ python3 blink_pin.py
When done working with your project:
$ deactivate
Pin 8 PH2 turns ON and OFF 😄
I haven't tested the other pins yet
-
ag123 reacted to Gunjan Gupta in Orange Pi Zero 3
The most recent CI job got failed in the stage that updates the website. Hence the image got missing from the web page. It will be back in few hours. Until then you can download them from the link that @ag123shared above.
The CI jobs finds what board images need to be rebuilt based on the changes made in the build repository. As there are no changes merged for zero3 in last two days, no new Images were generated for the same.
-
ag123 reacted to Gunjan Gupta in Orange Pi Zero 3
There is actually no need to build the image yourself. You can just download the latest nightly release from https://github.com/armbian/os/releases/latest
-
ag123 got a reaction from Werner in NPU
here is some 2 cents comments, if you are meaning NPUs like these:
https://github.com/rockchip-linux/rknpu2
- hardware interfaces are kept as trade secrets and not published anywhere
1st the hardware interfaces are practically undocumented, what they provide is mostly an 'sdk' with some binary blobs
it practically means there is *no way* to use the NPU as those binary blobs in turn depend on device drivers which again are binary blobs (no source)
and there is no hardware documentation any where about the technical details, registers etc.
if that at least those are published, one could possibly start coding something to test things on the NPU.
then that for things like ethos-n78
https://www.arm.com/products/silicon-ip-cpu/ethos/ethos-n78
you can find some info here
https://developer.arm.com/Processors/Ethos-N78
but that it seemed the real SOCs with that chip is no where to be seen let alone any boards found with them.
- IO / cpu scheduling
cpu frequency scaling / governors are well documented
https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
https://docs.kernel.org/scheduler/schedutil.html
https://www.kernel.org/doc/html/latest/scheduler/
and for 'simple' ARM (or RISC V) chips, any sort of 'elaborate' scheduling are probably going to just burn more cpu cycles with little to gain.
but that nevertheless the source codes and the documentations are there so that one can try to develop your own governor if you prefer.
and that the elaborate 'advanced' schedutil governor is already there in the kernel, likely in Armbian as well.
Hence, one can proceed to improve that if one deem that the state-of-the-art currently isn't adequate.
and if one wants to do some manual scheduling there is the plain old "nice" command
https://www.scaler.com/topics/linux-nice/
----
well my thoughts, scheduling and NPU are 2 unrelated issues, it is possible to handle 'elaborate' scheduling without an NPU, this is currently the state-of-the-art from the 'lowly' ARM boards that we are running, to top tier high core count Intel Xeon / AMD Epyc processors and running all that loads ranging from amazon, google, chatgpt etc, no issues.
The other thing being the NPUs itself, currently many SOC IP owners, held their hardware interfaces as *trade secrets* and refused to release them.
You would need to jump that hoop to even use the NPU without any documentation, or else use their proprietary binary blob software, which won't work outside their proprietary binary blob distributions.
This withheld *trade secret* about the NPU is the biggest pitfall / trap to those buying those boards with those SOCs and wanting to use the NPU. you get *no support*, *no help*, *no nothing* after you buy the board which purportedly has the NPU. practically *useless*. don't even bother to try it for any 'test' 'AI' stuff, you may at best get a *binary blob demo* and that's it (and it is not anywhere close to even using it for any practical purpose, let alone scheduling).
And much more than that, using an NPU practically means that your neural network model must be *quantized*, if you know what that means. All those small NPU hardware normally handles like 8 bit integers, 16 bit integers or at best 16 bit floats. This practically means that you would need to spend a lot of effort to *convert* even ordinary neural networks into the *quantized* form that can be processed by the NPU, if you can't convert that it is unusable. Even if you managed to convert that there is a risk of lost of precision, e.g. if you convert a 32 bit float down to an 8 bit int, you may practically be quantizing a number space of 4 billion numbers (actually more) to 256 quantized levels. that is the extreme of the information loss, and at the end of the day, if it even works, you may simply get *wrong* results, and again it is practically *useless*.
-
ag123 got a reaction from SteeMan in NPU
here is some 2 cents comments, if you are meaning NPUs like these:
https://github.com/rockchip-linux/rknpu2
- hardware interfaces are kept as trade secrets and not published anywhere
1st the hardware interfaces are practically undocumented, what they provide is mostly an 'sdk' with some binary blobs
it practically means there is *no way* to use the NPU as those binary blobs in turn depend on device drivers which again are binary blobs (no source)
and there is no hardware documentation any where about the technical details, registers etc.
if that at least those are published, one could possibly start coding something to test things on the NPU.
then that for things like ethos-n78
https://www.arm.com/products/silicon-ip-cpu/ethos/ethos-n78
you can find some info here
https://developer.arm.com/Processors/Ethos-N78
but that it seemed the real SOCs with that chip is no where to be seen let alone any boards found with them.
- IO / cpu scheduling
cpu frequency scaling / governors are well documented
https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
https://docs.kernel.org/scheduler/schedutil.html
https://www.kernel.org/doc/html/latest/scheduler/
and for 'simple' ARM (or RISC V) chips, any sort of 'elaborate' scheduling are probably going to just burn more cpu cycles with little to gain.
but that nevertheless the source codes and the documentations are there so that one can try to develop your own governor if you prefer.
and that the elaborate 'advanced' schedutil governor is already there in the kernel, likely in Armbian as well.
Hence, one can proceed to improve that if one deem that the state-of-the-art currently isn't adequate.
and if one wants to do some manual scheduling there is the plain old "nice" command
https://www.scaler.com/topics/linux-nice/
----
well my thoughts, scheduling and NPU are 2 unrelated issues, it is possible to handle 'elaborate' scheduling without an NPU, this is currently the state-of-the-art from the 'lowly' ARM boards that we are running, to top tier high core count Intel Xeon / AMD Epyc processors and running all that loads ranging from amazon, google, chatgpt etc, no issues.
The other thing being the NPUs itself, currently many SOC IP owners, held their hardware interfaces as *trade secrets* and refused to release them.
You would need to jump that hoop to even use the NPU without any documentation, or else use their proprietary binary blob software, which won't work outside their proprietary binary blob distributions.
This withheld *trade secret* about the NPU is the biggest pitfall / trap to those buying those boards with those SOCs and wanting to use the NPU. you get *no support*, *no help*, *no nothing* after you buy the board which purportedly has the NPU. practically *useless*. don't even bother to try it for any 'test' 'AI' stuff, you may at best get a *binary blob demo* and that's it (and it is not anywhere close to even using it for any practical purpose, let alone scheduling).
And much more than that, using an NPU practically means that your neural network model must be *quantized*, if you know what that means. All those small NPU hardware normally handles like 8 bit integers, 16 bit integers or at best 16 bit floats. This practically means that you would need to spend a lot of effort to *convert* even ordinary neural networks into the *quantized* form that can be processed by the NPU, if you can't convert that it is unusable. Even if you managed to convert that there is a risk of lost of precision, e.g. if you convert a 32 bit float down to an 8 bit int, you may practically be quantizing a number space of 4 billion numbers (actually more) to 256 quantized levels. that is the extreme of the information loss, and at the end of the day, if it even works, you may simply get *wrong* results, and again it is practically *useless*.
-
ag123 got a reaction from Igor in NPU
here is some 2 cents comments, if you are meaning NPUs like these:
https://github.com/rockchip-linux/rknpu2
- hardware interfaces are kept as trade secrets and not published anywhere
1st the hardware interfaces are practically undocumented, what they provide is mostly an 'sdk' with some binary blobs
it practically means there is *no way* to use the NPU as those binary blobs in turn depend on device drivers which again are binary blobs (no source)
and there is no hardware documentation any where about the technical details, registers etc.
if that at least those are published, one could possibly start coding something to test things on the NPU.
then that for things like ethos-n78
https://www.arm.com/products/silicon-ip-cpu/ethos/ethos-n78
you can find some info here
https://developer.arm.com/Processors/Ethos-N78
but that it seemed the real SOCs with that chip is no where to be seen let alone any boards found with them.
- IO / cpu scheduling
cpu frequency scaling / governors are well documented
https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
https://docs.kernel.org/scheduler/schedutil.html
https://www.kernel.org/doc/html/latest/scheduler/
and for 'simple' ARM (or RISC V) chips, any sort of 'elaborate' scheduling are probably going to just burn more cpu cycles with little to gain.
but that nevertheless the source codes and the documentations are there so that one can try to develop your own governor if you prefer.
and that the elaborate 'advanced' schedutil governor is already there in the kernel, likely in Armbian as well.
Hence, one can proceed to improve that if one deem that the state-of-the-art currently isn't adequate.
and if one wants to do some manual scheduling there is the plain old "nice" command
https://www.scaler.com/topics/linux-nice/
----
well my thoughts, scheduling and NPU are 2 unrelated issues, it is possible to handle 'elaborate' scheduling without an NPU, this is currently the state-of-the-art from the 'lowly' ARM boards that we are running, to top tier high core count Intel Xeon / AMD Epyc processors and running all that loads ranging from amazon, google, chatgpt etc, no issues.
The other thing being the NPUs itself, currently many SOC IP owners, held their hardware interfaces as *trade secrets* and refused to release them.
You would need to jump that hoop to even use the NPU without any documentation, or else use their proprietary binary blob software, which won't work outside their proprietary binary blob distributions.
This withheld *trade secret* about the NPU is the biggest pitfall / trap to those buying those boards with those SOCs and wanting to use the NPU. you get *no support*, *no help*, *no nothing* after you buy the board which purportedly has the NPU. practically *useless*. don't even bother to try it for any 'test' 'AI' stuff, you may at best get a *binary blob demo* and that's it (and it is not anywhere close to even using it for any practical purpose, let alone scheduling).
And much more than that, using an NPU practically means that your neural network model must be *quantized*, if you know what that means. All those small NPU hardware normally handles like 8 bit integers, 16 bit integers or at best 16 bit floats. This practically means that you would need to spend a lot of effort to *convert* even ordinary neural networks into the *quantized* form that can be processed by the NPU, if you can't convert that it is unusable. Even if you managed to convert that there is a risk of lost of precision, e.g. if you convert a 32 bit float down to an 8 bit int, you may practically be quantizing a number space of 4 billion numbers (actually more) to 256 quantized levels. that is the extreme of the information loss, and at the end of the day, if it even works, you may simply get *wrong* results, and again it is practically *useless*.
-
ag123 got a reaction from going in NPU
here is some 2 cents comments, if you are meaning NPUs like these:
https://github.com/rockchip-linux/rknpu2
- hardware interfaces are kept as trade secrets and not published anywhere
1st the hardware interfaces are practically undocumented, what they provide is mostly an 'sdk' with some binary blobs
it practically means there is *no way* to use the NPU as those binary blobs in turn depend on device drivers which again are binary blobs (no source)
and there is no hardware documentation any where about the technical details, registers etc.
if that at least those are published, one could possibly start coding something to test things on the NPU.
then that for things like ethos-n78
https://www.arm.com/products/silicon-ip-cpu/ethos/ethos-n78
you can find some info here
https://developer.arm.com/Processors/Ethos-N78
but that it seemed the real SOCs with that chip is no where to be seen let alone any boards found with them.
- IO / cpu scheduling
cpu frequency scaling / governors are well documented
https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
https://docs.kernel.org/scheduler/schedutil.html
https://www.kernel.org/doc/html/latest/scheduler/
and for 'simple' ARM (or RISC V) chips, any sort of 'elaborate' scheduling are probably going to just burn more cpu cycles with little to gain.
but that nevertheless the source codes and the documentations are there so that one can try to develop your own governor if you prefer.
and that the elaborate 'advanced' schedutil governor is already there in the kernel, likely in Armbian as well.
Hence, one can proceed to improve that if one deem that the state-of-the-art currently isn't adequate.
and if one wants to do some manual scheduling there is the plain old "nice" command
https://www.scaler.com/topics/linux-nice/
----
well my thoughts, scheduling and NPU are 2 unrelated issues, it is possible to handle 'elaborate' scheduling without an NPU, this is currently the state-of-the-art from the 'lowly' ARM boards that we are running, to top tier high core count Intel Xeon / AMD Epyc processors and running all that loads ranging from amazon, google, chatgpt etc, no issues.
The other thing being the NPUs itself, currently many SOC IP owners, held their hardware interfaces as *trade secrets* and refused to release them.
You would need to jump that hoop to even use the NPU without any documentation, or else use their proprietary binary blob software, which won't work outside their proprietary binary blob distributions.
This withheld *trade secret* about the NPU is the biggest pitfall / trap to those buying those boards with those SOCs and wanting to use the NPU. you get *no support*, *no help*, *no nothing* after you buy the board which purportedly has the NPU. practically *useless*. don't even bother to try it for any 'test' 'AI' stuff, you may at best get a *binary blob demo* and that's it (and it is not anywhere close to even using it for any practical purpose, let alone scheduling).
And much more than that, using an NPU practically means that your neural network model must be *quantized*, if you know what that means. All those small NPU hardware normally handles like 8 bit integers, 16 bit integers or at best 16 bit floats. This practically means that you would need to spend a lot of effort to *convert* even ordinary neural networks into the *quantized* form that can be processed by the NPU, if you can't convert that it is unusable. Even if you managed to convert that there is a risk of lost of precision, e.g. if you convert a 32 bit float down to an 8 bit int, you may practically be quantizing a number space of 4 billion numbers (actually more) to 256 quantized levels. that is the extreme of the information loss, and at the end of the day, if it even works, you may simply get *wrong* results, and again it is practically *useless*.
-
ag123 reacted to Werner in Orange Pi Zero 3
"legacy" is a term that thas been established years ago when there wasn't much confusion about it. However things have changed and now it is, depending on board family, either an old-LTS just for historical purpose or a vendor kernel which may or may not significantly outdated but working.
Anyway there are discussion about renaming that into "vendor" or something, however the impact would be huge if not done carefully.
If anyone steps up doing, testing and maintaining this, why not? We won't simply due to lack of human resources.
-
ag123 reacted to Gunjan Gupta in Orange Pi Zero 3
Thats becuase loading overlays from configfs is something that was viewed as not a recommended way and hence was not merged into the kernel. If you still wants to do the same, I believe our Allwinner kernels do have a patch that adds that functionality. Not sure if the same can be said for every soc family supported by Armbian. Also I am not sure if loading overlay via configfs is ever tested and hence cant say how well that works.
-
ag123 reacted to pixdrift in Orange Pi Zero 3
I have only really known about overlays for 24 hours, but this sounds like a good plan to me.
My only question is (as I don't play in this space much), what's the issue with having these enabled by default? and what benefit are you getting by making this disabled with a toggle? From a user experience perspective, there is then an additional step (armbian-config) to make this 'work', but I assume there is a benefit such a memory or power efficiency perspective for having these off if they aren't in use?
I would really like the overlays to be named h61x if they apply to both 616 and 618.. but I haven't thought too deeply about that. As long as we are happy with h618 always matching the h616 due to the fact that they are pin compatible as @Gunjan Gupta says, I guess we stay with h616 to avoid changing thing unnecessarily.
@Stephen Graf I am happy to take up your offer of you figuring it out, as you seem well versed in this part of the board. If you would like me to do a rebuild where those components are removed from the base configuration (so you can move them to overlays), I can do that on my i2c3 branch in github if you like, based on the list you have provided, just let me know.. as I am keen to assist where I can.
As always, thanks to the assistance and feedback everyone, it's been an excellent help in gaining understanding of the board and Armbian and I am sure others following along will also get value out of this information.
-
ag123 got a reaction from going in Building Armbian using Ubuntu (jammy) in a systemd-nspawn container
Updated section on loop devices in systemd-nspawn container
https://gist.github.com/ag88/05245121cce37cb8f029424a20752e35
Currently systemd-nspawn do not support loop devices needed in the compile.sh build. This section documents some workarounds to create loop devices in a systemd-nspawn container. Use this shell script to start systemd-nspawn
#!/usr/bin/bash sudo systemd-nspawn -b --capability=CAP_MKNOD \ --property=DeviceAllow="block-loop rwm" \ --property=DeviceAllow="block-blkext rwm" \ --property=DeviceAllow="/dev/loop-control rwm" \ -D /opt/armbian-build
when the container is started up, in the shell within the container, use this shell script to create the loop devices
#!/usr/bin/bash if ! test -e /dev/loop-control; then sudo mknod /dev/loop-control c 10 237 fi for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do if ! test -e /dev/loop${i}; then sudo mknod /dev/loop${i} b 7 ${i} fi done
In current tests, the above did create the loop devices, but is inadequate to fully resolve the issue with loop devices in armbian build compile.sh.
-
ag123 reacted to pixdrift in Orange Pi Zero 3
@Gunjan Gupta the changes for zero3 CPU Frequency are all bundled into this commit
https://github.com/pixdrift/armbian_build/commit/e53cba13aea0d1d7c555599bd4fbd6ae94d49dd0
It's on my branch zero3_cpufreq
https://github.com/pixdrift/armbian_build/tree/zero3_cpufreq
Changes of interest are are
https://github.com/pixdrift/armbian_build/blob/e53cba13aea0d1d7c555599bd4fbd6ae94d49dd0/patch/kernel/archive/sunxi-6.6/patches.armbian/arm64-dts-allwinner-h616-Add-efuse_xlate-cpu-frequency-scaling-v1_6_2-dtsi.patch#L98-L141
Thanks for the offer to take a look
-
ag123 reacted to fizban in Orange Pi Zero 3
Jus one more piece of news. After rebooting the device (I believe I had to reboot it twice), bluetooth started and I was able to pair it with a loudspeaker, working beautifully. On top of that, I was then able to set VLC to use OpenGL for embedded systems (which did not work before) and, with this configuration, some videos even played with 0 lost frames.
I also connected a 4G modem that supported the rndis driver through the USB and it was recognised without problem. I then installed SQM and cake-autorate to keep the latency in control and so far so good. It seems to be working quite stable. This little device seems to be quite promising, with several nice features at an unbeatable price...
-
ag123 reacted to Gunjan Gupta in Orange Pi Zero 3
Looks like there might be another H618 board in the pipeline named orange pi r1b - https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/config/boards/orangepir1b.conf
-
ag123 reacted to pixdrift in Orange Pi Zero 3
Sorry @Gunjan Gupta not having much luck with these images unfortunately.
I did a quick test of both kernel versions on a Zero2, and neither had HDMI output, although interestingly after the kernel boots it appears to send an HDMI signal (monitor detects it) but doesn't have any output. I tested both kernel versions using Bookworm as the OS.
I noticed in your branch, you haven't enabled console output 'both' or marked display as 'yes', so I rebuilt after updating the configuration and unfortunately I still didn't get anything displaying on HDMI out.
https://github.com/viraniac/armbian_build/blob/h616-hdmi/config/boards/orangepizero2.conf#L7-L8
I did test CPU Freq though and that appears to be working correctly. Here is some debugging output from the 6.1 Bookworm build.
root@orangepizero2:~# uname -a Linux orangepizero2 6.1.69-current-sunxi64 #1 SMP Wed Dec 20 16:00:29 UTC 2023 aarch64 GNU/Linux root@orangepizero2:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 244 us. hardware limits: 480 MHz - 1.51 GHz available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 1.51 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.51 GHz (asserted by call to hardware). cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31% (333) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 244 us. hardware limits: 480 MHz - 1.51 GHz available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 1.51 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.51 GHz (asserted by call to hardware). cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31% (333) analyzing CPU 2: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 244 us. hardware limits: 480 MHz - 1.51 GHz available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 1.51 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.51 GHz (asserted by call to hardware). cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31% (333) analyzing CPU 3: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 244 us. hardware limits: 480 MHz - 1.51 GHz available frequency steps: 480 MHz, 600 MHz, 792 MHz, 1.01 GHz, 1.20 GHz, 1.51 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 1.51 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.51 GHz (asserted by call to hardware). cpufreq stats: 480 MHz:16.49%, 600 MHz:2.47%, 792 MHz:0.66%, 1.01 GHz:0.03%, 1.20 GHz:0.05%, 1.51 GHz:80.31% (333) root@orangepizero2:~# lsmod Module Size Used by algif_hash 16384 1 algif_skcipher 16384 1 af_alg 24576 6 algif_hash,algif_skcipher bnep 28672 2 hci_uart 135168 1 btqca 24576 1 hci_uart btrtl 28672 1 hci_uart btbcm 20480 1 hci_uart btintel 40960 1 hci_uart bluetooth 724992 29 btrtl,btqca,btintel,hci_uart,btbcm,bnep ecdh_generic 16384 2 bluetooth ecc 32768 1 ecdh_generic sprdwl_ng 352256 0 sunxi_addr 20480 1 sprdwl_ng cfg80211 376832 1 sprdwl_ng sunrpc 290816 1 snd_soc_hdmi_codec 24576 0 lz4hc 16384 0 lz4 16384 0 polyval_ce 16384 0 sunxi_cedrus 45056 0 polyval_generic 16384 1 polyval_ce v4l2_mem2mem 36864 1 sunxi_cedrus videobuf2_dma_contig 24576 1 sunxi_cedrus videobuf2_memops 20480 1 videobuf2_dma_contig dw_hdmi_cec 16384 0 dw_hdmi_i2s_audio 16384 0 videobuf2_v4l2 24576 2 sunxi_cedrus,v4l2_mem2mem videobuf2_common 49152 5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_v4l2,v4l2_mem2mem,videobuf2_memops videodev 204800 4 sunxi_cedrus,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem panfrost 69632 0 mc 53248 5 sunxi_cedrus,videodev,videobuf2_v4l2,videobuf2_common,v4l2_mem2mem gpu_sched 28672 1 panfrost dump_reg 24576 0 apple_mfi_fastcharge 20480 0 drm_shmem_helper 20480 1 panfrost display_connector 20480 0 cpufreq_dt 20480 0 zram 28672 3 binfmt_misc 24576 1 sprdbt_tty 36864 2 uwe5622_bsp_sdio 208896 2 sprdbt_tty,sprdwl_ng rfkill 36864 7 sprdbt_tty,bluetooth,cfg80211 fuse 126976 1 dm_mod 131072 0 hid_apple 28672 0 realtek 32768 1 dwmac_sun8i 28672 0 mdio_mux 16384 1 dwmac_sun8i root@orangepizero2:~# dmesg | grep -i hdmi [ 1.444604] sun8i-dw-hdmi 6000000.hdmi: Detected HDMI TX controller v2.12a with HDCP (DWC HDMI 2.0 TX PHY) [ 1.445267] sun8i-dw-hdmi 6000000.hdmi: registered DesignWare HDMI I2C bus driver [ 1.445657] sun4i-drm display-engine: bound 6000000.hdmi (ops 0xffff800008ea4d48) [ 96.336072] sun8i-dw-hdmi 6000000.hdmi: EVENT=plugin [ 96.336102] sun8i-dw-hdmi 6000000.hdmi: read_hpd result: 1 [ 103.529860] sun8i-dw-hdmi 6000000.hdmi: EVENT=plugin [ 189.979691] sun8i-dw-hdmi 6000000.hdmi: EVENT=plugin
It seems very close, just not displaying anything. I will do some more testing and let you know if I get something to work.
If anyone else has a Zero2 and wants to validate my testing, I have posted the images built from @Gunjan Gupta's HDMI testing branch here
https://armdev.pixeldrift.net/orangepi/zero2/viraniac/
-
ag123 reacted to pixdrift in Orange Pi Zero 3
Hi @Ivan Sy thanks for your interest in our Zero3 work and welcome to the forum!
I won't speculate on timelines for official support, but a PR with everything necessary (that @Werner alludes to) shouldn't be far off and we have most of the pieces working to different degrees which is what you will see in some of the testing and discussion in this thread.
The biggest challenge with merging to mainline is really getting the HDMI patch working for the zero2 as the zero2 and zero3 share a lot of similarities in their SoC. @Gunjan Gupta has done some incredible work to wrangle patches for the Zero2 to get everything working, and that is why you will see some Zero2 discussion here which may seem out of place.
Unfortunately the most recent Zero2 test for HDMI still has some challenges, and I have given as much feedback as possible to @Gunjan Gupta but unfortunately @Gunjan Gupta doesn't have a physical Zero2 to test on (yet). Once this patch is merged into the mainline Armbian, I think there will be some effort to move the remaining pieces that are common for both Zero2/Zero3 into a consolidated .dtsi file so both boards can benefit, then it will only take a small amount of effort to add Zero3 configuration (because it's almost identical).
The Zero3 fork I am maintaining, and posting here doesn't take into consideration anything other than the Edge branch and making the Zero3 work, where @Gunjan Gupta has put incredible effort into the Zero2 specifically and I have been porting/testing those changes on Zero3 as we go.
I think the Zero3 is a great board and I am confident that if we maintain momentum with the people who are contributing feedback and assistance from the community here, combined with the amazing patching work form upstream.. we will be able to put together a PR of the quality the project will approve of
Also, if you do buy a Zero2 or Zero3 board, please hang around and help us test and to anyone else browsing this thread that has a Zero2/Zero3 board, create an account and say hi
-
ag123 reacted to pixdrift in Orange Pi Zero 3
The 'most complete' testing build at time of writing is this version, USE AT YOUR OWN RISK!
https://armdev.pixeldrift.net/orangepi/zero3/Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.6.7.tar.xz
There are elements that we know aren't working (Bluetooth, CPU Frequency scaling) and items that are currently untested (audio output via HDMI and the expansion board).
I understand you are looking for a working image, but the Zero3 Armbian image is still in early development and depends heavily on people testing and providing feedback with identified issues. If you do run this image, please provide feedback on specific items you have tested and let us know. It is too early in the development at this stage to provide any advice or assistance for third party user space programs/applications that may produce errors or not work.
-
ag123 reacted to Gunjan Gupta in Orange Pi Zero 3
@pixdriftTry hdmi on orange pi zero 2 for both 6.1 and 6.6 kernel from my branch - https://github.com/viraniac/armbian_build/tree/h616-hdmi
If this works, I will then move all the orangepizero2 patches to orangepizero.dtsi. I want to get this out of the way before I bump the edge kernel to 6.7
-
ag123 reacted to Gunjan Gupta in Orange Pi Zero 3
@pixdrift could you please test the kernel from the following link on Orange Pi Zero 2 - https://drive.google.com/drive/folders/1cjCyISx3r7bVlXEPapf_5BbONQMyTcHX?usp=drive_link
This kernel has all of the sun4i-drm patches enabled. See if HDMI works
-
ag123 reacted to pixdrift in Orange Pi Zero 3
Another day another update
I merged in the Bluetooth fixes from @Gunjan Gupta's pull request to Armbian main branch into my zero3 fork, this includes moving to the extension pattern for the wifi driver.
I did a quick build and tested Bluetooth (pairing to a BT speaker) and the pairing worked, but I didn't test past this. If you have some tests you can do with Bluetooth, I would appreciate the feedback (USE AT YOUR OWN RISK etc.)
https://armdev.pixeldrift.net/orangepi/zero3/Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.6.7.bt.fixed.tar.xz
I have looked at the CPU Frequency patch @Gunjan Gupta mentioned and I will look at modifying this patch to write to the shared .dtsi as suggested so both zero2 and zero3 benefit, I think that is a great suggestion.. this update doesn't include any CPU Frequency fixes yet unfortunately.
Thanks to everyone here that is providing feedback from their testing!
The github repo isn't updated with the BT fixes yet, I will try and get to this tonight so everyone can build updated images.
-edit-
GitHub fork for zero3 is now up to date with BT fixes
https://github.com/pixdrift/armbian_build/tree/zero3