Gunjan Gupta Posted January 10 Share Posted January 10 31 minutes ago, pixdrift said: Not sure what is required for analog audio to be honest, I will need to check if they actually have that working on the Zero2. Not really, Both hdmi and anolog audio is broken on all h616/h618 boards. This is what needs to be added for the same - https://github.com/orangepi-xunlong/linux-orangepi/commit/cfe0a8df18c2418f77acb24b17b88c9271d9613c#diff-b340c978bcdbe240f7b99f4d0d96ea130a8acb1a5786a8efbb24d9e7a0b14e53. Also its corresponding dts nodes along with dma node will be needed. I don't think we need to make modification to the dma driver like done here - https://github.com/orangepi-xunlong/linux-orangepi/commit/a86c734824acc775c3de5abc48fd48912087d73b. Instead we can just use compatible string as allwinner,sun50i-h6-dma in the dma node within dts. Settings used for h616 and h6 for dma looks exactly the same and hence using h6's compatible string should be enough. also the corresponding asound.state file will be needed to ensure alsa is properly initialized. 0 Quote Link to comment Share on other sites More sharing options...
pixdrift Posted January 10 Share Posted January 10 @Gunjan Gupta I was looking at this patch here (which unfortunately combines thermals etc. with HDMI audio) and was referenced earlier in this thread: https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-6.6/files/0630-arm64-dts-allwinner-h616.dtsi-add-ths-audio-hdmi.patch This appears to only modify the dtsi, but you're suggesting the underlying kernel code needs patching in too because it's not ther? (I will admit I haven't had a look yet) 0 Quote Link to comment Share on other sites More sharing options...
Gunjan Gupta Posted January 10 Share Posted January 10 16 minutes ago, pixdrift said: This appears to only modify the dtsi, but you're suggesting the underlying kernel code needs patching in too because it's not ther? (I will admit I haven't had a look yet) Yes the driver is not there. The driver code is from allwinner bsp kernel and is not in mainline linux kernel 0 Quote Link to comment Share on other sites More sharing options...
Sma Posted January 10 Share Posted January 10 2 hours ago, pixdrift said: anyone advise if the following would be a good box for testing? (plug headphones in to verify HDMI audio), if so I will buy one for testing. https://www.aliexpress.us/item/1005005630394541.html I can't advise on that, but it looks like it should work though. On another note, the 3.5" lcd screen I have has a headphone out plug, so I should be able to test audio once an image with a fix is available. I haven't tried compiling any of them yet, I could give it a shot I guess. I'll have to test to confirm my microhdmi to hdmi cable supports audio. But I don't see why it wouldn't. 1 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 10 Share Posted January 10 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). 0 Quote Link to comment Share on other sites More sharing options...
Gunjan Gupta Posted January 10 Share Posted January 10 1 hour ago, Stephen Graf said: 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 dont think it hurts to create more overlays. As most of the overlays provided by armbian for other allwinner soc's are for generic functionality, like enabling i2c but not configuring the same for connecting a specific peripheral like a temperature sensor, I believe same can be done here as well. 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 10 Share Posted January 10 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) 0 Quote Link to comment Share on other sites More sharing options...
pixdrift Posted January 10 Share Posted January 10 (edited) 2 hours ago, Stephen Graf said: 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 agree with this approach and it was what I was promoting earlier in the thread, an overlay for each board (or maybe combined in the very specific zero2/zero3 use case). The SoC itself should be the same, but there are minor differences in implementation and peripherals that will want to give us the flexibility to add/remove items at a board specific level and not have that show up for other boards as this would potentially confuse end users of armbian-config. This was the reason I went looking for other h616 and h618 boards and found the Sipeed Longan Pi 3H, and there is also the Mango Pi MQ-Quad, and Banana Pi M4 Zero that share h61x SoCs. The bigtreetech looks to be a very different board, with different components/peripherals that will be unique to those boards. I think cloning the current overlay into orangepizero (similar to how the dtsi is done) or orangepizero3, and just work to get the single board correct would be a great next step. In terms of testing on the zero2, I am happy to do that and provide the output, let me know specifically which boot logs you need after enabling components, and I can send it to you in a PM. -edit- A potentially a very basic question, but on the Zero2/3 board diagrams it shows GPIO pins as PC<num>, PI<num>, and PH<num> and I haven't found a clear explanation for these prefixes.. is someone able to decode this for me? Edited January 10 by pixdrift 0 Quote Link to comment Share on other sites More sharing options...
pixdrift Posted January 10 Share Posted January 10 10 hours ago, Gunjan Gupta said: Yes the driver is not there. The driver code is from allwinner bsp kernel and is not in mainline linux kernel It's definitely a hefty (large) patch, which makes me nervous when bringing it in.. as I expect (hope) the effort will be deprecated in the near future with the mainlining effort. What's the best way to determine if this is being worked on in mainline and it would be easier to wait for that? The sunxi mailing lists? 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 10 Share Posted January 10 @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 1 Quote Link to comment Share on other sites More sharing options...
Sean Perez Posted January 11 Share Posted January 11 (edited) On 1/7/2024 at 7:55 PM, Stephen Graf said: Original dtb: spi@5010000 { compatible = "allwinner,sun50i-h616-spi\0allwinner,sun8i-h3-spi"; reg = <0x5010000 0x1000>; interrupts = <0x00 0x0c 0x04>; clocks = <0x02 0x4f 0x02 0x4d>; clock-names = "ahb\0mod"; resets = <0x02 0x1c>; pinctrl-names = "default"; pinctrl-0 = <0x1c 0x1d>; status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x53>; flash@0 { #address-cells = <0x01>; #size-cells = <0x01>; compatible = "jedec,spi-nor"; reg = <0x00>; spi-max-frequency = <0x2625a00>; }; }; yeah but your missing the spidev@0{} thats what lets it be seen in /dev/ this is the 6.1 debian opi dtb... spi@5010000 { compatible = "allwinner,sun50i-h616-spi\0allwinner,sun8> reg = <0x5010000 0x1000>; interrupts = <0x00 0x0c 0x04>; clocks = <0x02 0x4f 0x02 0x4d>; clock-names = "ahb\0mod"; resets = <0x02 0x1c>; pinctrl-names = "default"; pinctrl-0 = <0x35 0x36>; dmas = <0x24 0x16 0x24 0x16>; dma-names = "rx\0tx"; status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x7e>; spidev@0 { status = "disabled"; compatible = "rohm,dh2228fv"; reg = <0x00>; spi-max-frequency = <0xf4240>; }; flash@0 { status = "okay"; #address-cells = <0x01>; #size-cells = <0x01>; compatible = "jedec,spi-nor"; reg = <0x00>; spi-max-frequency = <0x2625a00>; }; }; spi@5011000 { compatible = "allwinner,sun50i-h616-spi\0allwinner,sun8> reg = <0x5011000 0x1000>; interrupts = <0x00 0x0d 0x04>; clocks = <0x02 0x50 0x02 0x4e>; clock-names = "ahb\0mod"; resets = <0x02 0x1d>; pinctrl-names = "default"; pinctrl-0 = <0x37 0x38>; dmas = <0x24 0x17 0x24 0x17>; dma-names = "rx\0tx"; status = "disabled"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x7f>; spidev@1 { compatible = "rohm,dh2228fv"; status = "disabled"; reg = <0x01>; spi-max-frequency = <0xf4240>; }; }; im not 100% sure but im pretty sure the fact that it's in main dtb might not let it overlay on it? (oh I just realized my phone and my PC have different usernames -Serby) ** @Stephen Graf since I was here I decompiled the overlays in orangepi 6.1 debian /tmp/sun50i-h616-spi1-cs0-cs1-spidev.dtbi fragment@1 { target = <0xffffffff>; __overlay__ { status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; pinctrl-names = "default"; pinctrl-0 = <0xffffffff 0xffffffff 0xffffffff>; spidev@0 { compatible = "rohm,dh2228fv"; status = "okay"; reg = <0x00>; spi-max-frequency = <0x2faf080>; }; spidev@1 { compatible = "rohm,dh2228fv"; status = "okay"; reg = <0x01>; spi-max-frequency = <0x2faf080>; }; }; }; __fixups__ { spi1 = "/fragment@1:target:0"; spi1_pins = "/fragment@1/__overlay__:pinctrl-0:0"; spi1_cs0_pin = "/fragment@1/__overlay__:pinctrl-0:4"; spi1_cs1_pin = "/fragment@1/__overlay__:pinctrl-0:8"; }; }; /tmp/sun50i-h616-spi1-cs0-cs1-spidev.dtbi Spoiler /dts-v1/; / { fragment@0 { target-path = "/aliases"; __overlay__ { spi1 = "/soc/spi@5011000"; }; }; fragment@1 { target = <0xffffffff>; __overlay__ { status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; pinctrl-names = "default"; pinctrl-0 = <0xffffffff 0xffffffff 0xffffffff>; spidev@0 { compatible = "rohm,dh2228fv"; status = "okay"; reg = <0x00>; spi-max-frequency = <0x2faf080>; }; spidev@1 { compatible = "rohm,dh2228fv"; status = "okay"; reg = <0x01>; spi-max-frequency = <0x2faf080>; }; }; }; __fixups__ { spi1 = "/fragment@1:target:0"; spi1_pins = "/fragment@1/__overlay__:pinctrl-0:0"; spi1_cs0_pin = "/fragment@1/__overlay__:pinctrl-0:4"; spi1_cs1_pin = "/fragment@1/__overlay__:pinctrl-0:8"; }; }; /tmp/sun50i-h616-spi1-cs0-spidev.dtbi Spoiler /dts-v1/; / { fragment@0 { target-path = "/aliases"; __overlay__ { spi1 = "/soc/spi@5011000"; }; }; fragment@1 { target = <0xffffffff>; __overlay__ { status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; pinctrl-names = "default"; pinctrl-0 = <0xffffffff 0xffffffff>; spidev@0 { compatible = "rohm,dh2228fv"; status = "okay"; reg = <0x00>; spi-max-frequency = <0xf4240>; }; }; }; __fixups__ { spi1 = "/fragment@1:target:0"; spi1_pins = "/fragment@1/__overlay__:pinctrl-0:0"; spi1_cs0_pin = "/fragment@1/__overlay__:pinctrl-0:4"; }; }; /tmp/sun50i-h616-spi1-cs1-spidev.dtbi Spoiler /dts-v1/; / { fragment@0 { target-path = "/aliases"; __overlay__ { spi1 = "/soc/spi@5011000"; }; }; fragment@1 { target = <0xffffffff>; __overlay__ { status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; pinctrl-names = "default"; pinctrl-0 = <0xffffffff 0xffffffff>; spidev@1 { compatible = "rohm,dh2228fv"; status = "okay"; reg = <0x01>; spi-max-frequency = <0xf4240>; }; }; }; __fixups__ { spi1 = "/fragment@1:target:0"; spi1_pins = "/fragment@1/__overlay__:pinctrl-0:0"; spi1_cs1_pin = "/fragment@1/__overlay__:pinctrl-0:4"; }; }; dunno if you had those or not but I guess they use that other syntax of fragment@... but .. it seems that raspi goes that also, I dunno, gonna see what I find im like you never really messed with this beyond changing a line here and there... what im trying to find is the CMA memory which I think should be set in the reserved-memory reserved-memory { #address-cells = <0x02>; #size-cells = <0x02>; ranges; secmon@40000000 { reg = <0x00 0x40000000 0x00 0x80000>; no-map; }; }; but its not i think the secmon thing as per some kernel update email mentioned that is for kernel boot or something ... but the CMA is set in the orangepi debian 6.1 but i dont find it in DT secmon@... { ...}; cma_reserved@48000000 { // Adjust the address based on your system compatible = "shared-dma-pool"; reg = <0x0 0x48000000 0x0 0x8000000>; // Adjust the size based on your requirements no-map; }; but im not 100% convinced about that yet but im seeing things on other boards that are showing CMA at like 512mB ++ (depends on the memory size your board has) but mainly its for heavy GPU decode encode ( on those other boards) the default on the orangepi debian 6.1 is cat /proc/meminfo | grep -i cma CmaTotal: 131072 kB CmaFree: 117644 kB and its hardly using anything ( and im running desktop xfce) dunno how big a deal this is but according to this posts i been comming across mentioning this and with GPU hardware acceleration on other SoCs.. just dunno where to add this without breaking something LOL Edited January 11 by Sean Perez 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 11 Share Posted January 11 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. 0 Quote Link to comment Share on other sites More sharing options...
pixdrift Posted January 11 Share Posted January 11 (edited) This is the output from the orangepizero2 with all Hardware overlays turned on, using the latest build from Armbian mainline repo. So the overlays don't look to be in a particularly good state for either zero2 or zero3. # Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 299 bytes read in 1 ms (292 KiB/s) 32033 bytes read in 7 ms (4.4 MiB/s) Working FDT set to 4fa00000 268 bytes read in 6 ms (43 KiB/s) Applying kernel provided DT overlay sun50i-h616-ir.dtbo 512 bytes read in 5 ms (99.6 KiB/s) Applying kernel provided DT overlay sun50i-h616-light.dtbo failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND 339 bytes read in 5 ms (65.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 6 ms (107.4 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 6 ms (107.4 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 6 ms (107.4 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 6 ms (107.4 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 6 ms (130.9 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 5 ms (120.1 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 5 ms (52.7 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 32033 bytes read in 7 ms (4.4 MiB/s) 18403742 bytes read in 763 ms (23 MiB/s) 23169032 bytes read in 960 ms (23 MiB/s) Edited January 11 by pixdrift 0 Quote Link to comment Share on other sites More sharing options...
ag123 Posted January 11 Author Share Posted January 11 hi all a little 'off topic', but as we are doing quite a lot of works on device tree overlays, I did some googling and here are some random stumbles: Is it possible to get the information for a device tree using /sys of a running kernel? https://unix.stackexchange.com/questions/265890/is-it-possible-to-get-the-information-for-a-device-tree-using-sys-of-a-running /proc/device-tree or /sys/firmware/devicetree/base /proc/device-tree is a symlink to /sys/firmware/devicetree/base and the kernel documentation says userland should stick to /proc/device-tree: Userspace must not use the /sys/firmware/devicetree/base path directly, but instead should follow /proc/device-tree symlink. It is possible that the absolute path will change in the future, but the symlink is the stable ABI. You can then access dts properties from files: hexdump /sys/firmware/devicetree/base/apb-pclk/clock-frequency The output format for integers is binary, so hexdump is needed. dtc -I fs Get a full device tree from the filesystem: sudo apt-get install device-tree-compiler dtc -I fs -O dts /sys/firmware/devicetree/base outputs the dts to stdout. See also: How to list the kernel Device Tree | Unix & Linux Stack Exchange https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/latest/exports/docs/linux/How_to_Guides/FAQ/How_to_Check_Device_Tree_Info.html https://elinux.org/Device_Tree_Reference several trials: armbian@orangepizero3:~$ ls /proc/device-tree '#address-cells' display-engine opp-table-cpu serial-number vcc33-wifi aliases interrupt-parent osc24M-clk '#size-cells' vcc5v chosen leds pmu soc vcc-wifi-io compatible memory psci __symbols__ wifi-pwrseq connector model regulator-usb1-vbus thermal-zones cpus name reserved-memory timer armbian@orangepizero3:~$ ls /proc/device-tree/soc '#address-cells' i2c@5002400 pinctrl@7022000 syscon@3000000 addr-mgt i2c@5002800 ranges tcon-top@6510000 bus@1000000 i2c@5002c00 rsb@7083000 thermal-sensor@5070400 clock@3001000 i2c@5003000 rtc@7000000 usb@5100000 clock@7010000 i2c@7081400 serial@5000000 usb@5101000 compatible interrupt-controller@3021000 serial@5000400 usb@5101400 dump_reg@20000 ir@7040000 serial@5000800 usb@5200000 efuse@3006000 lcd-controller@6515000 serial@5000c00 usb@5200400 ethernet@5020000 mmc@4020000 serial@5001000 usb@5310000 ethernet@5030000 mmc@4021000 serial@5001400 usb@5310400 gpu@1800000 mmc@4022000 '#size-cells' usb@5311000 hdmi@6000000 name spi@5010000 usb@5311400 hdmi-phy@6010000 phy@5100400 spi@5011000 video-codec@1c0e000 i2c@5002000 pinctrl@300b000 sunxi-info watchdog@30090a0 armbian@orangepizero3A:~$ ls /proc/device-tree/soc/spi@5011000/ '#address-cells' clocks interrupts phandle pinctrl-names resets status clock-names compatible name pinctrl-0 reg '#size-cells' armbian@orangepizero3:~$ cat /proc/device-tree/soc/spi@501 double tab spi@5010000/ spi@5011000/ armbian@orangepizero3:~$ cat /proc/device-tree/soc/spi@5010000/status okay armbian@orangepizero3:~$ cat /proc/device-tree/soc/spi@5011000/status disabled well it seemed /proc/device-tree is a good place to check device tree configurations at run time. hope that could help with 'debugging' device tree overlays. of course, the other place is probably in dmesg as well as during boot but that'd need a usb-uart (serial) connection (at least) 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 11 Share Posted January 11 @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. 0 Quote Link to comment Share on other sites More sharing options...
Gunjan Gupta Posted January 11 Share Posted January 11 1 hour ago, Stephen Graf said: 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. Just a generic advice for both overlay and fixup script, look for whats done for H3, H5 and H6. Do something similar 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 11 Share Posted January 11 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. 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 15 Share Posted January 15 (edited) @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 Edited January 15 by Stephen Graf changed patch file, added test files 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 15 Share Posted January 15 Sorry, wrong patch. Try this one. Moving too fast.arm64-dts-overlay-sun50i-opangepizero2-3-overlays.patch 0 Quote Link to comment Share on other sites More sharing options...
pixdrift Posted January 15 Share Posted January 15 1 hour ago, Stephen Graf said: Sorry, wrong patch. Try this one. Moving too fast. Thanks I will try and get a build of this out tonight, can you detail some basic tests to verify this is working correctly? 0 Quote Link to comment Share on other sites More sharing options...
pixdrift Posted January 16 Share Posted January 16 @Stephen Graf I have put the patch in the following branch in my github repo: https://github.com/pixdrift/armbian_build/tree/zero23_spi_menufix You had a typo in your patch of 'opangepi' which may have been why you had filter issues with your prefix (late night development will do that to you!), but it was a quick fix.. and I updated the patch and then the prefix for zero2 and zero3 to use the correct prefix. I booted the image on zero2, and the armbian-config menu looked correct, I enabled everything in the list and rebooted and for whatever reason it failed to boot (red light, no disk activity). Not sure what is wrong, and if it's a one off or more significant issue, but I will hopefully have time to look at it tomorrow. I expect the above branch to have SPI fixes for Zero2 and Zero3 (using edge kernel) for anyone interested in testing. 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 16 Share Posted January 16 @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 1 Quote Link to comment Share on other sites More sharing options...
pixdrift Posted January 16 Share Posted January 16 I did some troubleshooting last night, and it appears that the boot issue isn't related to the overlay configuration, but appears to be a bug/issue with the Zero2 image. I can replicate it consistently 1. Flash Zero 2 image and boot 2. Configure root/user through prompts, configure Wifi, locales etc. 3. As soon as I am provided a command prompt issue `systemctl reboot` The board then reboots to only a red LED illuminated.. and doesn't boot again. I have removed power, waited for extended periods of time.. it just doesn't seem to come back. This is all without making any changes in the armbian-config menu. I am going to build a clean mainline image and confirm I can replicate this bug/issue there. In summary, I don't think I have a solid foundation for testing this change on Zero2 at the moment, will try and narrow it down when I have some more time. 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 16 Share Posted January 16 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. 0 Quote Link to comment Share on other sites More sharing options...
Gunjan Gupta Posted January 17 Share Posted January 17 12 hours ago, pixdrift said: The board then reboots to only a red LED illuminated.. and doesn't boot again. Is there any output on serial console? 0 Quote Link to comment Share on other sites More sharing options...
pixdrift Posted January 17 Share Posted January 17 (edited) So after much troubleshooting I could get reliable results on a much slower MicroSD card (I was using fast MicroSD cards). My theory is that the faster cards result in the Zero 2 board becoming CPU bound during initial configuration causing it to overheat, or there is a weird race condition during shutdown. I did manage one reboot with a faster card and the CPU temps looked quite high. What led me to this conclusion was after a re-flash it would still not boot (too hot). So after that troubleshooting exercise, I am now using my slowest MicroSD card, and have ordered a Zero 2 (and Zero 1!) heatsink So here are the results after turning on all the options in the armbian-config menu. ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 264 bytes read in 1 ms (257.8 KiB/s) 32033 bytes read in 6 ms (5.1 MiB/s) Working FDT set to 4fa00000 344 bytes read in 5 ms (66.4 KiB/s) Applying kernel provided DT overlay sun50i-orangepizero2-3-i2c3.dtbo 339 bytes read in 5 ms (65.4 KiB/s) Applying kernel provided DT overlay sun50i-orangepizero2-3-ir.dtbo 608 bytes read in 6 ms (98.6 KiB/s) Applying kernel provided DT overlay sun50i-orangepizero2-3-otg-host.dtbo 699 bytes read in 4 ms (169.9 KiB/s) Applying kernel provided DT overlay sun50i-orangepizero2-3-spi1-cs0-spidev.dtbo 644 bytes read in 5 ms (125 KiB/s) Applying kernel provided DT overlay sun50i-orangepizero2-3-uart5.dtbo 620 bytes read in 6 ms (100.6 KiB/s) Applying kernel provided DT fixup script (sun50i-orangepizero2-3-fixup.scr) ## Executing script at 45000000 18403342 bytes read in 762 ms (23 MiB/s) 23169032 bytes read in 958 ms (23.1 MiB/s) Moving Image from 0x40080000 to 0x40200000, end=41890000 root@orangepizero2:~# sudo i2cdetect -l i2c-0 i2c DesignWare HDMI I2C adapter i2c-1 i2c mv64xxx_i2c adapter I2C adapter root@orangepizero2:~# sudo i2cdetect 2 Error: Could not open file `/dev/i2c-2' or `/dev/i2c/2': No such file or directory root@orangepizero2:~# sudo i2cdetect 1 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-1. I will probe address range 0x08-0x77. Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- root@orangepizero2:~# lsusb Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@orangepizero2:~# usb-devices T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev=06.07 S: Manufacturer=Linux 6.7.0-edge-sunxi64 ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=5101000.usb C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev=06.07 S: Manufacturer=Linux 6.7.0-edge-sunxi64 ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=5200000.usb C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev=06.07 S: Manufacturer=Linux 6.7.0-edge-sunxi64 ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=5310000.usb C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev=06.07 S: Manufacturer=Linux 6.7.0-edge-sunxi64 ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=5311000.usb C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 1 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev=06.07 S: Manufacturer=Linux 6.7.0-edge-sunxi64 ohci_hcd S: Product=Generic Platform OHCI controller S: SerialNumber=5101400.usb C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=06 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev=06.07 S: Manufacturer=Linux 6.7.0-edge-sunxi64 musb-hcd S: Product=MUSB HDRC host driver S: SerialNumber=musb-hdrc.4.auto C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=07 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 1 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev=06.07 S: Manufacturer=Linux 6.7.0-edge-sunxi64 ohci_hcd S: Product=Generic Platform OHCI controller S: SerialNumber=5200400.usb C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=08 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 1 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev=06.07 S: Manufacturer=Linux 6.7.0-edge-sunxi64 ohci_hcd S: Product=Generic Platform OHCI controller S: SerialNumber=5310400.usb C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=09 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 1 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev=06.07 S: Manufacturer=Linux 6.7.0-edge-sunxi64 ohci_hcd S: Product=Generic Platform OHCI controller S: SerialNumber=5311400.usb C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms root@orangepizero2:~# mode2 -d /dev/lirc0 Using driver devinput on device /dev/lirc0 Trying device: /dev/lirc0 Using device: /dev/lirc0 Keep in mind I have nothing plugged into USB, GPIO, and don' have an IR remote.. but can possibly test these given some more time (if it's critical). From my perspective everything looks good, my only concern was the i2cdetect differences to zero3, not sure if it's to be expected that we have one less than zero3. I have this image running stable now so if any other testing is required, let me know.. looks good to me. Edited January 17 by pixdrift 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 17 Share Posted January 17 @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. 0 Quote Link to comment Share on other sites More sharing options...
pixdrift Posted January 17 Share Posted January 17 2 hours ago, Stephen Graf said: Yes, the output of the serial debug console would be very useful to see how far into the boot process the system got. I will try and re-create the issue today, and get a serial log. Hoping the summer heat is on my side. 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 17 Share Posted January 17 @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. 0 Quote Link to comment Share on other sites More sharing options...
pixdrift Posted January 18 Share Posted January 18 (edited) Well.. after some extended testing.. I finally got to the bottom of the issue. It wasn't related to the SD cards at all after all, and it also wasn't related to the heat (managed to push it to 84c+ and then reboot), it is my serial USB converter. So I have discovered that if my serial/USB converter is plugged in to the Zero2 serial pins, but not connected to a PC, the Orange Zero2 fails to boot, and gets 'stuck'. When I plug the serial converter in when it's in this state (just a red LED) I get a u-boot prompt. From here if I issue 'reset' with the serial converter plugged in to the PC (to issue the command) the board reboots cleanly, no issues. This is the same behaviour for mainline and my SPI fix branch in github, so it looks to be strange behaviour if it can see the USB serial converter on the line and it doesn't appear to have anything to do with the patches (apologies for the confusion). The USB serial converter (I have a few, but this is the most reliable) is a 'CP2102 USB to UART Bridge Controller' Not sure what to make of this information, but hoping others may have some thoughts? Edited January 18 by pixdrift 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.