martinayotte

you should look here in cache/sources/linux-mainline/linux-5.4.y/Documentation/devicetree/bindings/display/

I doubt since even "screenfetch" isn't part of Armbian images ...

Nothing special, but maybe ‘struct rw_semaphore’ has changed across kernel versions and ‘owner’ has been removed. To get AUFS working, maybe it require a fix to RT patches to match that change.

You can try to compile with "AUFS=no" ...

It looks like you try to achieve interfacing a 26 bits Wiegand keyfob reader ... Right ? In such case, I would rather dedicate a small MCU such Atmel328 doing this decoding job, and report the result over serial port to the BananaPi.

Rockchip SoCs always have eMMC as boot priority. So, to boot from SDCard, you need to stop U-Boot from eMMC by pressing <spacebar> several times during startup. Then, at U-Boot command line, you can type "setenv devnum 1" followed with "run mmc_boot", it will then boot from SD.

If it been seen on the I2C bus, you can try some library such as the one from Adafruit ...

"Merge Request", equivalent to PR which is "Pull Request" ...

Probably those dtbo were never been part of the build. Feel free to send a PR for this Makefile correction ...

Then, maybe it is I2C speed issue ...

Did you checked the presence of the device with "i2cdetect" ? Did you checked the permissions of /dev/i2c-1 and running your test script under proper user/group ?

Sorry, I don't see any things which could be obviously wrong ...

Are you using UART2 ? Because UART2 also use PA0/PA1 if enabled ...

Which patch ? The one I've post on Dec 6th ? ... Sure !

Not at all ! You are trying to build something that is not own by Armbian ... BTW, Jessie is now End-of-Life ...

Right !

This <0> means to use default hardware spi-cs0, while the second argument to cs-gpios is the new gpio for CS1 ...

The RAM chip needs an additional address line from the H3 SoC to decide if it is addressing the upper or lower bank of the memory. If the OPiPC PCB was designed in function to use 1GB, and didn't provided this additional address line to be compatible with 2GB chips, then this line will be left floating on the chip and can even not be limited to the first 1GB bank, but can even give random memory data depending of if the floating line will be treat as LOW or HIGH depending of the EFI, it will return the wrong data.

The PCB routing doesn't provide the extra address line to allow upgrading RAM ...

Normally, other TWI ports are using 2K pullups, but on both SDA and SCK. Did you tried with both pullups ?

This is usually symptom of missing pullups ! According to schematic, the TWI0 and TWI1 has pullups provided by the OPiZ+2, but none are provided for S-TWI, you need to add them yourself ...

So, it should work ... Also, "i2cdetect -l" should reveal its presence ... Maybe it is the attached devices that doesn't respond ... Do you have PullUps on those ?

What "cat /proc/device-tree/soc/i2c@1f02400/status" is reporting ? "okay" or "disabled" ? Did you tried to change ' pins = "PL0\0PL1"; ' to ' pins = "PL0", "PL1"; ' instead ?

I've use a small proto pcb, soldered a female header along with a SMT to DIP adaptor where I soldered the SPI-NOR flash, connect SPI signals to header. Then, I've compile a Armbian image with user-patch for U-Boot Pine64 DTS, along with an DT overlay for the kernel that provide MTD partition. To push U-Boot to the flash, I've used "flashcp" from "mtd-utils" package to /dev/mtd0 partition.

Most probably that the /boot/armbianEnv.txt is corrupted since it is where "rootdev" is set/overwrite the one defined in /boot/boot.scr ...