martinayotte

This looks like a problem with the router itself ... Did you tried to power recycle this router without touching anything on OPi ?

For simple LED, there is no issue driving it directly, simply check the sink or source capabilities of your SoC or chips. Some have higher sink capabilities than source, such as TTL chips, or even worst the PCF8574 GPIO Expander, but according to H3 datasheet, GPIOs has a "buffer strenth" of max 20mA in both sink/source mode.

Of course ...

Yes, that is why I've mentioned "mode selection is probably determined by another pin". According to this datasheet : https://www.elecrow.com/download/SH1106 datasheet.pdf some other pins IM0/IM1/IM2 determine what kind of interface is active.

Did you tried "i2cdetect" to see if the LCD is properly detected ? BTW, as you've mentioned earlier, there are also some LCD that have SPI wires, make sure you are using the I2C instead, mode selection is probably determined by another pin.

If PA20 is busy by some other drivers, such LEDS, pins controller will refuse to assign PA to W1 driver, therefore existing W1 setting to PG11 won't be overwritten. If PA20 were not it use, yes the W1 settings will overwrite the main DT, but it is not the case here since PA20 is busy.

Probably because it is how it has been defined in main DT, not by overlays, and trying to use your PA20 overlay failed to be loaded since PA20 is already in-use by kernel LEDS blue:status in main DT. In other words, you have to analyse the main DT before trying any kind of overlays ...

Right, I've mentioned PF11 wrongly, right, it is PG11 ...

It seems that PA20 is on leds blue:status and that W1 now using PF11 (203) ...

what are you seeing for PA20 while doing a "cat /sys/kernel/debug/gpio" ? what dmesg reports while doing "dmesg | grep w1" ?

So you have external pullup on PA20 ?

Doing "chown -R root:gpio /sys/class/gpio" is only changing this directory, not the pointed symlinks, so you probably need to do a "chown -R root:gpio /sys/devices/platform/soc/1c20800.pinctrl/gpio" also...

It must be placed before the last line showing "exit 0"

As I said, the u-boot is not inside a partition. Depending of the SoC and boards, the first byte is usally at byte#8192, for example, copying an u-boot image from file to sdcard would be : dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 bs=1024 seek=8 If you wish to extract an copy u-boot from a device to another, like you seems to wish, than it would be something like that, assuming that this u-boot is smaller than 500K : dd if=/dev/mmcblk0 of=/dev/sdc bs=1024 seek=8 skip=8 count=500 conv=notrunc As you can see, your previous copy was copying an entirely different location ...

Did you also check UUID in /etc/fstab ?