robertoj Posted February 4 Posted February 4 On 1/31/2024 at 10:13 PM, pixdrift said: Looks like the latest PR from @Gunjan Gupta merged a fix for the wifi load average problem thanks to github user @pyavitz. https://github.com/armbian/build/pull/6228 Good news because it was an annoying issue -edit- Looks good orangepizero3:~$ uptime 18:42:56 up 45 min, 2 users, load average: 0.07, 0.02, 0.00 I have posted a build here if anyone wants to validate the load average change https://armdev.pixeldrift.net/orangepi/zero3/pr_testing/PR6228_20240130_b600ead20_Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.3.tar.xz Edited Wednesday at 11:43 PM by pixdrift Hello. Thank you for making this image. I recently refocused in my orange pi boards and want to try this 👍🏽 i hope I don’t get much trouble with basic GPIO usage 0 Quote
Gunjan Gupta Posted February 4 Posted February 4 I would suggest you to try latest rolling release from https://www.armbian.com/orange-pi-zero-3/ 0 Quote
robertoj Posted February 4 Posted February 4 14 minutes ago, Gunjan Gupta said: I would suggest you to try latest rolling release from https://www.armbian.com/orange-pi-zero-3/ Thank you!! 0 Quote
Stephen Graf Posted February 5 Posted February 5 I would like to have a clear statement of how the orangepizero2 and orangepizrto3 are going to be treated going forward. Currently the orangepizero2 is a supported board, although how it got that way I can't figure out. So little of it was working until this round of development over the last few months. There is no maintainer listed at present. The only software differences between the zero3 and zero2 were taken care of upstream and are not an issue for Armbian. Other than the work to set up the orangepizero3 as a wip all the recent development work benefited the zero2 (a supported board) as much as the zero3. There was a lot of good work done that benefited a supported board. Any arguments to support or not the zero2 applies equally to the zero3. With the availability of the zero3, the zero2 is probably hardware obsolete. It is important for someone who is trying to choose a board for use to clearly understand what software support there is for the board. I probably made a mistake by assuming that because the zero2 was supported the zero3 would also be. There were volunteers willing and capable to make that happen. We were being supported by a developer. The zero3 is now much more ready to be a supported board than the zero2 ever was. If there is no possibility of this happening then the potential users of the zero3 need to be aware so that they can take that into consideration in going forward. Also there is no point for volunteers to work on the zero3 if developers are just going to ignore, or worse reject, the volunteers work. A clearer, if possible, statement would be much appreciated. 0 Quote
SteeMan Posted February 5 Posted February 5 27 minutes ago, Stephen Graf said: would like to have a clear statement of how the orangepizero2 and orangepizrto3 are going to be treated going forward. The answer to this question will likely come out of the 24.02 release planning meeting: https://forum.armbian.com/topic/33605-armbian-2402-release-planning The approval of the developer community is a requirement for standard support of a board. I would suggest you attend this meeting. One thing you may not be aware of that is in the background is the relationship (or lack thereof) between Armbian and Orange Pi. You might notice that they were not mentioned in the Vendor Appreciation section in today's Armbian Leaflet #18. Along with having a maintainer for a board to be supported, it also needs: For a SBC to be considered supported: - must be beneficial to the Armbian project - Armbian team must confirm and agree upon all supported boards statuses Currently I would say the lack of a relationship between Armbian and Orange Pi will make it difficult to demonstrate how the added support workload is beneficial to the Armbian project. (my opinion, not official statement) 29 minutes ago, Stephen Graf said: Currently the orangepizero2 is a supported board, although how it got that way I can't figure out. So little of it was working until this round of development over the last few months. There is no maintainer listed at present. The zero 2 currently has two maintainers listed. 0 Quote
Stephen Graf Posted February 5 Posted February 5 17 minutes ago, SteeMan said: The zero 2 currently has two maintainers listed. Why am I seeing this: https://www.armbian.com/orange-pi-zero-2/ Maintainer needed? 0 Quote
SteeMan Posted February 5 Posted February 5 Updates to the website can be a manual process for many things. And with any manual process, there are bound to be many mistakes. The most accurate info for any board is to look in the board config file. The board maintainer is automatically maintained from a database of maintainer information. $ grep BOARD_MAINTAINER orangepizero2.conf BOARD_MAINTAINER="krachlatte AGM1968" 0 Quote
Stephen Graf Posted February 5 Posted February 5 @SteeMan Thanks for the update. Please excuse me for being confused. I am looking at things like an end user would to determine board status. 0 Quote
Igor Posted February 5 Posted February 5 1 minute ago, SteeMan said: Updates to the website can be a manual process for many things Yes, but we are slowly applying automation. We currently don't have a dedicated person for website works and this is done by Effe with my assistance https://armbian.atlassian.net/browse/AR-909 (Automatic synchronization of board status between GitHub and website hasn't started yet) 0 Quote
Tusc Posted February 6 Posted February 6 Dumb question, what happend to the images on this page? It appears they were taken down: https://www.armbian.com/orange-pi-zero-3/ 0 Quote
Igor Posted February 6 Posted February 6 2 hours ago, Tusc said: Dumb question Can provide only dumb answer. Its not directed to you in person ... There is an add out there for almost a year. Nobody wants to use opportunity to learn and help you. Without maintaining automation ... things breaks down. Same will happen with board X, after we stop doing what we do. There is very little help elsewhere too. People don't want to know how much Armbian lost by providing you (and competitors, vendors, you ... that have no interest to cover our costs), those images. No, nobody asks, nobody cares, so we can live with what we already have. You assume this is what we do for fun? To some degree it is, but fun stops when abuse and blackmailing starts. Which is constantly present. Way too many people use all kind of tricks trying to manipulate with us to solve their computer problems in our private time. Welcome to Armbian forums Stay tuned, images will be back when they will be back. 0 Quote
ag123 Posted February 6 Author Posted February 6 @Tusc wrote: Quote Dumb question, what happend to the images on this page? It appears they were taken down: https://www.armbian.com/orange-pi-zero-3/ they are not quite yet ready for 'prime time', check out the rolling releases: https://github.com/armbian/os/releases/latest https://github.com/armbian/os/releases/tag/24.2.0-trunk.519 expand the 'Assets' flap, use your web browser's in page search and look for 'zero3'. still in 'bleeding edge' (technology) stage, try it/them out feedback on what works, issues etc. @Gunjan Gupta curiously in the most recent trunk.526 https://github.com/armbian/os/releases/latest a text search for 'zero3' draws a blank, but it is there in 519 0 Quote
Gunjan Gupta Posted February 6 Posted February 6 4 hours ago, Tusc said: Dumb question, what happend to the images on this page? It appears they were taken down: https://www.armbian.com/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. 23 minutes ago, ag123 said: curiously in the most recent trunk.526 https://github.com/armbian/os/releases/latest a text search for 'zero3' draws a blank, but it is there in 519 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. 1 Quote
robertoj Posted February 6 Posted February 6 I tried the latest rolling release from Feb 4, and I have good wifi performance and 0.0 cpu load when idle I tried to use GPIO Python from https://opi-gpio.readthedocs.io/en/latest/ however, it depends on having files in /sys/class/gpio/… which my original opi zero has, but my opi zero3 doesn’t have. Does GPIO depend on a dtbo or a ko? Or is it an option in kernel config, or within armbian-config? 0 Quote
Stephen Graf Posted February 6 Posted February 6 @Roberto I think the /sys/class type of gpio is no longer supported in the new linux releases. I have not used python to control gpio but when I tested gpio on the zero3 I discovered that the /sys/class procedures no longer worked. I then looked up some rust code and used their examples to test using the /dev/gpiochip procedures. I am sure that there must be some uptodate python code. 0 Quote
robertoj Posted February 6 Posted February 6 Thank you... I was just making a new thread about this topic... hopefully someone will give me a solution soon 0 Quote
ag123 Posted February 6 Author Posted February 6 @robertoj I started reading up a few things but that I'm more confused as ever: There is this thing about pincontrol https://www.kernel.org/doc/html/v4.13/driver-api/pinctl.html https://elinux.org/images/b/b6/Pin_Control_Subsystem_Overview.pdf https://wiki.st.com/stm32mpu/wiki/Pinctrl_overview ^ I liked this one from ST, but that I've not read well enough to understand how pin-control relates to gpio. on a superficial level, I understand it like such, as there are various configurations related to gpio pins e.g. that gpio pins can be configured in varous setups, e.g. input, output, pull up, pull down and other gpio properties etc (possibly soc related), then that for the pins in addition to gpio, there is pin mux, which 'behind' it can be configured for various 'alternate functions' e.g. spi, i2c, uart, pwm etc, then add interrupts etc. and accordingly earlier 'gpio' implementations eventually digressed and requires 'hacks' to get around 'missing' capabilities that is mapped in the more complex pin-control. But that I don't understand deeper than this that if pin control after all configures the pins as above, then where do gpio in the 'simple' sense e.g. reading the pins high or low, or writing to the pins work? Accordingly, there are API interfaces for that if you read the documentation, but I got stuck understanding further about this, i.e. I still don't know how gpio works in this context. on further 'google searches', I stumbled into more recent documentation https://www.kernel.org/doc/html/v6.7/driver-api/pin-control.html https://www.kernel.org/doc/html/v6.7/driver-api/gpio/index.html so it'd seem pin-control and gpio are after all 2 sets of API 0 Quote
Stephen Graf Posted February 6 Posted February 6 I have used the old /sys/class gpio interface quite extensively in the past. However it is not available in the newer kernels and my only experience with the new api has been to test the orangepizero3 with the code in the links below. It worked. https://docs.rs/gpio-cdev/latest/gpio_cdev/ https://github.com/rust-embedded/rust-gpio-cdev 1 Quote
ag123 Posted February 7 Author Posted February 7 @robertoj, all I stumbled into this: https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/ Quote libgpiod ======== libgpiod - C library and tools for interacting with the linux GPIO character device (gpiod stands for GPIO device) Since linux 4.8 the GPIO sysfs interface is deprecated. User space should use the character device instead. Version 2 of libgpiod requires GPIO character device uAPI v2 which was first released in linux 5.10. This library encapsulates the ioctl calls and data structures behind a straightforward API. ... TOOLS ----- There are currently six command-line tools available: * gpiodetect - list all gpiochips present on the system, their names, labels and number of GPIO lines * gpioinfo - list lines, their gpiochip, offset, name, and direction, and if in use then the consumer name and any other configured attributes, such as active state, bias, drive, edge detection and debounce period * gpioget - read values of specified GPIO lines * gpioset - set values of specified GPIO lines, holding the lines until the process is killed or otherwise exits * gpiomon - wait for edge events on GPIO lines, specify which edges to watch for, how many events to process before exiting, or if the events should be reported to the console * gpionotify - wait for changed to the info for GPIO lines, specify which changes to watch for, how many events to process before exiting, or if the events should be reported to the console This seemed to be there in a 'minimal' build, check if you are able to run those commands the pins didn't seemed named sudo gpioinfo [sudo] password for armbian: gpiochip0 - 288 lines: line 0: unnamed unused input active-high line 1: unnamed unused input active-high line 2: unnamed unused input active-high line 3: unnamed unused input active-high line 4: unnamed unused input active-high ... gpiochip1 - 32 lines: line 0: unnamed unused input active-high line 1: unnamed unused input active-high line 2: unnamed unused input active-high line 3: unnamed unused input active-high ... however, that they seemed to be mapped to 2 (set of) pin-control drivers https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c?h=v6.7.4 #include "pinctrl-sunxi.h" static const struct sunxi_desc_pin h616_pins[] = { /* Internally connected to the AC200 part in the H616 SoC */ SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0), SUNXI_FUNCTION(0x0, "gpio_in"), SUNXI_FUNCTION(0x1, "gpio_out"), SUNXI_FUNCTION(0x2, "emac1"), /* ERXD1 */ SUNXI_FUNCTION(0x4, "i2c0"), /* SCK */ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /* PA_EINT0 */ SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1), SUNXI_FUNCTION(0x0, "gpio_in"), SUNXI_FUNCTION(0x1, "gpio_out"), SUNXI_FUNCTION(0x2, "emac1"), /* ERXD0 */ SUNXI_FUNCTION(0x4, "i2c0"), /* SDA */ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)), /* PA_EINT1 */ ... a lot more ... static const unsigned int h616_irq_bank_map[] = { 0, 2, 3, 4, 5, 6, 7, 8 }; static const struct sunxi_pinctrl_desc h616_pinctrl_data = { .pins = h616_pins, .npins = ARRAY_SIZE(h616_pins), .irq_banks = ARRAY_SIZE(h616_irq_bank_map), .irq_bank_map = h616_irq_bank_map, .irq_read_needs_mux = true, .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_CTL, }; static int h616_pinctrl_probe(struct platform_device *pdev) { return sunxi_pinctrl_init(pdev, &h616_pinctrl_data); } static const struct of_device_id h616_pinctrl_match[] = { { .compatible = "allwinner,sun50i-h616-pinctrl", }, {} }; static struct platform_driver h616_pinctrl_driver = { .probe = h616_pinctrl_probe, .driver = { .name = "sun50i-h616-pinctrl", .of_match_table = h616_pinctrl_match, }, }; builtin_platform_driver(h616_pinctrl_driver); https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/pinctrl/sunxi/pinctrl-sun50i-h616-r.c?h=v6.7.4 #include "pinctrl-sunxi.h" static const struct sunxi_desc_pin sun50i_h616_r_pins[] = { SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0), SUNXI_FUNCTION(0x0, "gpio_in"), SUNXI_FUNCTION(0x1, "gpio_out"), SUNXI_FUNCTION(0x2, "s_rsb"), /* SCK */ SUNXI_FUNCTION(0x3, "s_i2c")), /* SCK */ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1), SUNXI_FUNCTION(0x0, "gpio_in"), SUNXI_FUNCTION(0x1, "gpio_out"), SUNXI_FUNCTION(0x2, "s_rsb"), /* SDA */ SUNXI_FUNCTION(0x3, "s_i2c")), /* SDA */ }; static const struct sunxi_pinctrl_desc sun50i_h616_r_pinctrl_data = { .pins = sun50i_h616_r_pins, .npins = ARRAY_SIZE(sun50i_h616_r_pins), .pin_base = PL_BASE, }; static int sun50i_h616_r_pinctrl_probe(struct platform_device *pdev) { return sunxi_pinctrl_init(pdev, &sun50i_h616_r_pinctrl_data); } static const struct of_device_id sun50i_h616_r_pinctrl_match[] = { { .compatible = "allwinner,sun50i-h616-r-pinctrl", }, {} }; static struct platform_driver sun50i_h616_r_pinctrl_driver = { .probe = sun50i_h616_r_pinctrl_probe, .driver = { .name = "sun50i-h616-r-pinctrl", .of_match_table = sun50i_h616_r_pinctrl_match, }, }; builtin_platform_driver(sun50i_h616_r_pinctrl_driver); gpiochip0 apparently corresponds to sun50i-h616-pinctrl, the main large bank of IO lines / those are muxed and a lot of them have alternate functions e.g. emac, etc. it'd seemed a little strange that gpiochip1 (sun50i-h616-r-pinctrl) gets a readout of 32 lines. (^edit: https://www.kosagi.com/w/index.php?title=Definitive_GPIO_guide linux gpio number = (gpio_bank - 1) * 32 + gpio_bit solves the puzzle, it could mean that the gpio register is 32 bits and that actually 2 lines are defined. that gives a feeling that the other bits/lines are *undocumented* (often marked 'reserved') 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 and apparently gpiod bindings are after all standard https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/bindings 0 Quote
robertoj Posted February 7 Posted February 7 That gpiod sounds very promising, and easy to use with https://pypi.org/project/gpiod/ I need to wait until I get back home to work on my opiz3 0 Quote
VioletGiraffe Posted February 14 Posted February 14 (edited) Where can I find uboot source code after I compiled Armbian? Did it get deleted? Don't see it anywhere - there is kernel source, but no sign of uboot. Edited February 14 by VioletGiraffe 0 Quote
Shivan SpS Posted February 16 Posted February 16 I know this is about zero 3, but the 2W works just as well with the same image, someone knows of a way to get audio out via the PWM1 and PWM2 GPIO pins of the 2W? 0 Quote
robertoj Posted February 16 Posted February 16 Audio on the opiz2w is through the "expansion interface". Have you seen other boards using the PWM for audio? There's a thread about the opiz2w... use that 0 Quote
Shivan SpS Posted February 17 Posted February 17 There is no one working on the 2W, i ask here because it is similar enoght to the point the same image works without issue. For what im doing i cant use the expansion board, and i dont have it either, the problem is that there is no pinout of the expansion interface, otherwise i would have tried to plug in some small flex to get the audio signals. Raspbery PI Zeros can get audio out via PWM pins, i think it is using an overlay. 0 Quote
robertoj Posted February 18 Posted February 18 https://www.amazon.com/Expansion-Connector-Interface-Development-Computer/dp/B0CHMTT4XP/ http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/2W-expansion-board.html http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_Zero_2W#24Pin_expansion_board_interface_pin_description In the tiny 24 pin expansion connector Pin 22=left audio Pin 23=right audio Pin 24=ground In armbian, orangepizero 3 audio support is missing, as of 2024-Feb-15... so you should try it and see if it works or not in opiz 2w (probably not). Then, use the OFFICIAL OrangePi Zero 3 Debian with Linux 6.1. The audio should work. Then tell us in the OrangePi Zero 2W thread. Raspberry Pi has a whole different ARM CPU... don't expect that hardware is going to work exact the same way. 0 Quote
DmitriyPie Posted February 20 Posted February 20 Hello, is there currently an armbian image for Orangepizero3 with stable WI-Fi? Thank you 0 Quote
robertoj Posted February 21 Posted February 21 I am using the armbian bookworm for Opiz3 from February 15 with zero problems. Are you using this image? 0 Quote
Sma Posted February 21 Posted February 21 (edited) On 2/20/2024 at 9:41 AM, DmitriyPie said: Hello, is there currently an armbian image for Orangepizero3 with stable WI-Fi? Thank you The latest images should have working wifi. I haven't tested personally myself, since...two weeks ago maybe. I recall someone not long ago saying that the Wi-Fi CPU usage issue was fixed too. I haven't had the time lately, but I'm looking to make it work with the MPI3508 LCD Touch screen. I may have to end up compiling support for it, but I've gotta look at the various resources to figure it out. Edited February 21 by Sma 0 Quote
DmitriyPie Posted February 22 Posted February 22 Thanks for the answer, I use Armbian_24.2.0-trunk.435_Orangepizero3_noble_edge_6.7.1_xfce_desktop.img , Wi-Fi does not work stably. Where can I download the latest version? 0 Quote
robertoj Posted February 22 Posted February 22 https://www.armbian.com/orange-pi-zero-3/ Now it links to an OS image made on February 22. Try the non GUI image, and see if it makes a difference. See if the difference is with 802.11b, g or n Current and older releases: https://github.com/armbian/community/releases/tag/24.5.0-trunk.58 https://github.com/armbian/community/releases 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.