Stephen Graf

I think the bigtree board is the one that is causing all this conflict. It is a very specialized board built for a specific function - to run 3D printers. Bigtree paid Armbian to set up the image and they got the paid treatment regardless of the compatibility with other boards. I suspect future h616 and h618 boards will be much more alike and not similar to the bigtree board. As for the devices that hang on the spi and i2c buses, there are hundreds of them. Go to AliExpress and search for "i2c device". There is no way to provide overlays for each of them. My suggestion is to provide overlays for the the main i/o that the SBC advertises and brings out to the headers. If users want to implement some of the other muxed functions then it should be the users responsibility to provide a user overlay which does not impact the build environment. Yes there will be many overlays that are common between boards and yes there will be some overlays that are not. The difficulty is how to deal with the overlays that are not in common.

@Igor What is the status of the orangepione? On the download page there are no images presented yet in the build framework is shows up as "conf" in the support (1st) page.

@Gunjan Gupta Yes I can see that you are trying to take on too much and no I don't think this is that urgent. However in the interests of moving forward, is there anyone else who would have some cycles to deal with this? I would like to follow your proposal and stay with the existing naming convention for the time being. As the orangepizero3 is the first h618 SOC, in keeping with the existing procedures we should create a new overlay structure called sun50i-h618. I could recreate the patch for the overlays (5) that I think are useful for the zero3. Then by the time new h618 boards are added you may have had time to revisit the whole issue. In the meantime let others do the work. This change will not impact any other board. As I am proposing to stay with the existing procedures. I don't think this patch will require any significant time from you. I can see from @SteeMan comments that trying to improve things will be a big headache. What do you think?

@ag123@Gunjan Gupta@pixdriftLet's try to go back to fundamentals to see what we are trying to resolve with the overlays. I will try to give you an idea of what a hardware developer would think about when deciding on a specific SBC. The SBC designer will have made some choices as to what i/o will be available on the board. The SOC has numerous options of which only a few will be implemented. The hardware developer will look at the array of boards available and choose one that readily provides the functions that he thinks he would need. I chose the orangepizero3 based on the availability of i2c (aka twi), spi and gpio which is very similar to the orangepione that I have a lot of experience with. My problem is trying to get this i/o enabled via the usual armbian-config procedure. @Gunjan Gupta has taught me how to write overlays and I have been able to patch the dtb directly to get the i/o working. But that is not the preferred procedure. In the process I have come to question the rational of tying the overlays to the SOC instead of the SBC. Should the overlays for orangepizero3 be labelled sun501-h618? That would be an easy solution for today as there are no other h618 boards. I think the bigtree board should not have been allowed to use the label sun50i-h616 for its overlays as that board is a very specific implementation for a particular environment. After further reflection I don't think enabling the i/o in the dtb is the best idea. It is usually better to keep things turned off if not in use. @pixdrift Think of your problem with the half plugged in serial to usb adapter. In a similar vein I would recommend that gpu, bluetooth, wifi and hdmi not be always enabled. Many users will run a headless server using these boards and all these unused devices add a lot of software overhead in addition to the extra power drain and associated heat generated. I am not sure this moves us further along in resolving the issue, but I hope it provides some stimulus for thought.

@MrK Try the spidev_test tool. It has many options to set various parameters such as speed. https://github.com/rm-hull/spidev-test/blob/master/README.md

@pixdrift Thank you. I will test current on zero3. I don't think zero3 is supported on legacy. I have a monitor with hdmi and audio and can test sound over hdmi on zero3. I can also test analog sound from the header if the sound fix works for both.

@pixdrift If you want to proceed with a PR please go ahead. If you apply the patch to your repo I will build and test on current for the zero3. I still have concerns with a number of items that might be related: - Bluetooth only working on the initial boot - pinctl errors on boot - dmesg log not starting at time 0.

@MrK You should try the build from @pixdrift (edge only). https://github.com/pixdrift/armbian_build/tree/zero23_spi_menufix There is only one overlay item for spi, spi1, PH6,7,8 and cs0, which is on PH9 as per the orangepizero2/3 drawings. I have not put a scope on the pins but tested with spidev_test and a loopback on SI/SO which returns the correct data. I also put a meter on PH9 and it goes high during the test.

@pixdrift If your serial to usb adapter is not connected on the usb side, where is it getting power from? This could be a cause for possible garbage characters appearing on the input of the serial side that would stop u-boot. It is also possible for the serial side to oscillate (if not powered) just from the voltages on the output pin and u-boot is trying to decode a lot of garbage. Bus usb@5200400: USB OHCI 1.0 scanning bus usb@5200000 for devices... 2 USB Device(s) found scanning bus usb@5200400 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Autoboot in 2 seconds, press <Space> to stop Card did not respond to voltage select! : -110 Regarding an overlay for the leds. Currently in the dtb the leds are defined as: leds { compatible = "gpio-leds"; led-0 { function = "status"; color = <0x01>; gpios = <0x14 0x02 0x0c 0x00>; linux,default-trigger = "heartbeat"; }; led-1 { function = "power"; color = <0x02>; gpios = <0x14 0x02 0x0d 0x00>; default-state = "on"; }; }; What would you propose? Overlays can add or change existing lines. They can not remove lines. My recommendation is to just leave them as they are. There is a option to add user defined overlays. Check out the /boot/boot.cmd: for overlay_file in ${user_overlays}; do if load ${devtype} ${devnum} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then echo "Applying user provided DT overlay ${overlay_file}.dtbo" fdt apply ${load_addr} || setenv overlay_error "true" fi done There is a catch. If the user overlay messes up the dtb is restored to the state before even the kernel overlays have been added! I think I would like to prepare the overlay patch as a PR to the Armbian master.

@pixdrift Comparing the debug console of the first boot and of a failed startup would be a good place to start. Have you tested on a zero3 with the fast SD? I'm sorry I can not help with the zero2. I am going to test with my hard drive again. If you need to cool things down, I could send you some snow. We had our first snowfall here today, about 20cm.

@pixdrift, @Gunjan Gupta Yes, the output of the serial debug console would be very useful to see how far into the boot process the system got. The speed of the SD card might be the trigger for the problem you are seeing, but I doubt it is the source of the problem. The system boots from a fresh flash and probably runs quite cool until a second boot. I have had an issue with what I think is timing related. I was using a usb hard drive for a system disk and booting from spi flash. The usb disk was twice as fast (40MB/sec) as the SD (17Mb/sec) card. On the initial boot after flash Bluetooth worked properly. After a reboot Bluetooth never worked again (the /dev/bluetooth was not created). I have now put away the usb disk and am using an SD card. I have on occasion seen a failure of Bluetooth on the SD card but am not really checking for it. Another concern I have is that the dmesg log does not start until about 1.6 sec or more instead of 0. This is not right. There is also some problem with setting up pinctl being logged. I dislike testing on a system that I know has problems that could be affecting the testing I am trying to achieve.

I'm curious to see what the zero2 does if you remove overlay_prefix=sun50i-orangepizero2-3 from /boot/armbianEnv.txt. Does it load sun50i-h616 or not find the overlays? On the zero3 it will not find the overlays.

@pixdrift I built an image for the zero3 from your repository and I am not having any difficulties with the overlays. If you think it is the overlays that are causing your boot problems you can try putting your system drive on another machine and removing the overlays line in: sysadmin@orangepizero3:~$ more /boot/armbianEnv.txt verbosity=1 bootlogo=false console=both disp_mode=1920x1080p60 overlay_prefix=sun50i-orangepizero2-3 rootdev=UUID=8b58b731-6024-4fbe-bd3e-c784b3b9a449 rootfstype=ext4 overlays=i2c3 ir otg-host spi1-cs0-spidev uart5 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u Armbian-config creates and modifies this line when you enable/disable overlays. If that resolves the problem try adding overlays one at a time. I would suggest this order: i2c3 ir spi1-cs0-spidev uart5 otg-host

