Jump to content

Orange Pi Zero 3

ag123

By ag123
in Allwinner sunxi

 Share

Recommended Posts

robertoj

robertoj

Posted
Posted
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
Link to comment
Share on other sites
Stephen Graf

Stephen Graf

Posted
Posted

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
Link to comment
Share on other sites
SteeMan

SteeMan

Posted
Posted
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
Link to comment
Share on other sites
SteeMan

SteeMan

Posted
Posted

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
Link to comment
Share on other sites
Igor

Igor

Posted
Posted
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
Link to comment
Share on other sites
Igor

Igor

Posted
Posted
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
Link to comment
Share on other sites
ag123

ag123

Posted
  • Author
Posted

 

@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
Link to comment
Share on other sites
Gunjan Gupta

Gunjan Gupta

Posted
Posted
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
Link to comment
Share on other sites
robertoj

robertoj

Posted
Posted

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
Link to comment
Share on other sites
Stephen Graf

Stephen Graf

Posted
Posted

@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
Link to comment
Share on other sites
ag123

ag123

Posted
  • Author
Posted

@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
Link to comment
Share on other sites
Stephen Graf

Stephen Graf

Posted
Posted

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
Link to comment
Share on other sites
ag123

ag123

Posted
  • Author
Posted

@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
Link to comment
Share on other sites
Shivan SpS

Shivan SpS

Posted
Posted

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
Link to comment
Share on other sites
robertoj

robertoj

Posted
Posted

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
Link to comment
Share on other sites
Sma

Sma

Posted
Posted (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 by Sma
0
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

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

×   Your previous content has been restored.   Clear editor

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

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

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept