[nano-sata-install script not working]

So, the problem isn't there !

I'm running out of ideas...

Maybe you will have to try again the nand_sata_install to see if it still fail.

[nano-sata-install script not working]

can you show what you have in your /etc/fstab (the one located in the eMMC, not the one on SDCard) ?

[nano-sata-install script not working]

With this log, it is clearly showing that mmcblk2p1 is mounted.

 

So, why are you saying that it is not working ?

[Any PYTHON gpio library for H3 ?]

Do you mean you were using this one https://github.com/duxingkei33/orangepi_PC_gpio_pyH3

Maybe the missing pins could be added in orangepi_PC_gpio_pyH3-master/pyA20/gpio/mapping.h

[Finishing vanilla kernel support for H3?]

I've done a PR for applying those Dynamic DT Overlays patches into "sunxi-next".

Next thing to do is to apply it also into "sunxi-dev".

 

EDIT : "sunxi-dev" done ! it was a bit more work since part of the patches were not required anymore in 4.8.x

[Orange Pi PC: Fan on GPIO]

Since initial state, as zador mentioned, is "input, no pullup", you will need to add pullup or pulldown depending of what Pmos/Nmos you choose and the initial state you wish to have.

[Finishing vanilla kernel support for H3?]

Thanks Zador for your feedback !

I'm not fluent with the whole build process, so I will have to figure out how to get those overlays sample copied from /bin to /lib/firmware/overlays of the final image.

 

BTW, today, I've decided to revamp my OlinuXinoA20-Micro with full image. I saw that patching mechanism used /patch/kernel/sunxi-* instead of /patch/kernel/sun8i-* for H3 didn't bring by patches, so I will have to port my Dynamic DT Overlays patches for that target too. It should be trivial, I hope so, I will see tomorrow ...

[NanoPI NEO / AIR]

 

it has LEDs on the TX and RX likes which may be acting as pull downs

 

That is a bit of myth in some people's thinkings. If they were acting like that, it would means that LED is in conducting mode.

Same thing applied when LED is connected in Sink mode, it doesn't act as PullUp, otherwise it will glow ...

[Finishing vanilla kernel support for H3?]

Unfortunately, I don't see much comments about my recent works ...

 

http://forum.armbian.com/index.php/topic/1633-dynamic-device-tree-overlays/

http://forum.armbian.com/index.php/topic/1537-397-maintainfix-dts-entries-for-some-devices-such-i2cspiw1/

 

Did someone has chances to give it try or I'm the only one using it to load overlays ?

 

