Gunjan Gupta

Can you share the uart output? That will tell the reason why it keeps on rebooting.

I have a plan to replace the driver with the newer driver but I won't do it for next release which is next month. The current one I believe was forward ported from 4.9 bsp kernel and is heavily patch to get it working with latest kernel versions.

Shot in the dark - https://unix.stackexchange.com/a/171925

that depends on what function calls that function. You can't say for all spi devices in the world that their drivers won't try to attach a callback Not asking you to prove anything. Just saying don't change things if they are not needed to be changed. Whats wrong with that? It was a simple advice. Not sure why you are getting all fired up on it.

From https://docs.kernel.org/driver-api/driver-model/driver.html So it can be called multiple times. This is exactly what those if blocks were for i.e. to make probe be called again in the future if the condition is met

I am not concerned about logging. The log statement that you added is fine. The logs that you moved above the if block that checked for defered probing I think were not supposed to be moved and will just cause unnecessary noise. But anyways, other than filling up couple of lines in dmesg, they won't do any harm. if its not required, lets skip this change. If you have any other Allwinner SoC make sure to test them as well when making those changes to ensure there is no regression. If you don't have it, then I will test it once you will raise PR against Armbian repository.

Actually its quite easy to reproduce and already fixed for next release. The problem is caused by sprdwl_ng module aka uwe5622 wifi driver. For some reasons, It creates problem for cpufreq-dt when its loaded pretty early during boot process like using /etc/modules. This causes cpufreq-dt to crash and any attempt to check information about cpu like running lscpu simply hangs. I remember seeing that resize service also does some checks related to cpu and hangs when cpufreq-dt crashes. If possible, Use images from the nightly/ rolling releases section of the Download page. They will work fine.

@krrmbnWere these boards using a fresh image or were they upgraded from some previous version? if they were upgraded, check if /etc/modules list a module like sprdwl_ng. If yes remove the same. Then enable aw859a-wifi.service service for wifi support. Now reboot and your problem should be resolved.

Well.. Stephen is the maintainer for the board. Csc got automatically renamed when he opted for it. But someone has to modify the download page. @Stephen Graf I believe Igot would have given you access to edit that page as well. Just check in your emails to see whether you got a email to create account in Armbian Wordpress. If you did and have created the account, you can update the download page yourself

@MrKAre the changes in sun6i_spi driver required? I see in first patch you have moved some logging statements around and added a new statement. In the second patch, you have changed from DMA_PREP_INTERRUPT to 0, I am not sure what the original value was. But does it work fine without changing the spi driver? I am asking as the same SPI driver will be in use across a lot of Allwinner SoCs and hence I will like to avoid making change to it if its not necessary.

@Stephen GrafI can see images on Download page. Could you please recheck?

If you are able to login to the system. Please share the output of dmesg and "ps aux --sort=-pcpu"

I am sorry if I caused any confusion. But my patch was for H6 SoC not H618. The issue is on Orange Pi 3 LTS and not Zero3

I didn't knew you were looking for it. I fixed a bug in the detection routine for H6 and could have pointed you to the same. My patch didn't made into U-boot, but its used in Armbian to fix boot issues for Orange Pi 3 LTS and Jernej also uses it for CoreElec. The memory size detection IIRC happens by varying two parameters called rows and cols. The test includes writing 2 values one at the start and one at the end of memory size being tested and then its read back and compared not to be same. I am not 100% sure on how that helps in determining the size but it does work. In case of H6, I am guessing there was some synchronization issue that caused the test to not work properly so I added a barrier and some delay that solved the issue.

DMA related changes looks good. I have the same changes in my local git as well. One thing I do suggest is to add dma to spi0 as well. Currently you have only added it to spi1 I am afraid I don't understand. Linux kernel will not be aware of the existence of overlay as they are applied by uboot. Unless ofcourse you used sysfs to load the same which is not the preferred way anyway. Do check uart output to see overlay was indeed loaded by u-boot and there was no error.

Is it too much to ask to wait so that I can get some time to work on this? I have seen your changes. Wait for some time to see what I had in mind and decide after that. Until then you have your fork and your builds. So forgive me if I don't understand why its so urgent to have this right now. Please just wait ok. I am maintaining 10 boards juggling multiple tasks. I can't simply keep on replying trying to explain what I have in mind. This is distracting me from focusing on other issues that need my attention right now.

Alright let me give you an example of cases where a generic overlay will be helpful. There can be cases where someone will just add a board that they have to armbian and disappear afterwards without adding overlay for it. Now users will come to the forum asking for what overlay they can use to enable i2c for example on header and such. If we have generic overlays, then the same can be avoided. Also its makes adding new boards easier for the same soc easier. Overlays will already be there and just can be straight forwardly tested or tweaked for the new board. Thats where fixup scripts and parameters come in. You can see we have a lot of parameters for spi overlays for other socs like H3. Those gets documented in the readme file. User enables the overlay and add parameter in the armbianEnv.txt file. I do agree this can be further improved and armbian-config can be made to handle those parameters with some work, but it is still better than have 10+ overlays per board for say for say 5-10 boards per socs with 5-10 socs per kernel. You can imagine the amount of files that will be there if we keep adding overlays per board per soc. Also imagine if something changes in mainline kernel and due to that you need to say add a new configuration value to the overlay. How many files would need to be checked and modified?

Any contribution is more than welcome.

Build system supports building using docker. When using the same, you neither require root nor you require sudo IIRC. Also if you only wish to compile kernel, you can use "../compile.sh kernel BOARD=<board> BRANCH=<branch>". That will only compile the kernel Series.conf and series.armbian. If you don't wish it to go missing on next major kernel bump

If I remember correctly, we generally have a README file in /boot/dtb/overlay listing all possible overlays for an soc and the parameter they support. So that should be fine. Besides these are header pins we are talking about. Anyone wishing to use it, unless they are using something simple will be writing their custom overlays for their electronic component anyways. For example if someone want to add a screen, they have to write a dts overlay for that. By default most things that are sold only provides overlays for raspberrypi. So I am willing to take a chance that the user who wants to use those headers would not be technically challenged and will do some homework themself

I thinks it would be ok. Its a CM4 like board, so having more overlays for it won't hurt in anyways I think

The way I see it, the summary from last PR is that I want to keep overlays generic to avoid duplicate future efforts. While pixdrift and Stephen Graf wants to keep things specific only to zero2 and zero3 which would mean there will be duplicate efforts needed in the future. And thats where we had the deadlock in the last PR.

There is no need to bring bigtreetech CB1 into the picture. Its a special case. It was added and maintained by Bigtreetech themself. They also have partnered with us and their funding allows us to spend sometime on Allwinner boards. Otherwise Allwinner boards just acts like giant blackhole that has the most of Armbian users and yet brings almost zero funding to the project.

I created the download page for it. So it should be even easier now - https://www.armbian.com/orange-pi-zero-3/

There is actually no need to build the image yourself. You can just download the latest nightly release from https://github.com/armbian/os/releases/latest