Banana PRO: Testers wanted! SATA drive not working on some boards.

[Gordon]

Wrong u-boot version or failed installation?

 

@Gordon

what is output of "dpkg -l | grep u-boot"?

 

Sure thing:

root@bananapi:~# dpkg -l|grep u-boot
ii  linux-u-boot-bananapi-next      5.01                      armhf        Uboot loader 2016.01
ii  u-boot-tools                    2014.10+dfsg1-5           armhf        companion tools for Das U-Boot bootloader

@igor

 

Only thing I can think of is, I'm using external power source to power the hard disk. Will it be different?

 

Like I mentioned previously, same set up can work under previous build (4.5) or other distro (with kernal 4.3.3)

 

Thanks again.

[zador.blood.stained]

Can you try installing this u-boot on fresh Armbian 5.00 image if you have some time and a spare microSD card/time to backup and restore?

 

Only thing I can think of is, I'm using external power source to power the hard disk. Will it be different?

5V/12V power is not the problem here, 2.5V that powers SATA part of SoC is.

[Gordon]

Thanks Zador, every thing I post is based on a freash armbian 5.00 image.

 

I did have two TF card, and only try new image on the spare one.

[Skygod]

I have Banana M1+ and a spare 16Gb SD card, so am willing to test anything if required.

[Igor]

I have Banana M1+ and a spare 16Gb SD card, so am willing to test anything if required.

 

Problem appear only on Lemaker Banana PRO.

[m_g_s_g]

Hello,

 

I'm trying to upgrade my current cubieboard2 server to a banana-pro-based one (to improve my ethernet throughput), and I'm experiencing exactly the same situation as Gordon. (Banana Pro with external 3.5 hdd. Brand new 16Gb sd with freshly loaded Armbian jessie vanilla image - I just changed passwords & hostname, updated&upgraded and installed samba).

 

Just in case, I'm using a 4Tb drive (some people say that the bpro supports them when externally powered), connected to the cubieboard2 "3.5 inch hdd addon package" (but changed the 5V hdd power polarity to comply with Banana Pro's one).

 

(EDIT: and yes, I upgraded U-Boot today)

 

Thx for your help

[jobenvil]

The only thing i did in addition was changing "ext4load mmc 0 0x49000000 /boot/dtb/sun7i-a20-bananapro.dtb in /boot/boot.cmd", but i think that should not make the difference.

I can confirm this weird behaviour: "changing "ext4load mmc 0 0x49000000 /boot/dtb/sun7i-a20-bananapro.dtb in /boot/boot.cmd" and it made the difference between recognice the SATA or not at the boot time (and after that as well).

 

The prebuilt image (with u-boot 5.0.0 & 5.0.1) doesn't work with SATA until we linked the dtb files with the model "bananapro" and not with bananapi default, which is automatically triggered after every upgrade.

 

Changing boot.cmd from default to "sun7i-a20-bananapro.dtb" will do the magic:

ext4load mmc 0 0x49000000 /boot/dtb/sun7i-a20-bananapro.dtb || fatload mmc 0 0x49000000 /dtb/sun7i-a20-bananapro.dtb

having this packages installled:

root@bananapi:/boot# dpkg -l|grep next
ii  linux-dtb-next-sunxi                5.00                              armhf        Linux DTB, version 4.4.1-sunxi
ii  linux-firmware-image-next-sunxi     5.00                              armhf        Linux kernel firmware, version 4.4.1-sunxi
ii  linux-headers-next-sunxi            5.00                              armhf        Linux kernel headers for 4.4.1-sunxi on armhf
ii  linux-image-next-sunxi              5.00                              armhf        Linux kernel, version 4.4.1-sunxi
ii  linux-u-boot-bananapi-next          5.01                              armhf        Uboot loader 2016.01
ii  linux-wheezy-root-next-bananapi     5.00                              armhf        Root file system tweaks for bananapi

This starts to be litte tricky; since my first ARMBIAN version (4.0.5 ~  Juli 2015) for Banana Pro I suffered with every ARMBIAN upgrade this collateral damage because banana pi and pro are not properly recogniced.

 

Why this? It is not possible to trigger the scripts to manage both separatedly?

 

 

I tested:

 

1) SATA error manifests with this error on u-boot 5.0.1:

 3.477254] ahci-sunxi 1c18000.sata: controller can't do PMP, turning off CAP_PMP
[    3.477317] ahci-sunxi 1c18000.sata: SSS flag set, parallel bus scan disabled
[    3.477351] ahci-sunxi 1c18000.sata: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl platform mode
[    3.477367] ahci-sunxi 1c18000.sata: flags: ncq sntf stag pm led clo only pio slum part ccc
[    3.478886] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port 0x100 irq 33
[    3.827349] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    8.827195] ata1.00: qc timeout (cmd 0xec)
[    8.827214] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[    9.177171] ata1: SATA link down (SStatus 0 SControl 300)

2) SATA error manifests with this error on u-boot 5.0.0 (downgrade with apt-get install linux-u-boot-bananapi-next=5.00)

root@bananapi:~# dmesg| grep ata
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] Memory: 1010820K/1046952K available (6822K kernel code, 256K rwdata, 1760K rodata, 328K init, 280K bss, 19748K reserved, 16384K cma-reserved, 244136K highmem)
[    0.000000]       .data : 0xc08bc000 - 0xc08fc1a0   ( 257 kB)
[    3.205237] libata version 3.00 loaded.
[    3.448110] ahci-sunxi 1c18000.sata: PHY power up failed.
[    3.448184] ahci-sunxi: probe of 1c18000.sata failed with error -5

In this situation it means that the 5.0.1 U-boot version doesn't work properly, or I'm doing something wrong?. I tested this starting with ARMBIAN 4.0.5 on SD and consecutively upgrading.

 

Fazit: U-boot 5.0 failed like 5.0.1 until the change of the bananapro dtb file, this made the trick.

 

Another different issue: I realized that the banana led lighting only works with bananapi.dtb and not with bananapro.dtb. It is possible to do the same for bananapro.dtb out of the box? I really like that led is lighting according to CPU/IOs -or whatever-.

 

 

Tests were performed with a 2,5" HDD SEAGATE Momentus ST750LX003 750GB which was recogniced before without issues.

[Igor]

I guess we had some noise in communication. I was doing changes to banana.dtb files in latest release and I request trying using bananapro.dtb which was not touched ... and report was "no change / SATA is not up".

 

"Changing boot.cmd from default to "sun7i-a20-bananapro.dtb" will do the magic"

 

If this helps, we only need to fix / update DTB package ... ? If this is 100% I am updating repository with new package.

 

Edit: I pushed updated kernel (with reverted patch to Banana PRO). It's now kernel defaults ... 

[m_g_s_g]

Changing the /boot/boot.cmd to this:

 

ext4load mmc 0 0x49000000 /boot/dtb/sun7i-a20-bananapro.dtb || fatload mmc 0 0x49000000 /dtb/sun7i-a20-bananapro.dtb

 

 

 

Gave me this result:

 

[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache

[    0.000000] Memory policy: Data cache writealloc

[    0.000000] Memory: 1010820K/1046952K available (6822K kernel code, 256K rwdata, 1760K rodata, 328K init, 280K bss, 19748K reserved, 16384K cma-reserved, 244136K highmem)

      .data : 0xc08bc000 - 0xc08fc1a0   ( 257 kB)

[    3.204701] libata version 3.00 loaded.

[    3.477334] ahci-sunxi 1c18000.sata: controller can't do PMP, turning off CAP_PMP

[    3.477396] ahci-sunxi 1c18000.sata: SSS flag set, parallel bus scan disabled

[    3.477429] ahci-sunxi 1c18000.sata: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl platform mode

[    3.477446] ahci-sunxi 1c18000.sata: flags: ncq sntf stag pm led clo only pio slum part ccc

[    3.478972] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port 0x100 irq 33

[    3.827415] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

[    8.827278] ata1.00: qc timeout (cmd 0xec)

[    8.827296] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)

[    9.177254] ata1: SATA link down (SStatus 0 SControl 300)

[    9.205979] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)

[   10.007168] systemd[1]: Starting Increase datagram queue length...

[   10.159656] systemd[1]: Started Increase datagram queue length.

[   11.340359] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=writeback,commit=600,errors=remount-ro

 

 

 

Still no /dev/sda1. Could this be caused by the 4Tb disk, or by the cubie hdd addon package?

[jobenvil]

I think so, but take care that the SATA errors on dmesg output depending on 5.00 or 5.01 -and same default bananapi.dtb- are not equal.

 

with 5.00:

[    3.448110] ahci-sunxi 1c18000.sata: PHY power up failed.
[    3.448184] ahci-sunxi: probe of 1c18000.sata failed with error -5

with 5.01:

[    3.827349] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    8.827195] ata1.00: qc timeout (cmd 0xec)
[    8.827214] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[    9.177171] ata1: SATA link down (SStatus 0 SControl 300)

[jobenvil]

I guess we had some noise in communication. I was doing changes to banana.dtb files in latest release and I request trying using bananapro.dtb which was not touched ... and report was "no change / SATA is not up".

 

"Changing boot.cmd from default to "sun7i-a20-bananapro.dtb" will do the magic"

 

If this helps, we only need to fix / update DTB package ... ? If this is 100% I am updating repository with new package.

 

Edit: I pushed updated kernel (with reverted patch to Banana PRO). It's now kernel defaults ... 

 

 

Sorry for the delay, but I wanted to be sure. I think we need both, u-boot 5.01 and fix dtb package. With u-boot 5.00 and dtb not linked to bananapro it still doesn't work. I tried this right now and after that always shutdown -h now.

 

Working SATA now with 5.01:

[    3.467792] ahci-sunxi 1c18000.sata: controller can't do PMP, turning off CAP_PMP
[    3.467849] ahci-sunxi 1c18000.sata: SSS flag set, parallel bus scan disabled
[    3.467881] ahci-sunxi 1c18000.sata: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl platform mode
[    3.467897] ahci-sunxi 1c18000.sata: flags: ncq sntf stag pm led clo only pio slum part ccc
[    3.469389] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port 0x100 irq 32
[    3.817752] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    3.818828] ata1.00: ATA-8: ST750LX003-1AC154, SM12, max UDMA/133
[    3.818841] ata1.00: 1465149168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[    3.820802] ata1.00: configured for UDMA/133
[    3.821571] scsi 0:0:0:0: Direct-Access     ATA      ST750LX003-1AC15 SM12 PQ: 0 ANSI: 5

Downgraded:

root@bananapi:~# apt-get install linux-u-boot-bananapi-next=5.00
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be DOWNGRADED:
  linux-u-boot-bananapi-next
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
Need to get 0 B/175 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? Y
dpkg: warning: downgrading linux-u-boot-bananapi-next from 5.01 to 5.00
(Reading database ... 44341 files and directories currently installed.)
Preparing to replace linux-u-boot-bananapi-next 5.01 (using .../linux-u-boot-bananapi-next_5.00_armhf.deb) ...
Unpacking replacement linux-u-boot-bananapi-next ...
Setting up linux-u-boot-bananapi-next (5.00) ...

root@bananapi:~# shutdown -h now

Using username "root".
root@192.168.178.30's password:
 ____
| __ )  __ _ _ __   __ _ _ __   __ _
|  _ \ / _` | '_ \ / _` | '_ \ / _` |
| |_) | (_| | | | | (_| | | | | (_| |
|____/ \__,_|_| |_|\__,_|_| |_|\__,_|


Welcome to ARMBIAN Debian GNU/Linux 7 (wheezy) 4.4.1-sunxi

System load:   0.80             Up time:       40 sec
Memory usage:  3 % of 1003Mb    IP:            192.168.178.30
CPU temp:      35°C
Usage of /:    29% of 3.6G

[ 1 updates to install: apt-get upgrade ]

Last login: Wed Feb 17 18:26:37 2016 from achilles.fritz.box

then

root@bananapi:~# dmesg|grep -i ata
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] Memory: 1010824K/1046952K available (6822K kernel code, 256K rwdata, 1760K rodata, 328K init, 280K bss, 19744K reserved, 16384K cma-reserved, 244136K highmem)
[    0.000000]       .data : 0xc08bc000 - 0xc08fc1a0   ( 257 kB)
[    3.194627] libata version 3.00 loaded.
[    3.437420] ahci-sunxi 1c18000.sata: PHY power up failed.
[    3.437488] ahci-sunxi: probe of 1c18000.sata failed with error -5
[    3.723642] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)
[    7.623411] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=writeback,commit=600,errors=remount-ro

SATA is missing.

root@bananapi:~# cd /boot
root@bananapi:/boot# ls -ltr
total 6592
-rwxr-xr-x 1 root root    6944 Jun 10  2015 boot.bmp
-rwxr-xr-x 1 root root 4826200 Feb 11 21:58 vmlinuz-4.4.1-sunxi
-rw-r--r-- 1 root root 1745862 Feb 11 21:58 System.map-4.4.1-sunxi
drwxr-xr-x 2 root root    4096 Feb 11 21:58 dtb.old
-rw-r--r-- 1 root root  132628 Feb 11 21:58 config-4.4.1-sunxi
-rwxr-xr-x 1 root root    1476 Feb 17 14:27 boot.cmd.backup
drwxr-xr-x 2 root root    4096 Feb 17 14:29 dtb
drwxr-xr-x 2 root root    4096 Feb 17 14:31 bin
lrwxrwxrwx 1 root root      19 Feb 17 14:31 zImage -> vmlinuz-4.4.1-sunxi
-rw-r--r-- 1 root root    1770 Feb 17 15:06 boot.src.bananapi
-rwxr-xr-x 1 root root    1736 Feb 17 18:18 boot.cmd
-rw-r--r-- 1 root root    1808 Feb 17 18:18 boot.scr
lrwxrwxrwx 1 root root      25 Feb 17 18:19 script.bin -> /boot/bin/bananapipro.bin
root@bananapi:/boot# grep -i banana boot.cmd
ext4load mmc 0 0x49000000 /boot/dtb/sun7i-a20-bananapro.dtb || fatload mmc 0 0x49000000 /dtb/sun7i-a20-bananapro.dtb

root@bananapi:/boot# dpkg -l | grep next
ii  linux-dtb-next-sunxi                5.00                              armhf        Linux DTB, version 4.4.1-sunxi
ii  linux-firmware-image-next-sunxi     5.00                              armhf        Linux kernel firmware, version 4.4.1-sunxi
ii  linux-headers-next-sunxi            5.00                              armhf        Linux kernel headers for 4.4.1-sunxi on armhf
ii  linux-image-next-sunxi              5.00                              armhf        Linux kernel, version 4.4.1-sunxi
ii  linux-u-boot-bananapi-next          5.00                              armhf        Uboot loader 2016.01
ii  linux-wheezy-root-next-bananapi     5.00                              armhf        Root file system tweaks for bananapi

 

 

 

 

 

[Igor]

Well, than apt-upgrade should now be fine by default / with default bananapi-dtb . U-boot is fixed and DTB is fixed (all = 5.01). It must work now

[m_g_s_g]

Gave me this result:

 

 

Still no /dev/sda1. Could this be caused by the 4Tb disk, or by the cubie hdd addon package?

 

Well, I installed the latest jessie stable (not vanilla) image (with kernel 3.*), and I can confirm that my externally powered 3.5" 4Tb disk is being recognized and works. So, no, it's not a disk or cubie hdd addon package problem. Tomorrow I will try again with the latest vanilla image and the 5.01 patches.

[jobenvil]

Well, I installed the latest jessie stable (not vanilla) image (with kernel 3.*), and I can confirm that my externally powered 3.5" 4Tb disk is being recognized and works. So, no, it's not a disk or cubie hdd addon package problem. Tomorrow I will try again with the latest vanilla image and the 5.01 patches.

sorry, my earlier answer was for Igor. I don't know why this behaviour. Maybe you can compare the /boot directory for src.bin symlinks to bananapro and dpkg -l to see what you have installed. Can you check if the properly Banana Pro Lemaker appear in dmesg? Only an idea.

[niphor]

Well, than apt-upgrade should now be fine by default / with default bananapi-dtb . U-boot is fixed and DTB is fixed (all = 5.01). It must work now

 

fresh install Armbian 5.0 and apt-get upgrade to 5.0.1

 

still can't find sata !!!

 

root@bananapi:~# dmesg|grep -i ata

[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache

[    0.000000] Memory policy: Data cache writealloc

[    0.000000] Memory: 1004380K/1040476K available (6822K kernel code, 256K rwdata, 1760K rodata, 328K init, 280K bss, 19712K reserved, 16384K cma-reserved, 237660                                                         K highmem)

      .data : 0xc08bc000 - 0xc08fc1a0   ( 257 kB)

[    3.204642] libata version 3.00 loaded.

[    3.537311] ahci-sunxi 1c18000.sata: controller can't do PMP, turning off CAP_PMP

[    3.537375] ahci-sunxi 1c18000.sata: SSS flag set, parallel bus scan disabled

[    3.537409] ahci-sunxi 1c18000.sata: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl platform mode

[    3.537426] ahci-sunxi 1c18000.sata: flags: ncq sntf stag pm led clo only pio slum part ccc

[    3.539003] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port 0x100 irq 32

[    3.887259] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

[    8.887256] ata1.00: qc timeout (cmd 0xec)

[    8.887279] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)

[    9.237234] ata1: SATA link down (SStatus 0 SControl 300)

[    9.253138] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)

[    9.945314] systemd[1]: Starting Increase datagram queue length...

[   10.096686] systemd[1]: Started Increase datagram queue length.

[   11.177529] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=writeback,commit=600,errors=remount-ro

 

 

 

root@bananapi:~# dpkg -l | grep next

ii  linux-dtb-next-sunxi            5.01                             armhf        Linux DTB, version 4.4.1-sunxi

ii  linux-firmware-image-next-sunxi 5.01                             armhf        Linux kernel firmware, version 4.4.1-sunxi

ii  linux-headers-next-sunxi        5.01                             armhf        Linux kernel headers for 4.4.1-sunxi on armhf

ii  linux-image-next-sunxi          5.01                             armhf        Linux kernel, version 4.4.1-sunxi

ii  linux-jessie-root-next-bananapi 5.00                             armhf        Root file system tweaks for bananapi

ii  linux-u-boot-bananapi-next      5.01                             armhf        Uboot loader 2016.01

 

like jobenvil 's solution

i just

cp sun7i-a20-bananapro.dtb sun7i-a20-bananapi.dtb 

and reboot

 

 sata work again!

 

then  i restored my sd card buckup,overwrited the file ,reboot , sata work!

 

i think there still something wrong in current code...

[jobenvil]

I guess we had some noise in communication. I was doing changes to banana.dtb files in latest release and I request trying using bananapro.dtb which was not touched ... and report was "no change / SATA is not up".

 

"Changing boot.cmd from default to "sun7i-a20-bananapro.dtb" will do the magic"

 

If this helps, we only need to fix / update DTB package ... ? If this is 100% I am updating repository with new package.

 

Edit: I pushed updated kernel (with reverted patch to Banana PRO). It's now kernel defaults ... 

 

Where are you changing the banana*.dtb? I want to take a look, because I want to enable the Banana green Leds depending on the CPU use. -Hope is not this managed by scripts after the hardware ist recogniced-

[Gary Blake ヅ]

I've just donated 40 euros. Thanks for the great support guys!

[Igor]

Where are you changing the banana*.dtb? I want to take a look, because I want to enable the Banana green Leds depending on the CPU use. -Hope is not this managed by scripts after the hardware ist recogniced-

I am changing it in kernel sources but dtb files (/boot/dtb/) can be edited on the spot as well. The process is described here, for example: http://www.wiki.xilinx.com/Build+Device+Tree+Blob

 

What and where to change is another topic / problem. Leds if / are defined likes this and you need to alter trigger

green {
			label = "bananapi:green:usr";
			gpios = <&pio 7 24 GPIO_ACTIVE_HIGH>;
			linux,default-trigger = "heartbeat";

      }; 

I am not sure if all are supported, but you can try out:

none (kinda defeats the purpose of setting a trigger)
rfkill0
battery-charging-or-full
battery-charging
battery-full
battery-charging-blink-full-solid
ac-online
usb-online
mmc0
mmc1
timer
heartbeat
cpu0
cpu1
default-on
rfkill1
rfkill2

[jobenvil]

Thanks Igor. I only see that bananapi.dts and bananapro.dts are equal regarding "green" and in both it is not specified the "default trigger":

root@kali:~/compilation/sources/linux-vanilla/v4.4.3/arch/arm/boot/dts# grep -A4 green sun7i-a20-bananapro.dts
        green {
            label = "bananapro:green:usr";
            gpios = <&pio 7 24 GPIO_ACTIVE_HIGH>;
        };
    };

root@kali:~/compilation/sources/linux-vanilla/v4.4.3/arch/arm/boot/dts# grep -A4 green sun7i-a20-bananapi.dts
        green {
            label = "bananapi:green:usr";
            gpios = <&pio 7 24 GPIO_ACTIVE_HIGH>;
        };
    };

however going directly to /boot/dtb and using dtc to convert from dtb to dts I can see only a difference:

root@locky /boot/dtb # grep -A4 green sun7i-a20-bananapro.dts
                green {
                        label = "bananapro:green:usr";
                        gpios = <0x1f 0x7 0x18 0x0>;
                };
        };

root@locky /boot/dtb # grep -A4 green sun7i-a20-bananapi.dts
                green {
                        label = "bananapi:green:usr";
                        gpios = <0x20 0x7 0x18 0x0>;
                };
        };

Strange is that in earlier versions the banana.dtb was doing that leds were blinking. Some clues why? Do you take the dts from Hans de Goede? Where you perform the dts changes? in your git? I'm little bit confused.

[zador.blood.stained]

Both bananapi and bananapro dts files are present in mainline kernel git repository. And one of kernel maintainers explains here that they don't like setting default triggers in DT because you can change them via sysfs interface (however this means that LEDs won't work in ealry boot until init script or systemd unit sets LED settings).

 

You can read more about sysfs interface, for example, here.

[jobenvil]

Both bananapi and bananapro dts files are present in mainline kernel git repository. And one of kernel maintainers explains here that they don't like setting default triggers in DT because you can change them via sysfs interface (however this means that LEDs won't work in ealry boot until init script or systemd unit sets LED settings).

 

You can read more about sysfs interface, for example, here.

Oh!, I see, thanks. Very interesting stuff. I will see how to manage it to get them enabled. Afaik there is no willlnes to enable LEDs by default, only some boards that doesn't have dts under /patch have this included by default, because they are "igors property". I enabled them by default for boot and after that in rc.local, like commented by you and tkaiser.

 

I feel comfortable with these changes:

root@locky ~ # cat /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
###
### Tunning scaling governor to ondemand from fixed minimal frequency value of 864Mhz:
###
echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 864000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy
echo 25 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor

###
### Tunning TCP / IP:
###
sysctl -w net/core/rmem_max=8738000
sysctl -w net/core/wmem_max=6553600
sysctl -w net/ipv4/tcp_rmem="8192 873800 8738000"
sysctl -w net/ipv4/tcp_wmem="4096 655360 6553600"
sysctl -w vm/min_free_kbytes=65536
sysctl -w net.ipv4.tcp_window_scaling=1
sysctl -w net.ipv4.tcp_timestamps=1
sysctl -w net.ipv4.tcp_sack=1
sysctl -w net.ipv4.tcp_no_metrics_save=1

###
###     To enable LEDS **bevor** booting we have to convert the dtb to dts and append leds functionality like as follows:
###     dtc -I dtb -O dts -o sun7i-a20-bananapro.dts sun7i-a20-bananapro.dtb
###     vi sun7i-a20-bananapro.dts
###     append lines 1545 and 1551:
###
#   1537         leds {
#   1538                 compatible = "gpio-leds";
#   1539                 pinctrl-names = "default";
#   1540                 pinctrl-0 = <0x41>;
#   1541
#   1542                 blue {
#   1543                         label = "bananapro:blue:usr";
#   1544                         gpios = <0x1f 0x6 0x2 0x0>;
#   1545                         linux,default-trigger = "heartbeat";
#   1546                 };
#   1547
#   1548                 green {
#   1549                         label = "bananapro:green:usr";
#   1550                         gpios = <0x1f 0x7 0x18 0x0>;
#   1551                         linux,default-trigger = "mmc0";
#   1552                 };
#   1553         };
###
###     convert sun7i-a20-bananapro.dts to sun7i-a20-bananapro.dtb
###     dtc -I dts -O dtb -o sun7i-a20-bananapro.dtb sun7i-a20-bananapro.dts

###
### Onboard LEDs enabled **after** booting filesystem:
###
echo "cpu0" > /sys/class/leds/bananapro\:blue\:usr/trigger
echo "cpu1" > /sys/class/leds/bananapro\:green\:usr/trigger

exit 0

Edited February 27, 2016 by jobenvil

[jobenvil]

@zador.blood.stained I need your help once again. I found this patch for cubietrack in /lib/patch/kernel/sunsi-next:

diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
index 710e2ef..ffe7625 100644
--- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
+++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
@@ -73,7 +73,7 @@
         green {
             label = "cubieboard:green:usr";
             gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>; /* LED2 */
-            linux,default-trigger = "heartbeat";
+            linux,default-trigger = "mmc0";
         };
     };
 };

I want to do the same for Banana Pro. Which is the easy way? Should I fork the torvalds/linux before? Do you have some expample/link how to do it? Thanks in advance

[zador.blood.stained]

diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
index 18fcc87..2f30bfc 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
@@ -68,11 +68,13 @@
 		blue {
 			label = "bananapro:blue:usr";
 			gpios = <&pio 6 2 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
 		};
 
 		green {
 			label = "bananapro:green:usr";
 			gpios = <&pio 7 24 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "mmc0";
 		};
 	};

Save this as your patch file and edit trigger names in quotes (without changing anything else)

[jobenvil]

Thanks!, but which comand you use to get the diff file? You clone the repo after that make the changes and then apply some diff comand? I supposse this file could be uploaded to my fork of /lib/patch/kernel/sunsi-next and then issue a pull request to Igor? I'm newby in this.

[zador.blood.stained]

Yes, if you have a local working copy of kernel repository, you just make necessary adjustments and execute in repository root directory

git diff <path>

