martinayotte

Not true ! It simply they out-of-stock and some parts in backorder. Manufacturing will resume within few weeks or months. When I ask for links, I didn't mean orangepi link which I know well since years, but link to the libraries you've tried without success ...

Which one ? Can you provide link ? What do you means by "pin alignment" ? Different pinout ? That I means by "tweaking" ...

Mainly : armhf != arm64

When you say "not readable", what do you means ? What things did you tried ? You can use /sys/class/gpio or you can install RPi.GPIO-PineA64 and tweak it for matching the header since it is not the same as Pine64.

When installing new kernel, you should always install the DTB that comes from the same build, because there can be discrepancies across 2 builds. EDIT : I've just realized that maybe you are using Legacy build instead of Mainline, in such case DTB doesn't exist. BTW, did you carefully looked at the "dmesg" logs ?

Does it still appear as "eth0" in "ifconfig" ? What "dmesg" is showing ? Did you update DT from the same kernel build, ie .: installed the "linux-dtb-<version>.deb" ?

copy the linux-image-<version>.deb on the OPi, then execute "dpkg -i linux-image-<version>.deb"

Yes, it is a build from NEXT ... What this patch is doing exactly ? Sadly, I couldn't check previous history of that patch to see if it explains when previous issue disappeared...

Strangely, this randomness re-appeared using my newest build 4.13.3 ... (I will check if same thing will happened on OPiWin)

Since there are different kind of those relay board, try it without any connection to GPIO first, then you will figure out which is the right level required.

Good !!!

You first need to figured out what is the chip used in your USB WiFi. To do so, issue the "lsusb" command to figure out which manufacturer it is.

The schematic I've provided should be used when you design your own relay board. In your case, with an already made board, you can see that there is already a transistor or mosfet on the board. The question is to figured out what is the IN pin require, without seeing the schematic. Here is where google becomes handy : So, since it said that IN is low-level trigger, my previous schematic could be applied, the mosfet could drive the IN pin directly ...

Next time you need another, some of the kits provides the PSU : http://www.ebay.ca/itm/SATA-PATA-IDE-to-USB-2-0-Adapter-Converter-Cable-for-2-5-3-5-Inch-Hard-Drive-IN-/311837844163

Of course ! But you also need +5V/+12V Power Supply.

Right ! Header pins are not necessarily GPIOs, in this case, it is really two additional USB provided on pins 3 to 6.

What is the relation between GPIO and SATA ? None !

If you are talking about having Armbian full image stored in that SPI_NOR, no, it is too small ... But, an OpenWRT image would fit . If you are talking about just placing a U-Boot loader there and booting from USB, yes, it have been done before. Unfortunately, it seems that current u-Boot is currently broken for USB boot right now. But it is possible to use older Apritzel u-boot, I've one built back in May and still working to boot from an USB HDD.

Why ? Is it the wireless connection that you don't know how to do or is it how to install Apache Web Server ?

It been a while since I've checked/tested SPI-NOR ... Effectively, it seems broken now, probably since several u-boot versions. Fortunately, I still had a old u-boot working build in last March, and I've put back this one into SPI_NOR. EDIT : since I'm keeping a lost of previous images, I found out that another image build back in May was also working, we were still using Apriztel u-boot tree at that time. So the issue come most probably when we switched to Mainline u-boot recently ...

I doubt that NAND Flash would be supported now and in the future. Better try to find a board that is using eMMC instead ...

Looking at both schematics and DTS of BananaPro-A20 and A20-OLIMEX-MICRO, (I've some Olimex myself and I know OTG is working on them), it seems probable that BananaPro-A20 is only missing things are the following in Mainline DTS : &reg_usb0_vbus { status = "okay"; }; &usb_otg { dr_mode = "host"; status = "okay"; };

Pins 11 and 13 are not so strange, they are PL0/PL1 which provide S-TWI.

On OPiOne and OPiLite, there was similar issue that reg_usb0_vbus was not present. I've fix that a month ago with this commit : https://github.com/armbian/build/commit/fb0d3c6ea4b06df236d198af825d31a073dd2b81 Maybe similar patch could fix it on BananaPro ...

There is no power switch on those board ! When you do "shutdown" command, it bring the kernel in idle state, but the power supply is never disconnected. I think you don't understand the above schematic ... It is describing a power switch for the fan itself : R1 should be around 10K, it is there to make sure that when GPIO17 (17 is only an example, it could be any other GPIO) is left floating the MOSFET is turned OFF. If GPIO17 is HIGH (thru R2, which can be around 1K), the Gate of the MOSFET will be HIGH, therefore it will be turned ON, providing GND to the fan, so the fan will spin. You can, for example, add commands to turn GPIO to LOW or floating as input to /etc/init.d/halt script.