Orange Pi Zero 3

[pixdrift]

9 hours ago, Gunjan Gupta said:

@pixdriftI will raise my PR when I am ready. But for the SPI change, could you please raise the PR yourself?

Hi @Gunjan Gupta, I am having a difficult time following the logic here.

You want me to add a single character change PH5 -> PH9 to a new PR, rather than adding it to your PR for orangepi fixes?

I will raise it now.

[pixdrift]

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 February 1 by pixdrift

[pixdrift]

This is from the H616 data sheet from here:
https://linux-sunxi.org/images/b/b9/H616_Datasheet_V1.0_cleaned.pdf
 

@Stephen Graf can you run me through this pin change? I believe I originally took it from your overlay, and there was some discussion about it.

In the kernel sun50i-h616.dtsi there is the following which both define PH5:
 

			i2c3_ph_pins: i2c3-ph-pins {
				pins = "PH4", "PH5";
				function = "i2c3";
			};



			/omit-if-no-ref/
			spi1_cs0_pin: spi1-cs0-pin {
				pins = "PH5";
				function = "spi1";
			};

 

My concern is the sun50i-h616.dtsi for spi1-cs0-pin matches what the datasheet shows for SP1_CS0 , but we are proposing a change to PH9.

What was the rationale here? was it that the datasheet is wrong? Sorry just getting some words together for the PR.

 

Edited February 1 by pixdrift

[Gunjan Gupta]

12 hours ago, pixdrift said:

Hi @Gunjan Gupta, I am having a difficult time following the logic here.

You want me to add a single character change PH5 -> PH9 to a new PR, rather than adding it to your PR for orangepi fixes?

Logic was simple, I was missing the context of the change. A PR is not just a code change. It also documents why the change is made. I couldn't have explained that myself at that point of time. Now that I took a look at the datasheet and orangepizero3 layout and I think I understand now why it was proposed, though I don't agree with the change now.

 

1 hour ago, pixdrift said:

My concern is the sun50i-h616.dtsi for spi1-cs0-pin matches what the datasheet shows for SP1_CS0 , but we are proposing a change to PH9.

What was the rationale here? was it that the datasheet is wrong? Sorry just getting some words together for the PR.

I would suggest to add a new entry for spi1_cs1_pin pointing to PH9. If someone needs to connect two spi devices and don't need to use i2c3, they can still make use of CS0 aka PH5 pin. Just because orangepi's documentation list PH5 as i2c doesn't really limit the pin to be i2c only. It will still be possible to use PH5 as SPI1_CS0. Hence I suggest to add entry for SPI1_CS1 instead of modifying SPI1_CS0.

 

[Stephen Graf]

8 hours ago, Gunjan Gupta said:

though I don't agree with the change now.

@Gunjan Gupta @pixdrift

 

 

This is the data that most users would go by when trying to set up the orngepizero2/3.  It clearly shows that the cs for spi1 is PH9.  If one tries to enable both i2c3 and spi1 with the current dts one will get an error due to the conflict with PH5.   If I only enable spi1 I will have an issue because I would expect cs to be on PH9 and not PH5. There is no reason to leave this kind of confusion uncorrected.

 

My original solution was to put the change for cs to PH9 in the overlay that enables spi1.  I have tested that. What is happening to the overlays?

 

Yes it is possible to set up multiple uses for the SOC pins, but to keep things simple, the software should initially conform to what the diagram shows.

[Gunjan Gupta]

33 minutes ago, Stephen Graf said:

This is the data that most users would go by when trying to set up the orngepizero2/3.  It clearly shows that the cs for spi1 is PH9.  If one tries to enable both i2c3 and spi with the current dts one will get an error due to the conflict with PH5.  This should not happen. 

There are two chip select pins for each spi interface on H616, infact that is the case for most Allwinner boards. User can choose to use either one of them or both of them. You are hung on the idea of enabling everything as per orangepi's own documentation and hence you think both i2c3 and spi should be enabled out of box. Yes both can be enabled, but user has to select chip select 1 to do the same. 

 

33 minutes ago, Stephen Graf said:

What is happening to the overlays?

Work in progress. If you see my activity on git, jira, discord and forums, you can easily see I am working on multiple things. I am almost working more than 40 hours a week making changes and testing things for Armbian. And as I said before community support device is not at the top of my priority list. 

 

If the overlays would have implemented the same way as H6, then this could have been easily handled in armbianEnv.txt by setting param_spidev_spi_cs=1. Also we could have document this on download page as well. We could have stated there that orangepi's documentation is incomplete and it doesn't show all possible config options. 

 

[Stephen Graf]

1 hour ago, Gunjan Gupta said:

you think both i2c3 and spi should be enabled out of box.

I previously suggested and then retracted the idea of enabling out of the box.  I do not think a separate PR is required to change PH5 to PH9.  It should be done with overlays.

 

My current thoughts are that the overlays should be set up to allow the end user the ability to enable and have working what is described on the picture shown in the previous post. That to me implies an overlay that enables spi1 and uses PH9 as a cs.  There should also be an overlay that enables i2c3. 

 

If there were to be an overlay for spi1 with PH5 for a cs, then there would have to be a caveat that it will conflict with i2c3. I would prefer that this overlay be left as a user provided overlay as it would require additional knowledge on the end user to recognize that it was possible and that there is a potential conflict.

[Gunjan Gupta]

9 minutes ago, Stephen Graf said:

My current thoughts are that the overlays should be set up to allow the end user the ability to enable and have working what is described on the picture shown in the previous post. That to me implies an overlay that enables spi1 and uses PH9 as a cs.  There should also be an overlay that enables i2c3. 

 

If there were to be an overlay for spi1 with PH5 for a cs, then there would have to be a caveat that it will conflict with i2c3. I would prefer that this overlay be left as a user provided overlay as it would require additional knowledge on the end user to recognize that it was possible and that there is a potential conflict.

I did said we can document whats needed on the download page. If required, we can even add a picture giving full list of features that will be available on headers that will correctly show 2 spi pins. We don't have to follow what shown in Orange Pi's documentation. If user would be so hell bent on following Orange Pi's documentation, they would most likely be using Orange Pi's images. After all their documentation also says how to flash their images. They won't come to Armbian.

[pixdrift]

-edit-

Removed comments abut PR process and taken to PMs to focus on technical discussion here.
 

5 hours ago, Gunjan Gupta said:

You are hung on the idea of enabling everything as per orangepi's own documentation and hence you think both i2c3 and spi should be enabled out of box. Yes both can be enabled, but user has to select chip select 1 to do the same. 

 

On this comment, I think it's a fair position to expect the board to operate as per the manufacturer's documentation out of the box.

Can we not configure spi1_cs1_pin as PH9 as suggested (not touching the spi1_cs0_pin PH5), and then use that for spi1 out of the box?

Edited February 1 by pixdrift

[pixdrift]

Latest PR from @Gunjan Gupta is here if anyone is available to test, this adds overlays which has been discussed at length in this thread.
https://github.com/armbian/build/pull/6241

I have also built an image of this PR6241 if people want to test, it's available here:

https://armdev.pixeldrift.net/orangepi/zero3/pr_testing/PR6241_20240202_9a1950d37_Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.3.tar.xz

[pixdrift]

My first review of this PR6241 is that it contains a lot of non-zero3 configuration that will only confuse end users.

I still maintain my position that this approach isn't best for end users, and a board specific overlay file is a better solution, even if it comes with more overhead.

The current list is confusing to me, and I have spent a lot of time with the board, I can't imagine what a new user 'just wanting it to work' would think when presented with this list of options. Additionally, this list will only increase with this approach as more H61x boards are added.

I understand your viewpoint @Gunjan Gupta, but I respectfully disagree with this approach. The amount of burden (managing more board specific overlay files) put onto developers in Armbian is far better than the impact that including all boards has on the user experience (UX) for (potentially inexperienced) end users using armbian-config. I can't think of a good reason for anyone developing a product to intentionally make the experience worse for users to save a small amount of time (and disk space) for developers.

 

