martinayotte

During my latest tests for Pinebook-a64, if I remember correctly, I've took from latest working build 5.7.6 the DTB and I tried to boot in either 5.8.0 or 5.9.1 images, screen is working during first phase of the boot, but then it switch to blank screen, either if it is a desktop or plain text image. So, it is not a DTB issue, but probably a kernel issue ... I tried to compare ".config" between 5.7.6 and other builds, but I didn't figure out what is missing, It maybe also be in the kernel code itself too...

Ok ! I've never try this over on Rock64, but I did for some other Rockchip boards. So, I've just tried and figured out that U-Boot version was not supporting "setexpr" function, so fixup script failed : ## Executing script at 0900Unknown command 'setexpr' - try 'help' Unknown command 'setexpr' - try 'help' Unknown command 'setexpr' - try 'help' Unknown ' Unknown command 'setexpr' - tlibfdt fdt_getprop(): FDT_ERR_NOTFOUND libfdt fdt_path_offset() returned FDT_ERR_BADPATH I will check to see if doing new builds will provided newer U-Boot for this board ... Alternatively, it is possible maybe to workaround by editing main DT instead of using overlay.

No needs to do any modprobe since it is the overlay that will load them ... You need to specify GPIO1_D4 with "param_w1_pin" in /boot/armbianEnv.txt

Just to avoid issue, please, add a git tag on DEV 5.9.x before doing any change for 5.10.x, this way it will make things easier to switch CURRENT to 5.9.x ...

Glad to see that you figured it out !

I suggest to decompile both DTB into DTS and compare them with "meld" ... Overlays are added using this patch : https://github.com/armbian/build/blob/master/patch/kernel/sunxi-current/general-sunxi-overlays.patch But looking at patches, I saw this patch, so maybe related : https://github.com/armbian/build/blob/master/patch/kernel/sunxi-current/board-cubietruck-enable-uart2.patch

Those settings should be in /boot/armbianEnv.txt using an Armbian image ...

Personally, I would not drive a 4 digits 7 segments display directly from SBC GPIOs, I would rather use a small MCU like Atmel328 or STM32F103 which will do all the scanning easily and would attach it to SBC using I2C bus for example ...

Is there someone who did some builds for Pinebook-A64 recently ? Last build I've done recently are not bringing X11 desktop, neither 5.9.1 or older 5.8.0, the last one that still work on my Pinebook is 5.7.6 ...

This error is there because you tried to compile original DTS outside kernel tree. You should rather decompile existing/working DTB into temporary DTS, edit this one, and recompile it into new DTB.

I not very familiar with libgpiod and how gpio names are coming from the kernel. It seems that all gpios are uname on both Allwinner and Rockchip SoC, but seems that some are present in AmLogic. But looking at some of my AmLogic boards, it seems pretty dependent of pin headers of the specific boards by using "gpio-line-names" property in "pinctrl" node in DT. This is why Allwinner and Rockchip don't have names, there is no "gpio-line-names" property present in the DT ... EDIT: BTW, my AmLogic boards are NanoPi-K2 and Odroid-N2 ...

You can turn it off by setting "PermitRootLogin no" in /etc/ssh/sshd_config ...

At the end of the builds, the image files are written into output/images directory ...

You can try a workaround by doing "cp /usr/bin/python /usr/bin/python-sudo ; chmod a+s /usr/bin/python-sudo" so that execution will be done as root.

In my case, I don't have any issue with a DS18B20 plugged on one of my OPiZero, except maybe that I'm using an external pullup ... root@orangepizero:~# cat /sys/bus/w1/devices/28-000003ebdd28/w1_slave b9 01 4b 46 7f ff 07 10 d1 : crc=d1 YES b9 01 4b 46 7f ff 07 10 d1 t=27562

Did you troubleshooted why you got this error ?

For video, I don't know ... But for serial, Yes ! Doing this command : grep "=8" /boot/config-*-sunxi will reveal : CONFIG_SERIAL_8250_NR_UARTS=8 CONFIG_SERIAL_8250_RUNTIME_UARTS=8

While adding w1-gpio in /boot/armbianEnv.txt, you don't need to add it in /etc/modules-load.d/modules.conf ... But you need to add "param_w1_pin=PD10" in /boot/armbianEnv.txt as well, otherwise it is defaulted to PD14.

Why ? I think there is no need to have a PA7 there, since it is not connected to any external regulator ...

That is why you're getting "Device or resource busy" ... Are you sure we are talking about an Armbian build here ? Because "vcc-af-csi" means this pin is related to a CSI camera...

That looks strange ... Can you try executing "cat /sys/kernel/debug/gpio" and report the output ? As I said, Allwiner H3 or H2+, the PA7 is GPIO7 not GPIO21 ...

Did you tried with sysfs command ? (Maybe it is a bug of gpio tool)

What kind of board are you using ? Your "gpio" tool seems to have been compiled for the wrong board, because PA7 should be named GPIO7 not GPIO21 ... Try using gpio sysfs : echo 7 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio7/direction echo 0 > /sys/class/gpio/gpio7/value

Did you loaded the uart4 overlay in /boot/armbianEnv.txt ?

That is a possibility ...