Jump to content

Orange Pi Zero 3


ag123

Recommended Posts

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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 by pixdrift
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

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 by Sean Perez
Link to comment
Share on other sites

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 by pixdrift
Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by pixdrift
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by pixdrift
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines