martinayotte

The scripts-dtc-Update-to-version-with-overlays.patch should already work "as is" in 4.8, I presume add_missing_UARTs_I2Cs_SPI_for-H3.patch too.
For patch-for-rtl8189fs-sun8i-h3-orangepi-pc-dts.patch, I don't know ...

It seems that there is a bug with improper path while trying to copy the u-boot-sunxi-with-spl.bin into the eMMC.
 
The workaround for now is booting from your sdcard and writing the u-boot manually :
dd if=/usr/lib/linux-u-boot-dev-orangepipcplus_5.20_armhf/u-boot-sunxi-with-spl.bin of=/dev/mmcblk2 bs=1024 seek=8 Then reboot without sdcard, it should work.

Ok ! Doing an upgrade of my OrangePi-PCPlus, I've narrowed the "nand-sata-install" issue ...
It try to write the u-boot-sunxi-with-spl.bin from the wrong path !
 
The trace has given me this wrong path :
 
/usr/lib/linux-u-boot-orangepipcplus_5.20_armhf/u-boot-sunxi-with-spl.bin
 
while the actual file is in this location (notice the missing "dev-" in the wrong one) :
 
/usr/lib/linux-u-boot-dev-orangepipcplus_5.20_armhf/u-boot-sunxi-with-spl.bin

Ok ! Doing an upgrade of my OrangePi-PCPlus, I've narrowed the "nand-sata-install" issue ...
It try to write the u-boot-sunxi-with-spl.bin from the wrong path !
 
The trace has given me this wrong path :
 
/usr/lib/linux-u-boot-orangepipcplus_5.20_armhf/u-boot-sunxi-with-spl.bin
 
while the actual file is in this location (notice the missing "dev-" in the wrong one) :
 
/usr/lib/linux-u-boot-dev-orangepipcplus_5.20_armhf/u-boot-sunxi-with-spl.bin

You can simply use GPIO internal pullups by enabling them.
By using orangepi_PC_gpio_pyH3 ( https://github.com/duxingkei33/orangepi_PC_gpio_pyH3), python code will look like :
from pyA20.gpio import gpio from pyA20.gpio import port gpio.setcfg(port.PA1, gpio.INPUT) gpio.pullup(port.PA1, gpio.PULLUP) if gpio.input(PA1) > 0: print "not pressed" else: print "pressed"

You can simply use GPIO internal pullups by enabling them.
By using orangepi_PC_gpio_pyH3 ( https://github.com/duxingkei33/orangepi_PC_gpio_pyH3), python code will look like :
from pyA20.gpio import gpio from pyA20.gpio import port gpio.setcfg(port.PA1, gpio.INPUT) gpio.pullup(port.PA1, gpio.PULLUP) if gpio.input(PA1) > 0: print "not pressed" else: print "pressed"

Usually, such issues can happened when doing a "dd" while sd is still mounted with previous partitions.
Making sure no partition are mounted before issuing the "dd" command is a good practice.

For those who are interested, here are some DT Overlay samples.
 
i2c-enable.dts :
 
 
 
spidev-enable.dts :
 
 

HI TKaiser,
Ok, until recently (my last build on Aug 20th), we were still using the orange-pi-4.6, so I will take a look.
In fact, for the sunxi-dev, I've already done the change by simply using the same patch done for 4.8 into 4.7.
So, I'm currently doing a new build, if it is the same case, I will commit the things needed : delete or disabling the old 4.6.x and copy the 4.8 into a 4.7.x.
 
EDIT : We are still using orange-pi-4.6 in the sun8i-dev config, but I gave a try switching it to orange-pi-4.7.
I will commit those changes soon. I hope the switch from 4.6.x to 4.7.x won't cause any other patch issues.
(For the schedutil governor, I'm not fluent with those pieces ... What we have to do exactly ?)

This is because the "sudo" command apply only to the "echo", not to the redirection of the output.
 
Try the following instead :
sudo su - -c "echo 203 > /sys/class/gpio/export"

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

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

Those past days, I was working on getting DT ConfigFS Overlays into sun8i-dev.
 
Today, I've suddenly saw that the version from that we are using from https://github.com/megous/linux(branch orange-pi-4.6) change from 4.6.2 to 4.6.4.
I didn't care much until I figured out that we loose all the UART1/2/3/4 (only keeping the debug UART0) as well as all I2C (except the one on r_pio for PMIC).
 
So, "megous" github is back to almost what linux-sunxi github is providing, without all the patches for UART/I2C that I had prepared 3 months ago.
I get I will have to re-integrate them on our side until there merge into real linxx-sunxi branch.
 
 
 

You're right !
I've done new build today, and it worked !
(Probably when I did it more than a week ago, still with 4.6.2, there was some patches missing about cpu throttling which is now included)

I posted 2 days ago some progress on Dynamic Device Tree Overlays, but I think I should report here too.
 
http://forum.armbian.com/index.php/topic/1633-dynamic-device-tree-overlays/#entry12696
 
 
I've been studying and working on Dynamic Device-Tree Overlays since awhile, but after hard work, I've finally got a working prototype using the work from Pantelis Antoniou.
 
During last few days, I was doing debugging to find out why it wasn't working, even if I got the ConfigFS working, it was refusing to grab my simple overlay test.
I've finally figured out this afternoon : the Root/Base DTB need also to be compiled with the "symbols" list generated with the Antoniou's version of "dtc".
 
So, I will probably prepare a patch soon and submit it thru a PR.

I posted 2 days ago some progress on Dynamic Device Tree Overlays, but I think I should report here too.
 
http://forum.armbian.com/index.php/topic/1633-dynamic-device-tree-overlays/#entry12696
 
 
I've been studying and working on Dynamic Device-Tree Overlays since awhile, but after hard work, I've finally got a working prototype using the work from Pantelis Antoniou.
 
During last few days, I was doing debugging to find out why it wasn't working, even if I got the ConfigFS working, it was refusing to grab my simple overlay test.
I've finally figured out this afternoon : the Root/Base DTB need also to be compiled with the "symbols" list generated with the Antoniou's version of "dtc".
 
So, I will probably prepare a patch soon and submit it thru a PR.

I've been studying and working on Dynamic Device-Tree Overlays since awhile, but after hard work, I've finally got a working prototype using the work from Pantelis Antoniou.
 
During last few days, I was doing debugging to find out why it wasn't working, even if I got the ConfigFS working, it was refusing to grab my simple overlay test.
I've finally figured out this afternoon : the Root/Base DTB need also to be compiled with the "symbols" list generated with the Antoniou's version of "dtc".
 
So, I will probably prepare a patch soon and submit it thru a PR.
 

I've been studying and working on Dynamic Device-Tree Overlays since awhile, but after hard work, I've finally got a working prototype using the work from Pantelis Antoniou.
 
During last few days, I was doing debugging to find out why it wasn't working, even if I got the ConfigFS working, it was refusing to grab my simple overlay test.
I've finally figured out this afternoon : the Root/Base DTB need also to be compiled with the "symbols" list generated with the Antoniou's version of "dtc".
 
So, I will probably prepare a patch soon and submit it thru a PR.
 

I've been studying and working on Dynamic Device-Tree Overlays since awhile, but after hard work, I've finally got a working prototype using the work from Pantelis Antoniou.
 
During last few days, I was doing debugging to find out why it wasn't working, even if I got the ConfigFS working, it was refusing to grab my simple overlay test.
I've finally figured out this afternoon : the Root/Base DTB need also to be compiled with the "symbols" list generated with the Antoniou's version of "dtc".
 
So, I will probably prepare a patch soon and submit it thru a PR.
 

I've been studying and working on Dynamic Device-Tree Overlays since awhile, but after hard work, I've finally got a working prototype using the work from Pantelis Antoniou.
 
During last few days, I was doing debugging to find out why it wasn't working, even if I got the ConfigFS working, it was refusing to grab my simple overlay test.
I've finally figured out this afternoon : the Root/Base DTB need also to be compiled with the "symbols" list generated with the Antoniou's version of "dtc".
 
So, I will probably prepare a patch soon and submit it thru a PR.
 

For the 1 core in /proc/cpuinfo, I've just figured out now (I didn't noticed before) that all my newer kernels (4.6.2) on orangepilite/orangepipcplus/orangepiplus2e have only 1 core while older ones 4.6.0+ on orangpipc/orangepione have 4 core. So, maybe a bug introduced recently somehow ...
 
EDIT : Oh ! looking at the root DTS, there wasn't any of this clock stuff defined in 4.6.0+, and in the 4.6.2 it is defined but only for cpu0. So, I wonder if only duplicating it for cpu1/cpu2/cpu3 will do the job.

MIPSbian ...

Ok, for the THS, adding back the 1008000 entry is a kind of ugly workaround : during boot FREQ switch is crashing, but at least it continue to boot completely.
I presume that real fix would not be adding it, but change the value at the origin of that 1008000, which is probably in u-boot, but this is outside of my knowledge.
@Tkaiser, the patches you mentioned, and even Megi's change doesn't seem to be part of the Armbian build process. Maybe patches are not applied for some reason.
 
@jernej, I started doing what you've said, I got some part done, but now I'm a bit lost about platform files searching for the legacy sys_config.h

I've received my OPi-Plus-2E this afternoon and done a fresh new Mainline build 5.14 kernel 4.6.2
 
I've soon discovered that 8189fs was not part of my fresh build.
I've done the same thing I did few days ago with my OPi-Lite : patch DTS and build rtl8189fs drivers borrowed from Legacy after apply Hans equivalent patch suggested to me by @jernej, and got it working.
I will probably probably have to prepare real patches for the official builds soon.
 
I've seen that eth0 is also not working, but I didn't investigated yet...
There is also the eMMC not present, but I think this one is related to new patches needed, I've seen several post on linux-sunix mailing list.
 
BTW, does someone have a link to schematic/board-layout for the OPi-Plus-2E board ?
(I didn't find it, I have all of them for others board I have, PC, One, Lite, but I wish to get this one as well as OPi-PC+ that I should received next week)

I've been working on the rtl8189fs patches for Mainline.
 
Althouth the source code change between Legacy and Mainline is pretty trivial, preparing good and nice patches becomes a tedious task :
 
- First, the original patch in Legacy contains tons of DOS file formatted (strange for a Linux driver, shame on Realtek) and even dos2unix failed on some files because of binaries character (probably Chinese), I had to edit many files because I wouldn't "signed-off" such ugly thing. (btw, maybe that dos2unix job should be done one Legacy to make it cleaner)
 
- It is a quick big patch, but about the same size as the one in Legacy, about 10MB of text file.
 
- Even after applying the patch, we still need to have some other patches, one for DefConfig in Igor's lib/config and one for DTS which I will work on tomorrow ...
 
- Then, lots of testing need to be done, especially that I need to figured out that everything is working in the fresh build environment, then a PR will be sent to Igor.