martinayotte

No ! I was considering the orientation and the R16 label itself.
That is probably caused by a short of the VCC-RTC to GND, which can harm/damage your board.
 
What do you mean by double click ?

GND !
According to voltage measured, it should be the green side ...

Looking at schematic, PL3 is been pulled up by R16 resistor bottom side near debug header.

It is in the default U-Boot environment, the default fdtfile is declared in board defconfig...

Ok ! You probably have this error in "dmesg" like I got :
sun4i-usb-phy 1c19400.phy: Couldn't request ID GPIO This is a bug probably introduced several months ago !
I don't have yet a real solution/fix, but at least I have a workaround :
 
Download the DT compiler using "wget http://ftp.debian.org/debian/pool/main/d/device-tree-compiler/device-tree-compiler_1.4.7-3_armhf.deb " , and then installing it using "dpkg -i device-tree-compiler_1.4.7-3_armhf.deb"
 
Then, decompile current DTB into DTS using "dtc -@ -I dtb -O dts -o sun8i-h3-orangepi-one.dts /boot/dtb/sun8i-h3-orangepi-one.dtb".
 
Edit this DTS to change "dr_mode" from "otg" to "host" in the "usb@1c19000" node, and comment out the "usb0_id_det-gpios" line in the "phy@1c19400" node.
 
Recompile DTB from this DTS "dtc -@ -I dts -O dtb -o /boot/dtb/sun8i-h3-orangepi-one.dtb sun8i-h3-orangepi-one.dts" and then reboot. The USB0 should be powered ...

I've committed fixes for Rockchip SPI overlays in DEV branch, I've got SPI2 working on my RockPi4B ...
 
EDIT: Tested also on my OPi-RK3399 and RockPro64 ...
EDIT2: beware, it seems that any speed lower than 10MHz is not allowed ...

I've done a build Meson64-DEV with 5.2.y ...
I will commit the switch as soon as runtime test succeded !
 

Me ...

Me ...

Me ...

Me ...

I'm not fluent with selinux at all .
All my boards booted without issues ...
Do you have any repro steps ?

I've started the job of switching both rockchip64-dev and rk3399-dev to 5.2.y ...
 

I've started the job of switching both rockchip64-dev and rk3399-dev to 5.2.y ...
 

With Mainline image, I'm doing flashing of both LEDs with this script :
#!/bin/bash while true ; do echo 255 > /sys/class/leds/orangepi\:green\:status/brightness echo 0 > /sys/class/leds/orangepi\:red\:power/brightness sleep 0.25 echo 0 > /sys/class/leds/orangepi\:green\:status/brightness echo 255 > /sys/class/leds/orangepi\:red\:power/brightness sleep 0.25 done  

In the other thread, @jernej were questioning why we still have all those 35 patches for lima.
Since I'm not an expert on that subject, I couldn't really answer properly...

Commits for the switching to 5.2.y is now done !
(Hoping I didn't forget too much ... Still few patches to fix, such as startup logo, but it is not an hurry ...)
 

I won't commit my work today, I still have some boards updates to do !
Maybe tomorrow ...

Maybe with some kind of hack by having DTB copied under both /boot/dtb/sun50i-h3-orangepi-zero-plus2.dtb and /boot/dtb/sun50i-h3-orangepi-zeroplus2.dtb names...

Since the two last days, I'm working on switching SUNXI-DEV to 5.2.y ...
I'm almost done, tested few of my boards, I will do more boards and probably commit my work tomorrow !
 

Since the two last days, I'm working on switching SUNXI-DEV to 5.2.y ...
I'm almost done, tested few of my boards, I will do more boards and probably commit my work tomorrow !
 

This is because Arduino TTL level is 5V, so it could damage a 3.3V input...

It seems it have been added during April for a specific NanoPi which has this RTC onboard, but by mistake, it has been added to all NanoPi !
We will probably fix that soon ...

@Igor, getting back to more serious stuff, seeing this post yesterday, I've downloaded the Armbian_5.89.190626_Orangepioneplus_Debian_stretch_dev_5.1.12.img, and it was effectively crashing during boot, and creating a boot loop after 10 seconds wait.
I've decided to compile my own image and ended up with Armbian_5.90_Orangepioneplus_Debian_stretch_dev_5.1.15.img which works without issue.
I don't know where is the issue, maybe the fact that I always compile my own image without Wireguard ...

No ! The 'm' means 'module' ...