martinayotte

Such as ?

@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 ..."

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

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

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 ...

Unfortunately, I don't see much comments about my recent works ... I wish to get some feedback if some of you tried it out, although, of course, most of you don't have yet my sample overlays, such i2c-enable.dtbo/spi-enable.dtbo/w1-enable.dtbo. This bring me again the question : where should those samples should be located in standard images ? (On beaglebone, they provide some in /lib/firmware)

Oh ! I got the issue again : Now, I start understand ... The issue is on my OrangePi-Lite (and probably on the PiOne too), which doesn't have the same freq switcher than PCs. I've put back "sec" instead of "nosec" and it is booting with only 1 CPU.

Today, I've also added the SPI pins and SoC, tested quickly with a loopback wire and famous spidev_test.c.

PR is now sent : https://github.com/igorpecovnik/lib/pull/421 I've faced some issues because of switch from 4.6.2 to 4.6.4 as well as u-boot from v2016-05 to v2106-07, but I get thru those ...

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)

Unfortunately, I don't know how, it should be doable since the schematic mentioned that SPI1_CS1 is the PH7 pin, but it is already used in DTS for UART3 as well as for Codec (which lead me to some confusion). Also, I don't know how the kernel drivers will handle it ...

Is this have been properly tested ? (because last time I've try "nosec" more than a week ago, it was crashing during boot. I don't remember on which Orange flavours I was trying it)

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.

So, that dongle wasn't so innocent ...

Good ! So, enjoy your new UART ...

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 don't see why editing the FEX with only the above changes would prevent from booting properly. Maybe the whole image is badly written or the SDCard defective. Try to redo the whole image, make sure it is booting, and then redo the FEX changes.

The UART available on pin 8 and 10 on the Pi header is the UART3, while the UART2 is located on pin 11 and 13. So, in the FEX, for the UART3, you simply need to enable it (uart_used = 1) and remove the corresponding pins (PA13/PA14) from the GPIO list. For the UART2, the pins to remove from GPIO list are PA00/PA01/PA02/PA03.

@tkaiser, Could you provide links for your best choices of USB-SATA ? I've purchased one 1 year ago, but never use it yet. Maybe you should test it with my OPi-Plus-2E ...

But the library that I've provided link above has I2C included as pyA20.i2c, I'm using it without any problem. As you said, it is probably the code checking for dependencies that need to be tweaked.

@jernej, thanks anyway ! @lanefu, thanks for the hint, for as soon I'm trying to change bootm_boot_mode to "nonsec", I'm getting a kernel panic with my 4.6.2 ... @tkaiser probably could help to figure out about this bootm_boot_mode, since he added it as "sec" to boot.cmd on Feb 19th : https://github.com/igorpecovnik/lib/commit/80247916c6631a84eed2a9b040aed8bac430af4b

Do you mean that it is some kind of regression bug introduced recently in u-boot ? EDIT : searching quickly, I've only find #define CONFIG_ARMV7_PSCI_NR_CPUS 4 in u-boot/v2016.05/u-boot.cfg.

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.

You probably simply need to install the https://github.com/duxingkei33/orangepi_PC_gpio_pyH3 version first, and then Adafruit's ones.