As asked in the PRs (which didn't have much comments either, even if officially merged), where should Armbian image should provide DT overlays samples ?

Should it be a bit like BeagleBone locating them somewhere like /lib/firmware/overlays ?

(I've now having some overlays ready such i2c-enable.dtbo, spi-enable.dtbo and w1-gpio-overlay.dtbo. Others such mcp-enable.dtbo, gpio-keys.dtbo and matrix-keypad.dts could be added soon if well tested.)

[SPI issue with Banana Pro/A20]

Ok ! I dig a bit more ...

In fact, the commit above done 9 months ago in Mainline is legitimate and it only cause a bug/mistake in the orangepi_PC_gpio_pyH3 to come to the surface and been discovered :

diff orangepi_PC_gpio_pyH3-master/pyA20/spi/spi.c.bak orangepi_PC_gpio_pyH3-master/pyA20/spi/spi.c
239c239
<     config.speed = 100000;
---
>     config.speed = 10000000;

As you can see, the author was setting "transfer speed" default to 100kHz instead of 10MHz ...

 

I won't blame duxingkei33 who simply ported the original pyA20 from Olimex to H3, but Stefan Mavrodiev author of the Olimex one.

 

EDIT : I've opened issue on both github :

https://github.com/OLIMEX/OLINUXINO/issues/39

https://github.com/duxingkei33/orangepi_PC_gpio_pyH3/issues/4

[SPI issue with Banana Pro/A20]

I've took some time to dig the issue and I've found something by diffing my old 4.4.5 and my 4.6.2 :

diff sources/linux-vanilla/v4.4.5/drivers/spi/spi-sun6i.c sources/linux-sun8i-mainline/orange-pi-4.6/drivers/spi/spi-sun6i.c
220,221c220,221
< 	if (mclk_rate < (2 * spi->max_speed_hz)) {
< 		clk_set_rate(sspi->mclk, 2 * spi->max_speed_hz);
---
> 	if (mclk_rate < (2 * tfr->speed_hz)) {
> 		clk_set_rate(sspi->mclk, 2 * tfr->speed_hz);
239c239
< 	div = mclk_rate / (2 * spi->max_speed_hz);
---
> 	div = mclk_rate / (2 * tfr->speed_hz);
246c246
< 		div = ilog2(mclk_rate) - ilog2(spi->max_speed_hz);
---
> 		div = ilog2(mclk_rate) - ilog2(tfr->speed_hz);

Mainline guys introduced the usage of "transfer speed" instead of using "spi max speed".

Until now, I didn't find where the "transfer speed" is initialized, and probably it is never initialized.

 

So, workaround for now, is to revert to the "spi max speed" ...

[nano-sata-install script not working]

Boot from sdcard, redo nand_sata_install again, it is doesn't work, you can fix it manually but doing something like :

 

dd if=/usr/lib/linux-u-boot-dev-orangepipcplus_5.17_armhf/u-boot-sunxi-with-spl.bin of=/dev/mmcblk2 bs=1024 seek=8

 

(I've wrote /dev/mmcblk2 because I'm using Mainline kernels, but on Legacy, it could be /dev/mmcblk1 instead, I'm not sure)

 

 

[Migrate from Orange Pi Plus 2 to Orange Pi Plus 2E]

In the OPi+2E, the driver is the F one, since it is the SDIO variant : 8189fs

[SPI issue with Banana Pro/A20]

In fact, I've also used an small ST7735 display on one of my OPiPC, it was working fine in 4.4.4 and 4.4.5, but when I've upgraded in 4.5.x and even later 4.6.x, it was horribly slow (displaying a clock even skip some seconds sometimes).

Unfortunately, I didn't get chance to narrow the reasons and didn't spent too much time on the case, since it wasn't my priority and "time is still the missing ingredient".

I presume it is a bug introduced somehow in clock management of Mainline.

[Opi lite MAC address]

That's explain everything ...

If I remember when I faced the same issue, I've explicitly copied the current MAC into the 8189fs.conf file, so I "fixed" the issue by placing a 00:e0:4c manually.

 

In mainline, it looks like the same code, because in fact, when I commit it, the sources was merged with Hans changes, but origins are common.

 

I see that the random init is using this code :

               *((u32 *)(&mac[2])) = rtw_random32();
               mac[0] = 0x00;
               mac[1] = 0xe0;
               mac[2] = 0x4c;

So, Yes, the firstrun should place the same RealTek prefix.

[Opi lite MAC address]

I'm using Mainline 4.6.2, and this /etc/modprobe.d/8189fs.conf works for me, it keep the same MAC at every reboot.

But I don't know if the same happen in Legacy kernel.

[Opi lite MAC address]

Maybe there was something missing in 5.14, but in 5.17 the firstrun script is creating the file : /etc/modprobe.d/8189fs.conf, it should looks like :

options 8189fs rtw_initmac=00:e0:4c:f5:16:d8

 

[[420] - Build tools testing, for improvements and/or documentation]

 

This could be a bug - can you reproduce?

 

Yes, I've seen that too.

In a build log, I found that error :

[[[0;32m o.k. [[0m] Checking toolchain [[[0;33m gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux [[0m]
[[[0;32m .... [[0m] Downloading
[[[0;32m .... [[0m] Verifying
[[[0;35m warn [[0m] Verification failed

[WiringOP sudo su with orange pi plus 2]

For GPIO, take a look at https://github.com/duxingkei33/orangepi_PC_gpio_pyH3

[[397] - maintain/fix DTS entries for some devices such I2C/SPI/W1]

I'm not sure to following you ...

Do you means a NIC that wasn't defined in the top level DTB ?

This scenario are pretty rare, but you it should be doable if top level expose everything needed.

But I don't see the advantages, especially if this NIC needs to be present all the time.

Overlays are best suit for things that require to be loaded/unloaded dynamically.

Currently, I have I2C, SPI and W1 sample overlays.

[[397] - maintain/fix DTS entries for some devices such I2C/SPI/W1]

Such as ?

[[397] - maintain/fix DTS entries for some devices such I2C/SPI/W1]

@lanefu, DT overlays are small pieces of DT definitions that can be loaded in the kernel DT at any time from user-space and kernel will notify drivers accordingly.

So, with my current samples, I could, for example, make the I2C buses appearing and disappearing from the following shell command :

mkdir /sys/kernel/config/device-tree/overlays/mydtbo
cat i2c-enable.dtbo > /sys/kernel/config/device-tree/overlays/mydtbo/dtbo
echo "overlay loaded ..."
echo "doing here more stuff ..."
rmdir /sys/kernel/config/device-tree/overlays/mydtbo
echo "overlay unloaded ..."

[Docker on H3 Armbian]

I'm doing copy/paste of the same answer posted in this other thread where the same news is posted : http://forum.armbian.com/index.php/topic/1666-mainline-moving-target/#entry13033

 

First, that pretty new, so let's the dust settle down !

Second, I don't know your knowledge about Kernel development, but you should remember that odd/even number in branches under Linux means Stable/Dev branches.

Stable 4.6.x cames out few months ago after a lot revamps in 4.5.x. This is now the Stable, and we are now using 4.6.4 in Armbian if you build your own kernel, but no image published yet since there are some stuff missing.

New 4.7.x can be interesting in a future, but it is probably NOT for you, except if you wish to become a Mainline kernel developer ...

 

[Dynamic Device-Tree Overlays]

Unfortunately, I don't see much comments about my recent works ...

 

http://forum.armbian.com/index.php/topic/1537-397-maintainfix-dts-entries-for-some-devices-such-i2cspiw1/#entry13032

[Mainline moving target]

First, that pretty new, so let's the dust settle down !

Second, I don't know your knowledge about Kernel development, but you should remember that odd/even number in branches under Linux means Stable/Dev branches.

Stable 4.6.x cames out few months ago after a lot revamps in 4.5.x. This is now the Stable, and we are now using 4.6.4 in Armbian if you build your own kernel, but no image published yet since there are some stuff missing.

New 4.7.x can be interesting in a future, but it is probably NOT for you, except if you wish to become a Mainline kernel developer ...