Jump to content

ag123

Members
  • Posts

    233
  • Joined

  • Last visited

Reputation Activity

  1. Like
    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.
     
     
  2. Like
    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
  3. Like
    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.
     
  4. Like
    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.
     
  5. Like
    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.
  6. Like
    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
  7. Like
    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.
  8. Like
    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
  9. Like
    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*.
     
  10. Like
    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*.
     
  11. Like
    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*.
     
  12. Like
    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*.
     
  13. Like
    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.
  14. Like
    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.
  15. Like
    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.
  16. Like
    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.
  17. Like
    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
  18. Like
    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...
  19. Like
    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
  20. Like
    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/
  21. Like
    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
  22. Like
    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.
  23. Like
    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
  24. Like
    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
  25. Like
    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
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines