martinayotte
-
Posts
3892 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by martinayotte
-
-
For the first "[ warn ] ... scripts-dtc-Update-to-version-with-overlays.patch [ failed ]", it is the DTC version that changed between 4.6.x and 4.7.x.
I will do some fix for that :
--- a/scripts/dtc/version_gen.h +++ b/scripts/dtc/version_gen.h @@ -1 +1 @@ -#define DTC_VERSION "DTC 1.4.1-g53bf130b" +#define DTC_VERSION "DTC 1.4.1-g4273dca2"
-
I'm facing some other issues with 5.20 builds ...
U-Boot 2016.09-armbian seems to be unstable. I getting memory crashes once in awhile during boot. The kernel itself seems to be Ok since I've try it out with a previous 5.17 image.
[ 9.085019] Unable to handle kernel paging request at virtual address 40ddb5a3 [ 9.085024] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
I've tried to overwrite u-boot with the old U-Boot 2016.07-armbian, but it didn't help :
[ 9.007689] Unable to handle kernel paging request at virtual address ffffffef [ 9.007855] Unable to handlE kernel NULL pointer dereference at virtual address 00000048
What is strange, is that all this is under OrangePiLite, but it got is booted properly one time out of 10, and I didn't got such issue under OrangePiPlus2e neither OrangePiPC+.
Maybe question of luck ? I will see if multiple reboot on those last one will still be stable.
-
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
-
Oh ! that means that Megous's github that we are using is NOT up-to-date ... :-(
Ok ! We should grab those missing DTS ...
(btw, pure coincidence, other people got the issue too : http://forum.armbian.com/index.php/topic/2038-not-starting-after-update-to-520/)
-
I think I found why ...
The commit https://github.com/igorpecovnik/lib/commit/195de287f2fe68baf510ce77b28b4a129aa4d24e now using a more specific names for "fdtfile" but those DTS files don't exist yet in Mainline tree.
As you said, the workaround for now is to copy sun8i-h3-orangepi-pc.dtb into sun8i-h3-orangepi-pc-plus.dtb new file, the same is true with other flavors such "lite" and "plus2e".
-
Hi folks,
I've done a Armbian build for my OrangePi-Plus2e this morning, and discovered that U-Boot "fdtfile" is now set to sun8i-h3-orangepi-plus2e.dtb instead of sun8i-h3-orangepi-pc.dtb as previously.
Unfortunately, the sun8i-h3-orangepi-plus2e.dtb doesn't exist, I had to copy the sun8i-h3-orangepi-pc.dtb under the sun8i-h3-orangepi-plus2e.dtb name to make it boot.
Where in the build process we manage to set "fdtfile" during u-boot build ?
Is that done using mix of manipulations of configs found in config/boards/orangepiplus2e.conf (Zador recently changed it)
Also, on separate issue, I've discovered that /usr/lib/linux-u-boot-dev-orangepiplus2e_5.20_armhf/u-boot-sunxi-with-spl.bin wasn't written during the nand-sata-install, I had to manually do the "dd" to make it work. (But this isn't the first time I faced that, I had to do that in previous 5.17 too. Probably I will have to redo a new nand-sata-install with some traces it to figure out)
-
You were asking "for mainline", so device-tree files.
Using 'dtc' compiler, you have to decompile the DTB file into a DTS, add the above property, and recompile it back into a new DTB. (Keep a backup of the old DTB, just in case)
-
In mainline, you can add parameter in ethernet@1c30000 (or &emac) section like :
mac-address = [aa e3 14 b9 b5 12];
-
Should be pretty straight forward ...
Only setup() needs to be changed to setcfg() along with separate pullup() call since setcfg() doesn't have the third argument.
-
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" -
Of course, this version is patched one coming from the above github version (I've created the patch about a month ago).
-
Yes, you're right, I forgot to mention the dt-overlays8 branch ...
About speed issue, when I faced some, if it is the same as you, I've discovered that it was in the python library that was setting CONFIG_SPEED to 100KHz instead of 10MHz.
http://forum.armbian.com/index.php/topic/1523-spi-issue-with-banana-proa20/#entry13824
-
Sorry if I didn't gave details earlier.
Yes, you need to compile the DTBO, but using the DTC compiler supporting Dynamic Overlays developped by Pantelis Antoniou.
I can be found there : https://github.com/pantoniou/dtc.git
With this version, You need to invoke it with '-@' option :
dtc -@ -O dtb -I dts -o spidev-enable.dtbo spidev-enable.dts
-
I've been using Dynamic Overlay to load SPIs into the DTS. There is no need to do any modprobe, since the Kernel will load it automatically when DTS is updated.
mkdir /sys/kernel/config/device-tree/overlays/spi cat spidev-enable.dtbo > /sys/kernel/config/device-tree/overlays/spi/dtbo
// Enable the spidev interface
/dts-v1/;
/plugin/;
/ {
compatible = "allwinner,sun8i-h3";
fragment@0 {
target-path = "/aliases";
__overlay__ {
/* Path to the SPI controller nodes */
spi0 = "/soc@01c00000/spi@01c68000";
spi1 = "/soc@01c00000/spi@01c69000";
};
};
fragment@1 {
target = <&spi0>;
__overlay__ {
pinctrl-names = "default";
pinctrl-0 = <&spi0_pins_a>, <&spi0_cs0_pins_a>;
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
spidev@0 {
compatible = "spidev";
reg = <0x0>;
spi-max-frequency = <1000000>;
};
};
};
fragment@2 {
target = <&spi1>;
__overlay__ {
pinctrl-names = "default";
pinctrl-0 = <&spi1_pins_a>, <&spi1_cs0_pins_a>;
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
spidev@0 {
compatible = "spidev";
reg = <0x0>;
spi-max-frequency = <1000000>;
};
};
};
}; -
All Armbian images are using a U-Boot that is EXT4 aware, so SD images has only one EXT4 partition.
As Pieter said, checking the debug serial output will help to figure where it is choking.
Tip: attach a ttl-usb cable between your orange pi and your pc and watch what happens on boot.
-
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.
-
You probably means a "reset" switch ...
http://forum.armbian.com/index.php/topic/1429-orange-pi-one-hardware-reset/
-
The command is mentioned as a comment at the end of boot.cmd :
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
-
If you are using orangepi_PC_gpio_pyH3 and not mixing with other libs, the following is working for me (note the lower cases) :
from pyA20.gpio import gpio from pyA20.gpio import port gpio.init() gpio.setcfg(port.PA1, gpio.OUTPUT) gpio.setcfg(port.PA20, gpio.OUTPUT)
-
Yes, you should not mix 2 kind of GPIO libraries in the same project, it is even dangerous.
For GPIO.setup() issue, it should be GPIO.setcfg(), but no needs to do it for SPIMOSI or SPIMISO, since the SPI.open() will do that for you.
from pyA20 import spi spi.open("/dev/spidev0.0") -
For those who are interested, here are some DT Overlay samples.
i2c-enable.dts :
// Enable the i2c interface
/dts-v1/;
/plugin/;
/ {
compatible = "allwinner,sun8i-h3";
fragment@0 {
target-path = "/aliases";
__overlay__ {
/* Path to the i2c2 controller node */
i2c0 = "/soc@01c00000/i2c@01c2ac00";
i2c1 = "/soc@01c00000/i2c@01c2b000";
i2c2 = "/soc@01c00000/i2c@01c2b400";
};
};
fragment@1 {
target = <&i2c0>;
__overlay__ {
status = "okay";
};
};
fragment@2 {
target = <&i2c1>;
__overlay__ {
clock-frequency = <400000>;
// clock-frequency = <100000>;
status = "okay";
};
};
fragment@3 {
target = <&i2c2>;
__overlay__ {
status = "okay";
};
};
};spidev-enable.dts :
// Enable the spidev interface
/dts-v1/;
/plugin/;
/ {
compatible = "allwinner,sun8i-h3";
fragment@0 {
target-path = "/aliases";
__overlay__ {
/* Path to the SPI controller nodes */
spi0 = "/soc@01c00000/spi@01c68000";
spi1 = "/soc@01c00000/spi@01c69000";
};
};
fragment@1 {
target = <&spi0>;
__overlay__ {
pinctrl-names = "default";
pinctrl-0 = <&spi0_pins_a>, <&spi0_cs0_pins_a>;
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
spidev@0 {
compatible = "spidev";
reg = <0x0>;
spi-max-frequency = <1000000>;
};
};
};
fragment@2 {
target = <&spi1>;
__overlay__ {
pinctrl-names = "default";
pinctrl-0 = <&spi1_pins_a>,
<&spi1_cs0_pins_a>;
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
spidev@1{
compatible = "spidev";
reg = <0>;
spi-max-frequency = <1000000>;
};
};
};
}; -
For those who are interested, here are some DT Overlay samples.
i2c-enable.dts :
// Enable the i2c interface
/dts-v1/;
/plugin/;
/ {
compatible = "allwinner,sun8i-h3";
fragment@0 {
target-path = "/aliases";
__overlay__ {
/* Path to the i2c2 controller node */
i2c0 = "/soc@01c00000/i2c@01c2ac00";
i2c1 = "/soc@01c00000/i2c@01c2b000";
i2c2 = "/soc@01c00000/i2c@01c2b400";
};
};
fragment@1 {
target = <&i2c0>;
__overlay__ {
status = "okay";
};
};
fragment@2 {
target = <&i2c1>;
__overlay__ {
clock-frequency = <400000>;
// clock-frequency = <100000>;
status = "okay";
};
};
fragment@3 {
target = <&i2c2>;
__overlay__ {
status = "okay";
};
};
};spidev-enable.dts :
// Enable the spidev interface
/dts-v1/;
/plugin/;
/ {
compatible = "allwinner,sun8i-h3";
fragment@0 {
target-path = "/aliases";
__overlay__ {
/* Path to the SPI controller nodes */
spi0 = "/soc@01c00000/spi@01c68000";
spi1 = "/soc@01c00000/spi@01c69000";
};
};
fragment@1 {
target = <&spi0>;
__overlay__ {
pinctrl-names = "default";
pinctrl-0 = <&spi0_pins_a>, <&spi0_cs0_pins_a>;
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
spidev@0 {
compatible = "spidev";
reg = <0x0>;
spi-max-frequency = <1000000>;
};
};
};
fragment@2 {
target = <&spi1>;
__overlay__ {
pinctrl-names = "default";
pinctrl-0 = <&spi1_pins_a>,
<&spi1_cs0_pins_a>;
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
spidev@1{
compatible = "spidev";
reg = <0>;
spi-max-frequency = <1000000>;
};
};
};
}; -
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 ?)
Some discovery while trying 5.20 builds
in Advanced users - Development
Posted
I can reboot multiple times with my previous 5.17 image with the newer 4.7.4 kernel inside it without any issues ...
So, it must be something else.