specifying path for git diff reduces time needed for finding changed files, especially in huge repositories

for example

git diff arch/arm/boot/dts > leds-for-bananapro.patch

You can fork and make a pull request for Igor's repo, but some triggers (especially heartbeat) are quite annoying with bright SMD LEDs to have them by default.

[tkaiser]

You can fork and make a pull request for Igor's repo, but some triggers (especially heartbeat) are quite annoying with bright SMD LEDs to have them by default.

 

I agree. And I would also think about controlling the LEDs by us to provide user feedback at least the 1st time an image is booted. For the H3 boards we implemented it now this way:

• red led constant on from the moment when u-boot starts as an 'it works' indicator
• when firstrun is active then we let the red led blink through sysfs ('there's something going on!' indicator)
• after the first reboot we do the same with the green led. Let it blink for 30 seconds unless the user logged in at least once, after this it only blinks for 3 seconds to not annoy users that much

I had the hope we get some feedback from Orange Pi users (but it seems most of them just download and forget) and wanted to discuss this behaviour internally if the majority of 'user grade' boards feature at least a green and a red led (we won't need that 'led user feedback' stuff for ie. the Clearfog -- there the users should be able able to read documentation and stay patient for at least 3 minutes)

[jobenvil]

Hi guys, thanks a lot!, this is what I was looking for. I was reading something similar, but I was not sure.

 

These is my first concerning: "the boot indication", because without serial cable it is really difficult to observe if it is booting or not.

 

I saw that it was two patches for enable green leds on some boards and I was asking why not for banana pro. I catch the point. In my case the terrible LED is not disturbing to much because I have placed vertical, near the window.

 

I agree with your approach and it is understable. I will take the patch and put it inside the user patches.

 

Here is the summary:

 

 

• Now, everytime that I compile a new kernel with Igors tool, I should have the LED lights activated by default on banana pro:

root@kali:~/compilation/userpatches/kernel/sunxi-next# ls -ltr
total 4
-rw-r--r-- 1 root root 514 Feb 28 13:39 enable_LEDs_bananapro.patch
root@kali:~/compilation/userpatches/kernel/sunxi-next# cat enable_LEDs_bananapro.patch
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
index 18fcc87..2f30bfc 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
@@ -68,11 +68,13 @@
         blue {
             label = "bananapro:blue:usr";
             gpios = <&pio 6 2 GPIO_ACTIVE_HIGH>;
+            linux,default-trigger = "heartbeat";
         };
 
         green {
             label = "bananapro:green:usr";
             gpios = <&pio 7 24 GPIO_ACTIVE_HIGH>;
+            linux,default-trigger = "mmc0";
         };
     };

("compilation" directory is the clone of igors lib repository)

Edited February 28, 2016 by jobenvil

[technik007_cz]

I upgraded kernel 4.x on my BananaPro today and system did not see SATA drive.

 

This simple fix works for me:

cd /boot/dtb && cp -v sun7i-a20-bananapro.dtb’ -> ‘sun7i-a20-bananapi.dtb

 

I know this is dirty solution but I have no time to solve problems with non working BananaPro images again and again.

And for second I must focus howto sort out same problem with latest image but with 3.4.110 kernel....   :-(

 

EDIT:

For some unknow reason system recognized drive on my second BananaPro board running on 3.4.110 kernel.

[Igor]

http://www.armbian.com/banana-pi-pro/

 

Images rebuild only, update will follow in few days.

 

v5.04 / 1.3.2016

• Banana M1/PRO/M1+ rebuilded
• fixed SATA problem
• set OTG port in HOST mode in vanilla kernel
• wireless is working on PRO out of the box
• added utility to switch between OTG and HOST in vanilla kernel
• Bugs left: OTG mode not working in Vanilla, M1+ wireless not work in vanilla kernel

Tested on all Bananas. Thanks for support!

[Gary Blake ヅ]

Great work as always Igor!