Gunjan Gupta

MRAA doesn't depend on sysfs. Its intelligent enough to choose either that or /dev/gpiochip* device Simpler method if you wish to try - https://github.com/eclipse/mraa/blob/master/docs/jsonplatform.md Example file for the same - https://github.com/eclipse/mraa/blob/master/examples/platform/turbotjson.json create json file, export MRAA_JSON_PLATFORM=<path_to_json_file> and you should have it working

Another possible library to try - https://github.com/eclipse/mraa And a sample implementation if you wish to develop and merge support upstream - https://github.com/eclipse/mraa/pull/1111

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.

Ah..I see whats going on here. The nightly images uses unreleased OS versions. Debian trixie is to be released next year, and Ubunu Noble will not be released for another 2 months. Hence docker doesn't have a repository for them yet as can be seen by going to - https://download.docker.com/linux/debian/dists/ Install docker.io package using apt instead of following the docker installation guide.

Yeah speaking from personal experience, he didn't meant to offend you. He uses an online translator so I guess if message appeared rude, that is not his fault. He was only trying to help FTDI232 and FT232 is actually the same thing. its just printed differently on different chips. But as I said before, anyone of the adapters will be fine. Some boards require to communicate at very high speed and thats when generally we have to be careful in choosing the uart adapter. But this board uses standard 115200 bps rate. So any adapter can handle it.

I would suggest you to try latest rolling release from https://www.armbian.com/orange-pi-zero-3/

Just checking in if we reached a conclusion. Do we have a root cause? Are we concluding that the issue was due to DRAM_CLK patch?

is there any output on serial console?

Yeah, I think anyone of them should do. I am personally using one thats based on FT232R. In the video I think its mentioned to use one based on CH340C, CP2104 or FT232R. But anyone should work fine for this board.

The difference is mostly in what handles the process. As you already discovered startx doesn't ask you password. Thats because you already logged in and desktop is being started for your user only. If you are familiar with old run level concept, "Systemctl isolate multi-user.target" is like calling telinit 3 and "Systemctl isolate graphical.target" is like calling telinit 5. Desktop is started for all users. Anyone who have access can login.

May be Software Updater is not installed? Anyways rolling release is based on distributions that are not even released yet. Debian Trixie will release next year. Ubuntu Noble will release close to end of April. So bugs in those distributions are kind of expected. May be shortcut is not defined. Not sure, I have to check and come back to you That is weird. I wonder if its the wrong ram size detection thing that I mentioned. Only way to tell is by using serial console and looking at the output. So if you can share the same, that will be great

Thats news to me. Could you please share more details? I don't personally use them. I had bought a smart extension board with 3 power sockets and 3 usb about 5 years back, but the company went downhill, so their servers are now down. I have a plan to hack it though and add my own firmware on it. Similar to most smart devices sold in my country, its using a ESP8285 based module. Just need enough time and boredom to work on it. Its now working as a normal extension board. Just buy which ever brand you trust. They are mostly all the same.

ok...maybe just forget about systemctl isolate and use startx to start the graphics. Then you can simply logout.

We have a release coming. Its scheduled for this month end. Once its released you should be able to use the 24.02 images. There is nothing wrong with using rolling release either. Just you will be getting more frequent updates. On possitive side you will be getting the features before people using the release. On negative side, in extremely rare scenarios, the board may crash. But its rare. If you are not going to be physically there, make sure to use ethernet for networking, don't use wifi. Audio support is not there yet and will get added sometime later. I noticed this issue on Orange Pi Zero 3, not sure if its there on Orange Pi zero 2, but sometimes when soft rebooting the board, board hangs after reboot So those are some caveats right now. If you can use a smart power socket for controling power remotely, I will highly recommend to use the same. We are continuously improving things. As you can see we added support for HDMi and wifi since last release, but with limited resources the progress is bit slow. Things will improve further over future releases.

There can be multiple ways. Here is one of them. Use a desktop image. Then run sudo systemctl set-default multi-user.target This will prevent the desktop to start by default To start the desktop, run sudo systemctl isolate graphical.target To stop it again run sudo systemctl isolate multi-user.target

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.

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.

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.

Its possible I think. I have a s805x based tv stick lying around that also use to use uboot for burning tool. I had seen that by monitoring serial output while I plugged my device to the computer trying to connect it to burn tool. I guess it might be something that the OEMs can choose on how to implement. Mine was made by sdmctech. I don't have original firmware for it. I tried dumping its firmware, but the first few blocks always got dumped in some mangled/encrypted form so I never tried to hack it further.

Text from download page

I fixed that too when I migrated uwe5622 to the extension. its the uwe5622 driver causing the cpufreq to crash and lscpu call hangs because of that. This is already discussed in other threads for orange pi zero2

@highlander0681If you are expecting hdmi, use the image from the rolling release section of the download page.

I added the hdmi just about a month back, remember? It was not there before.

@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

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