Another potential option is to update armbian-config to support more complex filtering, or the option to pass a list of overlay filters in the configuration file to allow a board to specify the generic/shared h61x overlays, and then also some board specific ones, but in the interim, I would prefer to avoid the path PR6241 is taking, even if we only make that change for Zero2 / Zero3 for now so we can protect the user experience for these specific boards.

Edited February 2 by pixdrift

[VioletGiraffe]

Hi. I'm new to Armbian and Linux development, and first of all I want to thank everyone who supported Armbian for Zero 3 and made it work.

What is the current state of things - when building from source, should I use the Armbian trunk or should I use a PR/fork? And what are the recommended options for the compile.sh script?

 

The reason I need to build from source and not just take the nightly built image is that I need to make the TV out (composite / analog video out) work. During your work, has anyone come across any code / patches that might help me activate the TV out?

Thanks!

 

P. S. I will have the Zero 3 on hand in one or two days, can I help with testing anything?

Edited February 3 by VioletGiraffe

[ag123]

@VioletGiraffe Orange Pi Zero 3 is still in *test* phase, review the many comments above e.g. from @pixdrift, @Gunjan Gupta, @Stephen Graf et.al. , if images links are embedded in comments, those are *test* images if they are listed for now.

 

the rolling release images can be found here:

https://github.com/armbian/os/releases/latest

 

do try them out and add your comment as feedback in this thread if you tried it, providing info such as your board , memory size, the image used etc.

what works and any issues if you discovered it. 

 

but practically speaking, support for Orange Pi Zero 3 is really / practically *reverse engineered*, even the dram controller is *undocumented* and it is an 'best effort' that it works (many things are wild guesses e.g. trials based on other chips e.g. H616 and 'they happened to work'). Hence, the images would likely always be *use at your own risk* even if it becomes 'community' support.

 

 

[VioletGiraffe]

I know, I've read 80% of the topic, except for a couple pages in the middle where it got too technical and you were discussing features I don't care about.

 

As I said, I need to compile my own image, so what is the recommended revision / PR, and what configuration/compilation options can you recommend?

Since you linked to the "releases" page of the main Armbian repo, I assume that building from the top of the armbian/build repo should be ok and no extra patches are required?

[Stephen Graf]

4 hours ago, VioletGiraffe said:

I need to make the TV out (composite / analog video out) work.

Unfortunately I don't think there has been any work on the TV out.  Not even Zunlong supports TV out.  From the Zunlong zero3 manual:

 

 Analog audio and video
output interface
Supported, it can be used to connect headphones to
play music, or connect to TV through AV cable to
output analog audio and video signals (Android
system only).

 

Using the main build for Armbian would thus be as good as any place to start.

[pixdrift]

Welcome @VioletGiraffe, thanks for joining the forum and letting us know you can test

Must be quite a journey reading the whole thread for the history now, well done 

In terms of video out, I don't think there has been any specific focus on it and as @Stephen Graf may not be currently supported, but keep an eye out for updates here.
 

I think mainline is good to build off currently, there are no big PRs pending except the Overlay work which may not interest you as it's GPIO related. The options vary based on what OS you're using, but I generally use Edge Kernel, Debian OS and XFCE Desktop options for testing. I can be more specific if you need

[Gunjan Gupta]

7 hours ago, VioletGiraffe said:

During your work, has anyone come across any code / patches that might help me activate the TV out?

TV out might work, its not tested though. The DTS changes for the same was part of HDMI changes that were merged. But there is no audio support added yet so you will not have any audio.

[Gunjan Gupta]

23 hours ago, pixdrift said:

Another potential option is to update armbian-config to support more complex filtering, or the option to pass a list of overlay filters in the configuration file

I did suggested that we can do this on your PR. But you and Stephen seem to be more interested in taking shortcuts than adding value to Armbian by improving its tools.

 

23 hours ago, pixdrift said:

The amount of burden (managing more board specific overlay files) put onto developers in Armbian is far better

Better how? You will most likely disappear in couple of months, who will maintain that shit load of overlays then? The list of patches are at 400+ at the moment. It use to be 600+ I brought it down and removed what was not needed. There are more patches that might not needed but I don't have time to thin them further. You think it will be easy to maintain everything for the developer if things keep on increasing?

 

There is almost no one touching Allwinner in Armbian right now. I tried keeping things updated and fixing stuff. Brought some boards back from the dead and shared the feedback based on my experience. But you guys are only interested in shortcuts. The PR is only a step. It was supposed to be followed by an update on download page. I did added a photo in a comment on PR today, I was going to add text describing everything along with it on download page too. That would have helped users as well.

 

Users come to Armbian for the added value it provides, otherwise they would have stuck to orange pi's distro if all they were going to do is follow their documentation. Do you think you can add devices to orange pi zero using their documentation? Most of the hats and peripherals, etc are designed with raspberry pi in mind. Nothing works without porting their raspberry pi compatible overlays to Allwinner compatible one.

[VioletGiraffe]

34 minutes ago, Gunjan Gupta said:

TV out might work, its not tested though. The DTS changes for the same was part of HDMI changes that were merged.

Thanks a lot! If, by some miracle, it happens to work, how would I activate it? Activating the analog out shuts down HDMI. So when HDMI works, it means the analog out isn't working.

I've found there is a Linux kernel config/module DRM_SUN8I_TCON_TOP that might be needed.

P. S. I don't need audio, so no problem.

Edited February 3 by VioletGiraffe

[Gunjan Gupta]

@VioletGiraffeI don't remember the changes I made, but if its status is marked as disabled in dts, then probably yes. For the module, if you are ok to do your own build, you can use "./compile.sh BOARD=orangepizero3 BRANCH=current kernel-config" to modify kernel configuration and then proceed with building the image. Current branch will give you 6.6 kernel, you can use edge if you want to use 6.7 kernel as well. Once you get it to work, feel free to raise a PR

[pixdrift]

2 hours ago, Gunjan Gupta said:

I did suggested that we can do this on your PR. But you and Stephen seem to be more interested in taking shortcuts than adding value to Armbian by improving its tools.

Excuse me? This is a completely absurd statement.

[pixdrift]

2 hours ago, VioletGiraffe said:

3 hours ago, Gunjan Gupta said:

TV out might work, its not tested though. The DTS changes for the same was part of HDMI changes that were merged.

Thanks a lot! If, by some miracle, it happens to work, how would I activate it? Activating the analog out shuts down HDMI. So when HDMI works, it means the analog out isn't working.

I've found there is a Linux kernel config/module DRM_SUN8I_TCON_TOP that might be needed.

P. S. I don't need audio, so no problem.

On the topic of audio, I have started looking at it and should have something working over the next couple of days. The early patches from warmpe merge fine, which is a good sign.. it's just getting the h616 dtsi and dts patches in next.

My working branch is here, which compiles fine with some of the additional patches but board configuration patches aren't there yet.
https://github.com/pixdrift/armbian_build/tree/zero23_audio

[Stephen Graf]

4 hours ago, Gunjan Gupta said:

Stephen seem to be more interested in taking shortcuts than adding value to Armbian by improving its tools.

I am sorry that you have to get personal in this discussion. 

 

Never have I suggested taking a shortcut.  What I am striving for is simplification.  There is a big difference between the two.  I am also trying to improve the end users experience on Armbian, for without end users there would be no need for Armbian.

 

Please stick to criticizing my suggestions and not me. Constructive criticism would be better as it is always more useful in the long run.

[SteeMan]

On 2/2/2024 at 4:55 PM, pixdrift said:

I understand your viewpoint @Gunjan Gupta, but I respectfully disagree with this approach. The amount of burden (managing more board specific overlay files) put onto developers in Armbian is far better than the impact that including all boards has on the user experience (UX) for (potentially inexperienced) end users using armbian-config. I can't think of a good reason for anyone developing a product to intentionally make the experience worse for users to save a small amount of time (and disk space) for developers.

When you have been involved with Armbian for a length of time (and read a few of igor's rants 🙂 ) you will realize why what was said here will not be received well by many within Armbian.

It isn't that what you are saying isn't a reasonable comment.  The problem is that Armbian is under resourced by probably an order of magnitude.  Discussions are continually occurring on how the project can survive let alone move forward.  Many of those conversations involve discussing how more can be done with less resources, ways to cut features/scope to make what exists manageable.  So by you saying to "put [more work] onto developers in Armbian is far better than ..." you are hitting a nerve.  In the current environment that will never pass muster.  Any proposed solution needs to maintain or reduce developer work in the long term.  So any feature suggestion is going to be measured first against that metric, then secondarily by the merits of that feature. 

 

This whole dtd discussion is fundamentally a request for a new feature for Armbian.  Regardless of the merits of your focus on the end user experience, that isn't the way Armbian has handled dtbs in any of the existing boards that are supported.  I'm not saying that what exists is good or desireable, but it is what it is.  Can it be improved, sure.  Can it be improved and at the same time not increase maintenance costs going forward, maybe.

 

[Gunjan Gupta]

38 minutes ago, Stephen Graf said:

Please stick to criticizing my suggestions and not me. Constructive criticism would be better as it is always more useful in the long run.

Yeah sorry about that. I didn't wanted to, but that really is what it seemed like. Armbian's policy as, I understand, is to add support for on board things first. Only after that optional things are handled. And this overlay thing was anyways something that is well documented on how user can add an overlay themself - https://docs.armbian.com/User-Guide_Armbian_overlays/. I already said 3-4 times, once in this thread, once or twice on pixdrift's PR that what you are trying to achieve is something that needs to be in armbian-config. I know it will take a lot of time to develop that.  2 full work days to a week or two depending on the developer. The easiest thing in the short term does seem to be just keep dumping more overlay files. But tell me honestly, is that the right thing to do? Aren't you adding a lot of bloat on the filesystem in the process as well? What would the filesystem look like in say 5 years from now when that folder will have thousands of files when only handful is actually being used. Tell me that no user will come complaining about asking to reduce the same.

[Stephen Graf]

@SteeManI would like to set up discussion on the overly topic.  Should we continue here or start a new thread? I don't think we should be starting to write code until there is a reasonable agreement on how to proceed.  We should also share our ideas instead of pushing them to a PR first thing.

 

Recently @Gunjan Gupta posted this in the current PR he proposed.  It has some good thoughts. We can start with this, see what can be done to make it smooth for the end user and minimize the work required by developers.  I use armbian-config.  I think anyone who takes part in this discussion should confess to whether they do.😊

 

"These are generic overlays, other examples are there in the existing patches and can be extracted from kernel source. There is no other documentation. There never was anything on any platform or OS that provides the behavior you are expecting to have. Even on raspberry pi running raspian, you can add all those hundreds of overlay in the config.txt file and other than maybe having trouble booting, no other kind of indication is given to the user. It was always left for the user to decide what overlays they want to enable, and it was always left to the user wits to determine whether overlay will have conflicts or not.

I understand you want to make it as simple as possible for user to easily determine what overlays can conflict with other overlays. That part can not be implemented within overlay itself. Thats something that needs to be implemented in armbian-config. armbian-config also lacks one other thing, it doesn't tell users overlay parameters are there and what their values can be. So it is long due for the change. Here is a proposal for how this functionality can be implemented

Extend armbian-config's hardware configuration to two different configurations i.e lets say one file is for SoC overlays listing all existing overlays that can be applied on that SoC, their corresponding parameters and the possible values for the same. Also mentions the overlays that can conflict with each other. Second config file will be board specific configuration file providing a list of overlays that can be used on that board. Then extend armbian-config to use that information and provide the behavior you are expecting user to get."

 

Here are some of my current thoughts.

It may be possible to provide a full list of overlays without modifying  armbian-config.

I am glad to see that @Gunjan Gupta has acknowledged that a board specific file could be used.

 

There is an Armbian cli procedure that @Gunjan Gupta showed me that I think takes a dts and creates a dtbo and puts it in ArmbienEnv which will then load at boot time.  I think a dts can have comment lines.  If we created the dts files for the secondary overlays with suitable comments within the dts file that warned about possible conflicts, pins that the dts will use etc, and then put these files into the allwinner/overlay directory, it would give the more knowledgeable user the option to install the secondary overlay.  The less savvy user could just use the primary overlays provided by armbian-config.

 

This design would not require any work on armbian-config.  The dts files for the secondary overlays would become the "generic" overlays. I am not sure how to get the secondary dts files into the allwinner/overlay directory, but hopefully this is a patch procedure.  Any new dts files would require a patch anyway.  I don't think it is necessary to go back and modify overlays for the existing SBC.

 

Anyway, I am sure there are multiple solutions and this is possibly one for discussion.

[Werner]

24 minutes ago, Stephen Graf said:

Should we continue here or start a new thread? I

Open as much topics as you need. That is what forums are for. I don't like those multiple pages long mega-threads anyways but for some reason some users seem to be fine with them. As for me at least I don't see how value information can be found within when there is a need to read page by page by page while with multiple topics you immediately see what's going on inside

 

24 minutes ago, Stephen Graf said:

modifying  armbian-config.

There should be as minimal adjustments needed as possible since this tool is undergoing major rewrite anyways so besides having it as a working proof-of-concept for the new version it would be a waste of time.

 

3 hours ago, SteeMan said:

When you have been involved with Armbian for a length of time (and read a few of igor's rants 🙂 ) you will realize why what was said here will not be received well by many within Armbian.

Haha, true story.

Anyway as bad as some rants (not only Igors ) read there is always some truth within and the truth often is either misunderstood or hurts or both.

Therefore no further action is taken here besides asking everyone to calm down if necessary and keep it more constructive, alright? ->

 

Oh boy, that was a lot of off-topic

[Gunjan Gupta]

2 hours ago, Stephen Graf said:

pins that the dts will use etc,

I believe it would be possible to extract that information even from a compiled overlay. Though it will require something like https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/dtmerge/dtmerge.c. The idea is to create a merged dts and then look at which node changed. Once that is known, that node's pinctrl property can be use to locate the pins in use. Knowing pins in use allows to track conflicts. This will take time to implement in one place which will still be way less than the time that will be required to update each and every overlay that exists in Armbian.

 

Also having something like dtmerge available can make it possible to dynamically test if a overlay will apply on the current devices dtb. The information can be extracted once either as kernel post install script or whenever the user goes into the armbian-config menu and we find that information that was previously extracted is not for the running kernel. Both approaches have their pros and cons, so I will leave that for the implementer to decide.

[going]

A short comment on the discussion.

 

I never use armbian-config. It doesn't help me figure out the essence of the problem.

I am considering the overlays that are provided by Armbian as a template for possible use.
A script that switches something can be harmful. I'm just turning it off.

Next, I pull out the DTB from the working system, which was actually applied.

 

I open the schematic diagram of the printed circuit board and the schematic diagram of the device that I want to attach to the board.

I write out the available pin numbers in the table that I could use.
I take an overlay file found on the Internet or an existing one as a basis and rewrite it to suit my needs.

 

Next, compile this file, add it to the download and check its operability.

This algorithm ensures that nothing superfluous appears in the applied device tree.

 

We can add a lot of automation. We can even connect neural networks to recognize circuit diagrams.😁
But an experienced user will still try to get around (ignore) all this.
And an inexperienced user will not understand why something is not working for him.

He just did not extract the DTB from the running OS and he does not see the real state of things.

 

It seems to me that helping the user to start thinking with his own head is the best solution.

[Gunjan Gupta]

2 hours ago, going said:

It seems to me that helping the user to start thinking with his own head is the best solution.

I have the same experience based on my last 7 months of being here. I totally agree with you.

 

I also don't disagree with the idea of making it simpler for the non-techie user as long as its not something that is going to increase development and maintenance burden for Armbian. I know no matter how simple we make for them, a lot of them will just try it once and will say its easier to do things on raspberry pi and move on. Simply because its easier for them to find guides for it and they are more geared towards end result than the learning they gather in the process.