Stephen Graf

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

@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.

This works on my orangepione. I think dtc comes with the standard image. Armbian-unofficial 23.11.0-trunk Bookworm with bleeding edge Linux 6.6.1-edge-sunxi sysadmin@orangepione:~$ nano screen.dts sysadmin@orangepione:~$ dtc -I dts -O dtb -o screen.dtbo screen.dts sysadmin@orangepione:~$

What are you booting from? I use an SD card with the up to date image which works just fine. There is no boot partition in the image, just a boot directory. Can you try an up to date image with and SD card? The fel firmware would be part of u-boot that is on the Armbian image.

@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.

Why am I seeing this: https://www.armbian.com/orange-pi-zero-2/ Maintainer needed?

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.

Igor fixed the problem that was probably part of the "glitch" on the last release.

@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.

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.

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.

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 @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 Should @pixdrift issue a PR to change the value for the legacy, current and edge to 17?

On orangepizero3 I tested with just changing CONFIG_LOG_BUF_SHIFT=17 and it worked well. Using a setting of 15 still had missing messages. I saw that most other boards in the Armbian distro had settings of 17 or 18 and I think one was 19.

Well I found it by asking for kernel configuration changes during the build setup. I think the original values were 15 for 17 and 12 for 15 but I can't remember for sure. Anyway with the new values I can see the beginning of the dmesg and journal does not report missing messages. However the extra data did not show anything to help me with the bluetooth problem. x General setup ---> x (17) Kernel log buffer size (16 => 64KB, 17 => 128KB) x x x (15) CPU kernel log buffer size contribution (13 => 8 KB, 17 => 128KB)

I think I retracted my proposal to enable all the hardware and just skip overlays. Armbian-config Hardware and overlays are very useful. My concern from the beginning has been the issue of overlays being "generic". Dts is a definition of the hardware on a SBC. Obviously the SOC is the major piece, but there are other items that need specification, memory, gpu, power regulator, ethernet phy, etc. Because these other items are unique to a SBC, the dts takes the name of the SBC, not the SOC. There is no such thing as a generic dts. Now since overlays are simply modifications to a dts it is logical that overlays should also be unique and tied to a specific dts. There are many overlays that are common among the SBCs just as many dts' share common dtsi, But the fact remains that the dts has the name of the SBC and I suggest that the overlays follow this naming convention. I think this would simplify creation and certainly testing of overlays. Fewer patches would be required and testing would be limited to the overlay for the SBC being worked on. If this approach were taken it would not require rework of the existing overlays that already work.

I'm still trying to find where to make the change. The internet message was from 10 years ago! I did not want you to rebuild, just start up zero2 and do a dmesg to see it it starts at time 0 or about .6 sec. Just to see if the problem is specific to zero3 or both.

@pixdrift Would you please look at dmseg on your orangepizero2 to see if it starts at time 0. I came across this in the internet: Your kernel's ring buffer ran out and the first entries were removed for new entries. Simply set CONFIG_LOG_BUF_SHIFT and CONFIG_LOG_CPU_MAX_BUF_SHIFT larger in your kernel config. yeah now works with 19! ~ $ cat /usr/src/linux/.config | egrep CONFIG_LOG_ CONFIG_LOG_BUF_SHIFT=19 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12

I am asking for help in resolving an issue with dmesg and journal not starting at time zero on the orangepizero2. I don't' know about the zero2. I am actually trying to determine why bluetooth only works on the initial boot and never again after a reboot. I am booting from spi flash to a usb hard disk. The dmesg started at time .03 sec on the initial boot and only at time .6 sec on the second boot. In previous investigation I noted the journal indicates missing about 150 messages on boot. I am not sure if the missing data would help in my bluetooth investigation, but I feel very uncomfortable without the data. I have no idea of where to start looking at the missing data problem. An armbianmonitor -u has been uploaded: https://paste.armbian.com/isajocaper

Orangepizero2/3 are using spi0 internally to connect to the 16MB flash memory on the boards. Spi1 is available and should be enabled by a working overlay in the near future. In the meantime if you can find the driver source, it should be easy to change the spi port and cs in the code as they are usually just definitions. As an aside, if you are looking to use a tpm for secure boot, you should be looking at u-boot and not Armbian.

@MrK I think you owe @Gunjan Gupta an apology. There is no need for such language when people are volunteering their time and efforts, or ever for that matter. @MrK you are in the wrong forum. Changes such as you are proposing should be done at the Linux kernel level. @MrK I am not sure the following comments are worth posting. But if it helps you, I would recommend that you learn to work with others in a team environment. You will get more things done and with better results. If you had been working for me I would have fired you for behaving this way. It is just too disruptive.

I think this was meant for @SteeMan attention. I was following this discussion and I think the discussion should be going on upstream not at the Armbian level.

For hardware work I find 1GB is plenty. As Bill Gates once said "who needs more than 512KB".

When I was working with u-boot to test the orangepizero3 implementation there was an issue with memory size not being detected properly. The issue was resolved by raising the default memory speed parameter to the value recommended for LPDDR4. I have not seen an reported problems since then.