martinayotte

Most probably "active_high" vs "active_low" ...

Yes, this is an important error, it mean that some parameters inside overlay are not resolved ! Unfortunately, there is no way to get it more verbose during that boot phase. But, it is a bit easier to debug using dynamic loading : mkdir /sys/kernel/config/device-tree/overlays/waveshare cat waveshare.dtbo > /sys/kernel/config/device-tree/overlays/wave/dtbo Then, "dmesg" reveal a more verbose "OF: resolver: overlay phandle fixup failed: -22" . It is probably that the line "interrupt-parent = <&gpio>;" should be "interrupt-parent = <&pio>;" instead ...

Yes, like that : clocks = <&ccu 107>; If it doesn't work, try to find the "phandle" of the "ccu" by decompiling the main DT, and write like (where N is the numeric value of the phandle found) : clocks = <N 107>;

You seems to use overlays syntax inside a main device tree... Place the pin node inside "&pio" node, and pace the "onewire" node at root level.

Right ! This is because CLK_CSI_MCLK is not define since it is not compiled from Main DT where there are kernel includes defining it. In overlays, you need to use strictly numeric values, no defines are allowed ...

Did you look more thoroughly in "dmesg", maybe there something else missing ...

In many distribution, mysql has been replaced by mariadb ... MariaDB is a fork of MySQL started in 2009 ! EDIT: BTW, by editing this install.sh and change "mysql-" with "mariadb-" will most probably do the job.

How your patch looks like ? Do you see in "lsmod" that the "w1_gpio" has been loaded ?

I've just done a preliminary commit here : https://github.com/armbian/build/commit/b8c87da5732d488f28e07535149dba1d0ba490fa Other 5.6.y commits will be done later ...

At first look, those pins should be in upper cases ...

I had to create new one as patch/misc/general-packaging-5.6.y.patch and added an IF/ELSE statement in lib/compilation-prepare.sh to avoid braking older branches.

The schematic is here : https://linux-sunxi.org/images/6/6c/ORANGEPI-Winplus-V1_3.pdf GPIO header can be found on page 12, SDA/SCL are at pins 3 and 5 ...

It seems that "board autodetection" of that "gpio readall" tools is the culprit. Don't really on it ! Or try to figure out why it is not detecting the good pinout ... You can use GPIO directly using /sys/class/gpio, I'm pretty sure the GPIOs are all working since it is not a kernel or Armbian problem. You can also use python library such as the one from https://github.com/duxingkei33/orangepi_PC_gpio_pyH3

How did you diagnose that ... (It should be pretty straight forward ...)

You need a USB-TTL Serial dongle plugged on the 3 pins Debug header of the OPi4 board. On your computer where you attached the dongle, you run terminal software such as "picocom" with baudrate set at 1500000 baud. You will then see the log when powering the board. If this Android U-Boot allows to stop booting using <spacebar> pressed several times during early boot and comes to a command prompt, you can then do "mmc list" to see the list of bootable devices, you can then select the SDCard device by doing "setenv devnum N", where N is the device number for SD, followed by "run mmc_boot". If this Android U-Boot doesn't support those commands, then you have to either try the TP50265 test point method shorted to GND before applying power to the board, or to find/try another SD image provided by Xunlong that allows to boot from it over eMMC, and then, from a "root" user shell, erase the eMMC by doing "dd if=/dev/zero of=/dev/mmcblk2 bs=1024 count=1024", that will destroy/erase Android U-Boot sectors definitively, so that any future boot attempts will be done exclusively from SDCard ...

If nothing connected, it is pretty normal that "flashrom" gives an error since it doesn't find any answers to it JEDEC ID request ...

So, according to your "dmesg" output, UART3 came up into /dev/ttyS1 ! You can then try to communicate with your arduino board using that port ...

What "dmesg | grep tty" is reporting ? Is "cat /proc/device-tree/soc/serial@1c28c00/status" reporting "okay" or "disabled" ? Are you using PG6/PG7 or PH0/PH1 to connect to your arduino board ? Because UART3 overlay if defaulted to PG6/PG7, except if you add "param_uart3_pins=b" to switch it to PH0/PH1.

You should be aware that any Rockchip SoC have eMMC boot priority over SDCard. So, if Android U-Boot present in eMMC doesn't provide "stop" functionality to let you choose boot device using Serial Debug port, you won't have much choice to short TP50265 test point to disable eMMC as described in this thread :

Interesting ... Hoping there is no other secret sauce such as defconfig ... I will give a try this over the weekend !

Most probably, someone will post here ...

This is brand new SoC from Allwinner, this mean Linux support will take a while before it make it under Armbian, unless we find some compatibility with previous H6.

The simpliest way is to test MOSI/MISO with a loopback wire between those two pins and then use "spidev_test" after having it compiled : https://github.com/torvalds/linux/blob/master/tools/spi/spidev_test.c Did you properly connected a SPINOR flash chip on the proper pins or you connected some other kind of devices ?

Ok ! I passed the main hurdles ... The worst one was that many obsolete time32 helpers that are now definitively gone/erased, but we still need them for out-of-the-tree wifi drivers, so I had to put them back using timekeeping32.patch. I will do few more test images for my different Allwinner boards, then I will be ready for commit ...

Maybe this is because of partition scheme which probably different. Armbian is using a single partition and have a /boot folder which contains kernel/dtb/uinitrd. Any hobbyist should have at least one, they are so cheap ($0.99), and useful for debugging. Personally, I've around 15 of them, so I don't need to disconnect it when debugging another board. If you don't care about losing it current content, Yes, you could erase the U-Boot of the eMMC, at least the first MB, using "dd if=/dev/zero of=/dev/mmcblk2 bs=1024 count=1024"