Sorry, wrong patch. Try this one. Moving too fast.arm64-dts-overlay-sun50i-opangepizero2-3-overlays.patch

@pixdrift Attached is the patch and my testing. Can you try it on an zero2. gitdiff.txt overlay_test.txt arm64-dts-overlay-sun50i-opangepizero2-3-overlays.patch linux-serial-test spidev_test

Re: fixup script for orangepizero2/3 I have looked at the script: /boot/dtb-6.7.0-rc7-edge-sunxi64/allwinner/overlay/sun50i-h616-fixup.scr and not being any kind of expert have these comments: The first test is for spi that controls the flash chip. Spi0 is already set up properly in the dtb and I have flashed the memory with u-boot successfully without running the fixup.scr. The second test is to fix up spi1 if it is not being used for the flash memory. This is not necessary as spi1 is already set up in the dtb. Additional setup for spi1 should be done in an overlay. The final six items are for pins that are not brought out on the orangepizero2/3 (pps, w1, pm34 and uart1,2,3 rts/cts) and should not be required. This leaves me with an empty script. Is there an option somewhere to prevent the fixup.scr from running? @Gunjan Gupta I looked at the h6 fixup and the h616 seems to be an exact copy.

@ag123 Thank you for the info. I would like to propose the following overlays for orangepizero2 and 3: - i2c3 to enable - spi1 to enable, create spidev and use cs0 - spi1 to enable, create spidev and use cs0 and cs1 - ir to enable - uart5 to enable - usbotg to set to host I don't know what lineout might require until sound is working. Usb2 and 3 are already enabled in the dtb. Does anyone have any suggestions for the fixup script? I have been running the zero3 for a couple of months without it and have not experienced any difficulties. Suggestions/comments are requested.

I have been able to create an overlay for spidev, copying the Zunlong overlays. An overlay is necessary to set disabled to okay ie to enable the device.

@pixdrift You will need a connection to the console uart to catch the log of the overlays. It all happens at boot time before the OS is started. On the system as root go to armbian-config and then System and Hardware. enable (space) all of the items offered. Then save, back and reboot. Watch the output of the console. U-Boot 2024.01-rc5-armbian (Dec 31 2023 - 01:13:07 +0000) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 1 GiB Core: 57 devices, 25 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@4020000: 0 Loading Environment from FAT... Unable to use mmc 0:1... In: serial@5000000 Out: serial@5000000 Err: serial@5000000 Allwinner mUSB OTG (Peripheral) Net: Unsupported value 13, using default (13) Unsupported value 13, using default (13) eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in MAC de:ad:be:ef:00:01 HOST MAC de:ad:be:ef:00:00 RNDIS ready , eth1: usb_ether starting USB... Bus usb@5200000: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@5200000 for devices... 1 USB Device(s) found scanning bus usb@5200400 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3259 bytes read in 2 ms (1.6 MiB/s) ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 299 bytes read in 2 ms (145.5 KiB/s) 31257 bytes read in 4 ms (7.5 MiB/s) Working FDT set to 4fa00000 268 bytes read in 3 ms (86.9 KiB/s) Applying kernel provided DT overlay sun50i-h616-ir.dtbo 512 bytes read in 3 ms (166 KiB/s) Applying kernel provided DT overlay sun50i-h616-light.dtbo failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND 339 bytes read in 3 ms (110.4 KiB/s) Applying kernel provided DT overlay sun50i-h616-mcp2515.dtbo

Test on orangepi3 of the overlays provided by armbian-config. Not one worked! Working FDT set to 4fa00000 268 bytes read in 3 ms (86.9 KiB/s) Applying kernel provided DT overlay sun50i-h616-ir.dtbo 512 bytes read in 3 ms (166 KiB/s) Applying kernel provided DT overlay sun50i-h616-light.dtbo failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND 339 bytes read in 3 ms (110.4 KiB/s) Applying kernel provided DT overlay sun50i-h616-mcp2515.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does not have a /__symbols__ node make sure you've compiled with -@ 661 bytes read in 3 ms (214.8 KiB/s) Applying kernel provided DT overlay sun50i-h616-spidev0_0.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does not have a /__symbols__ node make sure you've compiled with -@ 661 bytes read in 3 ms (214.8 KiB/s) Applying kernel provided DT overlay sun50i-h616-spidev1_0.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does not have a /__symbols__ node make sure you've compiled with -@ 661 bytes read in 3 ms (214.8 KiB/s) Applying kernel provided DT overlay sun50i-h616-spidev1_1.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does not have a /__symbols__ node make sure you've compiled with -@ 661 bytes read in 3 ms (214.8 KiB/s) Applying kernel provided DT overlay sun50i-h616-spidev1_2.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does not have a /__symbols__ node make sure you've compiled with -@ 808 bytes read in 3 ms (262.7 KiB/s) Applying kernel provided DT overlay sun50i-h616-spi-spidev.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does not have a /__symbols__ node make sure you've compiled with -@ 616 bytes read in 3 ms (200.2 KiB/s) Applying kernel provided DT overlay sun50i-h616-tft35_spi.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does not have a /__symbols__ node make sure you've compiled with -@ 272 bytes read in 3 ms (87.9 KiB/s) Applying kernel provided DT overlay sun50i-h616-ws2812.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does not have a /__symbols__ node make sure you've compiled with -@ Error applying DT overlays, restoring original DT 31257 bytes read in 4 ms (7.5 MiB/s)

The situation with the overlays is more confusing than I originally anticipated. I assumed that the zero2 overlays would have been in good working order. I should know better than to assume anything! Would someone with an orangepizero2 please test the overlay function to see what works and does not. Use armbian-config -> System -> Hardware and turn on all options. Reboot and check the console boot log to see which overlays load or fail. It looks like the bigtreetech-cb1board created the overlay for sun50i-h616 (/kernel/archive/sunxi-6.7/patches.armbian/arm64-dts-overlay-sun50i-h616-bigtreetech-cb1.patch). However not all SBCs that use the h616 SOC implement the same features. The current sun50i-h616 overlays have implementations for ws8212, tft3, mcp and light, none of which exist on orangepizero2/3. The spi overlays might work as well as the ir. There is no overlay to enable i2c3 or add host function to usbotg. New SBCs that use the h618 SOC will probably implement different features than the zero2/3. The zero2 (h616) and the zero3 (h618) implement the same i/o features. My current thoughts are to implement a new set of overlays for the orangepizero2/3, which have identical i/o. Then both boards then need to be pointed to the new overlays with an overlay_prefix in the board config. I would start with the overlays from the Zunlong distribution for orangepizero3. I would appreciate feedback before I go charging off in the wrong direction (again).

I have a zero3 with 1G ram. I just stuck some small heats sinks on the cpu and mem. A stress test and results are included below. Before Armbian was viable I compiled the Linux kernel on this system using the Zunlong image. It ran for a couple of hours with all 4 cpus at 100%. The temperature stayed constant at about 65, but it worked without a problem. sysadmin@orangepizero3:~$ sudo stress --cpu 4 --io 4 -m 4 --vm-bytes 256M -t 300 stress: info: [2144] dispatching hogs: 4 cpu, 4 io, 4 vm, 0 hdd stress: info: [2144] successful run completed in 301s 12:07:25 480 MHz 3.60 0% 0% 0% 0% 0% 0% 41.3 °C 0/5 12:07:31 480 MHz 3.39 0% 0% 0% 0% 0% 0% 41.3 °C 0/5 12:07:36 1512 MHz 3.20 22% 15% 7% 0% 0% 0% 43.8 °C 0/5 12:07:41 1512 MHz 4.07 100% 64% 35% 0% 0% 0% 48.0 °C 0/5 12:07:46 1512 MHz 4.78 100% 64% 35% 0% 0% 0% 48.7 °C 0/5 12:07:51 1512 MHz 5.44 100% 64% 35% 0% 0% 0% 49.3 °C 0/5 ... 12:12:09 1512 MHz 13.22 100% 66% 33% 0% 0% 0% 56.7 °C 0/5 12:12:14 1512 MHz 13.20 100% 64% 35% 0% 0% 0% 56.5 °C 0/5 12:12:19 1512 MHz 13.18 100% 65% 34% 0% 0% 0% 56.4 °C 0/5 Time CPU load %cpu %sys %usr %nice %io %irq Tcpu C.St. 12:12:25 1512 MHz 13.17 100% 64% 35% 0% 0% 0% 57.0 °C 0/5 12:12:30 1512 MHz 13.16 100% 65% 34% 0% 0% 0% 56.8 °C 0/5 12:12:35 1512 MHz 13.14 96% 62% 30% 0% 3% 0% 56.8 °C 0/5 12:12:40 480 MHz 12.17 0% 0% 0% 0% 0% 0% 51.0 °C 0/5 12:12:45 480 MHz 11.28 0% 0% 0% 0% 0% 0% 49.9 °C 0/5 12:12:50 480 MHz 10.45 0% 0% 0% 0% 0% 0% 49.1 °C 0/5 12:12:55 480 MHz 9.69 0% 0% 0% 0% 0% 0% 48.4 °C 0/5 ... 12:56:56 480 MHz 1.00 0% 0% 0% 0% 0% 0% 39.1 °C 0/5 12:57:01 480 MHz 1.08 0% 0% 0% 0% 0% 0% 39.5 °C 0/5 12:57:06 480 MHz 1.07 0% 0% 0% 0% 0% 0% 39.3 °C 0/5 12:57:11 480 MHz 1.06 0% 0% 0% 0% 0% 0% 39.2 °C 0/5

@pixdrift Since @Gunjan Gupta is busy with another project he asked me to prepare a PR for the following patch. I have never done this and so I am asking you to help with it. It makes sense to point to the h616 overlays as the zero3 and zero2 are common for the items that would normally go into the overlays. I have been using the proposed change and it makes the fixup.scr work on boot and allows armbian-config > System > Hardware to work and load overlays on boot. diff --git a/config/boards/orangepizero3.wip b/config/boards/orangepizero3.wip index 18bcae79d..642eb216f 100644 --- a/config/boards/orangepizero3.wip +++ b/config/boards/orangepizero3.wip @@ -3,6 +3,7 @@ BOARD_NAME="Orange Pi Zero3" BOARDFAMILY="sun50iw9" BOARD_MAINTAINER="viraniac" BOOTCONFIG="orangepi_zero3_defconfig" +OVERLAY_PREFIX=sun50i-h616 BOOT_LOGO="desktop" KERNEL_TARGET="current,edge" FORCE_BOOTSCRIPT_UPDATE="yes" (When I first started working, the concept of patching and PR consisted of shuffling a deck of IBM punched cards!)

@Gunjan Gupta, @pixdrift Re zero2w The hardware output on the zero2 is very different from the zero2/3. The zero2w has a 40 pin header and a 24 pin connector while the zero2/3 have a 26 pin and 13 pin header. The zero2w exposes - twi0, 1, 2 (i2c) - uart0, 2, 3, 4 - spi1 - pm1, 2, 4 - usb2, 3 and a bit more The zero2/3 expose - i2c3 (twi) - spi1 - uart5 - usb2, 3 and a bit more. Some of the pin definitions are common, but many are not. Also the zero2w has multiple definitions for some pins.

I think the overlay files for zero2 and zero3 can be the same as the hardware layout is identical. Zero2w is different. I have put together and tested 3 overlay files, - enable i2c3 - enable spi1 and create spidev - change usbotg to host I could use the i2c3 and spi1 overlays to fix the PH5 duplication if it will not be done in sun50i-h616.dtsi. Usb2 and 3 are already enabled and work without further changes. I am still looking into uart5 to determine what is required. Ir is another item to look at. Then there is sound which has output on the header. But since sound is not yet working that will have to wait. All these overlays currently exist in the Zunlong image. After @Gunjan Gupta showed me how to build an overlay I am now able to reverse engineer the Zunlong dtbos and create dts/dtbo for Armbian.