Armbian customization

[chradev]

Thanks Igor,

What if you install only armbian-firmware and remove other firmwares?

I have just do that - armbian-firmware is installed by default and linux-firmware removed.

After removing linux-firmware rt2870.bin disappears.

 

rt2870.bin do not exists in clean Armbian build (with armbian-firmware installed) with both Jessie and Xenial.

 

Long time ago it was there but after some changes (discussed with you) rt2870.bin disappears from armbian-firmware for some reasons.

 

Best regards

Chris

[chradev]

Hi to All,

 

These days I have received front panel and the board with a view buttons and RGB LEDs. For controlling the LEDs I choose to use the Mainline Kernel LED driver so configure them in Device Tree.

To make a difference between system and user DTB staff I have added (with a patch in userpatches/kernel/sunxi-next):

 * include directive in sun7i-a20-olinuxino-lime2-emmc.dts file

#include "sun7i-a20-olinuxino-lime2-emmc-egpr.dts"

 * main user DTB staff in file sun7i-a20-olinuxino-lime2-emmc-egpr.dts:

 

 

/ {
    sys-leds {
	compatible = "gpio-leds";
	pinctrl-names = "default";
	pinctrl-0 = <&egpr_sys_led_pins>;

	red {
	    label = "egpr-sys:red:usr";
	    gpios = <&pio 6 1 GPIO_ACTIVE_HIGH>;
	    default-state = "off";
	};

	green {
	    label = "egpr-sys:green:usr";
	    gpios = <&pio 6 2 GPIO_ACTIVE_HIGH>;
	    linux,default-trigger = "timer";
	    default-state = "off";
	};

	/* More LEDs in Group*/
    };
    /* More LED Groups*/
};

&pio {
    egpr_sys_led_pins: sys_led_pins@0 {
	allwinner,pins = "PG1","PG2","PG3";
	allwinner,function = "gpio_out";
	allwinner,drive = <SUN4I_PINCTRL_20_MA>;
	allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
    };
    /* More LED Pin Groups */
};

 

 

 

The staff is working fine except the 'linux,default-trigger = "timer";' directive. The problem is that the Kernel is set to support LED timer trigger as module making impossible to start triggering early in the boot process.

 

That is why I have to reconfigure Kernel and the best option was to use my own linux-sunxi-next.config file in userpatches directory. For doing the things in a right way I have used following procedure:

 * set in compile.sh file:

KERNEL_ONLY="yes"
KERNEL_CONFIGURE="yes"

 * when get to kernel configuration I have change in drivers -> leds -> triggers 'timer' support from module to built-in and save configuration to my.config;

 * then move my.config to userpatches/linux-sunxi-next.config;

 * restore compile.sh file and rebuild everything.

 

As a result the green LED starts blinking early at the boot process. To make it better I have added to boot.scr:

gpio set 193;

lighting the green LED from U-Boot.

 

Later on I have added in firstrun file:

echo none > /sys/class/leds/egpr-sys\:blue\:usr/trigger
echo none > /sys/class/leds/egpr-sys\:green\:usr/trigger
echo timer > /sys/class/leds/egpr-sys\:red\:usr/trigger

getting the red LED to blink while the firstrun script is working at fist run after updating.

 

For getting better illumination reflecting the system activity I have also added to /etc/rc.local:

/bin/echo default-on > /sys/class/leds/egpr-sys\:green\:usr/trigger
/bin/echo cpu0 > /sys/class/leds/egpr-sys\:red\:usr/trigger
/bin/echo cpu1 > /sys/class/leds/egpr-sys\:blue\:usr/trigger

I have also added to my 'rebootd' daemon:

echo none > /sys/class/leds/egpr-sys\:blue\:usr/trigger
echo none > /sys/class/leds/egpr-sys\:green\:usr/trigger
echo timer > /sys/class/leds/egpr-sys\:red\:usr/trigger

forcing the red LED to blink in case of reboot button is pushed.

 

Later on I am planing to blink the blue system LED while eMMC and/or SSD devices are updated with new firmware like the blue LED from other group when STM32F405 firmware is updated. The prompt progress indication is very important in case of completely none interactive update procedures because the planned embedded system will not have a console or other user control except application web interface and front panel LEDs.

 

Best regards

Chris

 

[chradev]

Hi to All,

 

I am needing a GPIO connected button to run some shell script on Lime2-eMMC under customized by me Armbian with mainline Kernel. The button is connected to PG0 and worked fine till now using daemon script and sysfs. After setting up LED control via the mainline Kernel LED driver I have decided to use its 'gpio-keys' support for the button.

 

I have added in Kernel configuration:

CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_GPIO_POLLED=y

and

/ {
    egpr-keys {
	compatible = "gpio-keys-polled";
	poll-interval = <100>;
	pinctrl-names = "default";
	pinctrl-0 = <&egpr_sys_key_pins>;

	reboot {
	    label = "reboot-key";
	    gpios = <&pio 6 0 GPIO_ACTIVE_LOW>;
	    linux,code = <200>;
	};
    };
};

&pio {
    egpr_sys_key_pins: sys_key_pins@0 {
	allwinner,pins = "PG0";
	allwinner,function = "gpio-in";
	allwinner,drive = <SUN4I_PINCTRL_10_MA>;
	allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
    };
};

to Device Tree and get /dev/input/event0. Here "gpio-keys-polled" is used because PG0 cannot generate interrupt. I have tested it:

root@egpr:~# evtest /dev/input/event0
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100
Input device name: "egpr-keys"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 256 (BTN_0)
Properties:
Testing ... (interrupt to exit)
Event: time 1476670337.034565, type 1 (EV_KEY), code 256 (BTN_0), value 1
Event: time 1476670337.034565, -------------- EV_SYN ------------
Event: time 1476670338.244566, type 1 (EV_KEY), code 256 (BTN_0), value 0
Event: time 1476670338.244566, -------------- EV_SYN ------------

and found it is working. Command 'udevadm info --query=all --name=/dev/input/event0 --attribute-walk' prints:

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/platform/egpr-keys/input/input0/event0':
    KERNEL=="event0"
    SUBSYSTEM=="input"
    DRIVER==""

  looking at parent device '/devices/platform/egpr-keys/input/input0':
    KERNELS=="input0"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{uniq}==""
    ATTRS{properties}=="0"
    ATTRS{min}=="0"
    ATTRS{max}=="100"
    ATTRS{phys}=="gpio-keys-polled/input0"
    ATTRS{poll}=="100"
    ATTRS{name}=="egpr-keys"

  looking at parent device '/devices/platform/egpr-keys':
    KERNELS=="egpr-keys"
    SUBSYSTEMS=="platform"
    DRIVERS=="gpio-keys-polled"
    ATTRS{driver_override}=="(null)"

  looking at parent device '/devices/platform':
    KERNELS=="platform"
    SUBSYSTEMS==""
    DRIVERS==""

I have created '/etc/udev/rules.d/72-egpr-key-event.rules' file with the following content:

ACTION=="add", SUBSYSTEM=="input", KERNEL=="event*", ATTRS{name}=="egpr-keys", RUN+="/root/run.sh"

where /root/run.sh prints "Hello" to /dev/ttyS0. The script is executed only once when GPIO is initialized by the driver.

 

Changing 'linux,code' to 116 for shutting the system down is working as expected without matter what is the content of udev rules file.

 

Can somebody help me to run a shell script when button is pushed using above Kernel and Device Tree setup.

 

Thanks in addvance

Chris

 

[arox]

Do you know "triggerhappy" ?

 

http://manpages.ubuntu.com/manpages/wily/man1/thd.1.html

[chradev]

Thanks Arox,

Do you know "triggerhappy" ?

http://manpages.ubuntu.com/manpages/wily/man1/thd.1.html

I will give it a try but it will be another daemon consuming resources.

My idea is to use already existing one like udev if possible.

 

I am not sure if udev is a solution at all and that is why I made a test with key code 116 (used for system shutdown) and someone (don't know who!) is doing the job as expected.

 

Best regards,

Chris

[arox]

I will give it a try but it will be another daemon consuming resources.

Chris

In fact, you just need a script that open and parse event0. I use to do that in tcl (old skill). The problem you might have is that you are not sure of the number of event device number. This can be retrieve from /proc/bus/input/devices.

[chradev]

Thanks Arox,

In fact, you just need a script that open and parse event0. I use to do that in tcl (old skill). The problem you might have is that you are not sure of the number of event device number. This can be retrieve from /proc/bus/input/devices.

Event number is not a problem because thanks to udev it can be found as symbol link like:

root@egpr:~# ls -la /dev/input/by-path/
total 0
drwxr-xr-x 2 root root  80 Oct 17 07:16 .
drwxr-xr-x 3 root root 100 Oct 17 07:16 ..
lrwxrwxrwx 1 root root   9 Oct 17 07:16 platform-1c2ac00.i2c-platform-axp20x-pek-event -> ../event1
lrwxrwxrwx 1 root root   9 Oct 17 07:16 platform-egpr-keys-event -> ../event0

where /dev/input/by-path/platform-egpr-keys-event in my case is linked to the right /dev/input/event0.

Unfortunately, I did not understand who and when this link was created - suspect of command sequence:

 

 

root@egpr:~# udevadm info -q path -n /dev/input/event0
/devices/platform/egpr-keys/input/input0/event0

root@egpr:~# udevadm test /devices/platform/egpr-keys/input/input0/event0
calling: test
version 215
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

...

GROUP 101 /lib/udev/rules.d/50-udev-default.rules:29
IMPORT builtin 'path_id' /lib/udev/rules.d/60-persistent-input.rules:31
LINK 'input/by-path/platform-egpr-keys-event' /lib/udev/rules.d/60-persistent-input.rules:36
RUN '/root/run.sh' /etc/udev/rules.d/72-system-reboot-button.rules:3
handling device node '/dev/input/event0', devnum=c13:64, mode=0660, uid=0, gid=101
preserve permissions /dev/input/event0, 020660, uid=0, gid=101
preserve already existing symlink '/dev/char/13:64' to '../input/event0'
found 'c13:64' claiming '/run/udev/links/\x2finput\x2fby-path\x2fplatform-egpr-keys-event'
creating link '/dev/input/by-path/platform-egpr-keys-event' to '/dev/input/event0'
preserve already existing symlink '/dev/input/by-path/platform-egpr-keys-event' to '../event0'
ACTION=add
DEVLINKS=/dev/input/by-path/platform-egpr-keys-event
DEVNAME=/dev/input/event0
DEVPATH=/devices/platform/egpr-keys/input/input0/event0
ID_INPUT=1
ID_PATH=platform-egpr-keys
ID_PATH_TAG=platform-egpr-keys
MAJOR=13
MINOR=64
SUBSYSTEM=input
USEC_INITIALIZED=91965
run: '/root/run.sh'
unload module index
Unloaded link configuration context.

 

 

 

About the other staff it is not good idea to "invent the wheel" again.

 

Best regards

Chris

 

[arox]

Well, I thought that udev was supposed to listen to kernel driver events and not input events, but if you can do what you need with udev and this is just to shutdown, it sure would be the better solution.

[chradev]

Thanks Arox,

Well, I thought that udev was supposed to listen to kernel driver events and not input events, but if you can do what you need with udev and this is just to shutdown, it sure would be the better solution.

For sure but I need to make preparation to and reboot which needs my own script to be executed. It is definitely supported by udev but not sure for listening to the input events.

 

I have tried triggerhappy daemon and it seems to work. I have found and install it from the official Debian repository.

 

I have done manually following:

root@egpr:~# thd --dump /dev/input/event0
EV_KEY  BTN_0   1       /dev/input/event0
# BTN_0 1       command
EV_KEY  BTN_0   0       /dev/input/event0
# BTN_0 0       command

for dumping supported events from /dev/input/event0,

root@egpr:~# thd --dump /dev/input/event0 > thd.config

for saving them in config file which was modified as:

# EV_KEY        BTN_0   1       /dev/input/event0
BTN_0   1       /root/run.sh

to react on desired button push event,

root@egpr:~# thd --listevents | grep BTN_0
BTN_0

to be sure that triggerhappy is listening to the prompt key,

thd --triggers thd.config /dev/input/event0

to run triggerhappy manually from the console. After pushing the button the following was printed on the console:

Executing trigger action: /root/run.sh
Hello

which is expected. Next step is to copy working triggers config file to '/etc/triggerhappy/triggers.d/' and to restart triggerhappy daemon.

 

Unfortunately, I did not see expected printout 'Hello' on my console (/dev/ttyS0) as per /root/run.sh:

#!/bin/bash
/bin/echo Hello > /dev/ttyS0

Looking in '/etc/init.d/triggerhappy' the daemon is started with prompt arguments:

DAEMON_ARGS="--daemon --triggers /etc/triggerhappy/triggers.d/ --socket /var/run/thd.socket --pidfile $PIDFILE --user nobody /dev/input/event*"

Did you work with this service and where could be my fault?

 

Best regarsd

Chris

[arox]

"--user nobody"

 

chmod 777 /root/run.sh

[arox]

and

 

chown nobody /dev/ttyS0

[arox]

If I understand well, the driver is polling and not called by interrupt. I suppose (and hope because I will want to make input buttons sometimes in the future) that it react instantly but do not need or already integrate a debounce function. (otherwise you may well engage redundant reboot order).

[chradev]

Thanks Arox,

"--user nobody"

chmod 777 /root/run.sh

Unfortunately, it is not the problem.

 

I have changed the mode (766 was before and should be executed with any rights) and even copy it to /bin directory (modifying the config file and restarting the daemon) without success.

 

Any other ideas?

 

BTW I have just found following error at boot:

[    3.545960] sun7i-a20-pinctrl 1c20800.pinctrl: unsupported function gpio-in on pin PG0
[    3.545972] pinctrl core: failed to register map default (0): invalid type given
[    3.546355] input: egpr-keys as /devices/platform/egpr-keys/input/input0

but the events are definitely generated as tested.

 

Could it be a problem with triggerhappy (and udev probably) when running as daemon?

 

Best regards

Chris

 

[chradev]

Thanks Arox,

and

chown nobody /dev/ttyS0

This is not a problem as well. I have changed /root/run.sh to:

#!/bin/bash

#/bin/echo Hello > /dev/ttyS0
/sbin/reboot

without success.

 

Best regards

Chris

[arox]

You cannot write on ttyS0 as nobody !

 

If you can see BTN_0 events in uinput, it works, and the driver config error is not fatal. But I only use legacy kernel and cannot help you with that. Probably need a map config in params.

[arox]

nobody is not allowed to reboot.

 

Hack the --user nobody and change to --user root (in /etc/default/triggerhappy I suppose). Security administrators are morons - nobody will try break your system to reboot it from China !

[chradev]

Thanks Arox,

If I understand well, the driver is polling and not called by interrupt. I suppose (and hope because I will want to make input buttons sometimes in the future) that it react instantly but do not need or already integrate a debounce function. (otherwise you may well engage redundant reboot order).

I am using polling driver because Allwinner A20 PGxx (and others ports available on Lime2 GPIO-1 connector) did not support external interrupts.

Only part of PHxx and PIxx GPIOs are EINTxx and able to generate interrupts.

 

About denounce function - it is already integrated in the gpio-keys-polling driver and denounce time could be set in device tree configuration so there is no problem with generation many events.

 

In my opinion using gpio-key is better because it is based on interrupts but I have to add in my case one more 40 pin cable and connector to use a single EINT gpio from GPIO-2/3 Lime2 connectors.

 

Best regards

Chris

[chradev]

Thanks Arox.

nobody is not allowed to reboot.

Hack the --user nobody and change to --user root (in /etc/default/triggerhappy I suppose). Security administrators are morons - nobody will try break your system to reboot it from China !

That helps!!!

 

Is it possible to have the same problem with udev?

 

Best regards

Chris

[arox]

"Is it possible to have the same problem with udev?"

 

I don't know and don't want to know - udev is a system configuration subsystem : a user shouldn't have to fiddle with multiple cryptic configuration files to configure his applications. If it doesn't work out of the box, it is bugs !

[chradev]

Hi to All,

 

Thanks to Arox' assistance I have managed to get to my preferred reboot button control.

 

Button is controlled by 'gpio-keys-polled' mainline Kernel driver as described here.

Trigger Happy daemon is used to listen and execute an user script as described here.

 

Finally, after installation of triggerhappy from the official Debian repository following files ware added:

 * /etc/triggerhappy/triggers.d/reboot.conf

# EV_KEY        BTN_0   1       /dev/input/event0
BTN_0   1       /bin/reboot.sh

 * /bin/reboot.sh with mode 766

#!/bin/bash

/bin/echo none > /sys/class/leds/egpr-sys\:green\:usr/trigger
/bin/echo timer > /sys/class/leds/egpr-sys\:red\:usr/trigger
/bin/echo none > /sys/class/leds/egpr-sys\:blue\:usr/trigger

/sbin/reboot

and /etc/init.d/triggerhappy script is modified as follows:

sed -i 's/--user nobody/--user root/g' /etc/init.d/triggerhappy

to allow running privileged command.

 

The effect of pushing the PG0 button is: the red system LED on PG0 starts blinking and system is restarted what is the main goal as a beginning.

 

Additionally, file '/etc/udev/rules.d/72-system-reboot-button.rules' can be created for adding link to the right /dev/input/eventX device:

# Handle user button with systemd
ACTION=="remove", GOTO="power_switch_end"
SUBSYSTEM=="input", KERNEL=="event*", ATTRS{name}=="egpr-keys", SYMLINK+="rebooter"
LABEL="power_switch_end"

After reboot ther will be the following:

root@egpr:~# ls -la /dev/rebooter
lrwxrwxrwx 1 root root 12 Oct 17 17:24 /dev/rebooter -> input/event0

which can be used if needed.

 

Best regards

Chris

 

[chradev]

Thanks Arox,

"Is it possible to have the same problem with udev?"

I don't know and don't want to know - udev is a system configuration subsystem : a user shouldn't have to fiddle with multiple cryptic configuration files to configure his applications. If it doesn't work out of the box, it is bugs !

You are definitely right so I will stop looking in that direction anymore.

 

Thanks again for all your assistance and the time spent.

 

With hope all above to help you as well

Chris

[chradev]

Hi Tomas,

 

Today I have noticed change around verbosity control and find that with commit Re-enable crash detection, adopt armbianEnv.txt (by Tomas Kaiser) was removed deletion of '/boot/.verbose' file and verbosity control has been moved to U-Boot environment. Unfortunately, I am using old scheme relying on above file, environment coming from U-Boot build and written by me boot script.

 

Is it possible to stay compatible with old verbosity control mechanism?

 

What can I do in case of breaking backward compatibility?

 

Best regards

Chris

[chradev]

Hi to All,

 

Because the problem described above I have fixed my current build at USBIP support for sun8i default commit (21a5f49) by igorpecovnik on Oct 18, 2016.

 

These days after new prototypes mounting and testing I have noticed a problem with 'poweroff' command which is resetting the board instead of powering it off.

The same problem I have with Lime2 Power On/Off button (connected via PMU) because it finally run 'poweroff' command.

 

The main differences with previous prototypes is that the front panel staff (LEDs, buttons and connectors) are:

• placed on a board and the GPIOs used was reordered to fit new board schematics;
• LEDs control is migrated to mainline Kernel driver gpio-leds as described here;
• Button control is migrated to mainline Kernel driver gpio-keys-polled as described here.

They have no relations with the problem and works fine.

 

Can somebody help me to find and solve the problem?

 

Some help around fixing the 'verbosity' problem described above will also be very kind.

 

Best ragards

Chris

 

 

[zador.blood.stained]

Some help around fixing the 'verbosity' problem described above will also be very kind.

Please describe what is your problem here. armhwinfo was extended for backwards compatibility, so it should create and remove /boot/.verbose file when necessary.

 

These days after new prototypes mounting and testing I have noticed a problem with 'poweroff' command which is resetting the board instead of powering it off.

The same problem I have with Lime2 Power On/Off button (connected via PMU) because it finally run 'poweroff' command.

Are you sure this is not a kernel problem where it crashes on shutdown (which will force automatic reboot)? Please increase verbosity level and look at serial console messages during shutdown, and check what are the last messages before loading u-boot.

[chradev]

Thanks Zador,

Please describe what is your problem here. armhwinfo was extended for backwards compatibility, so it should create and remove /boot/.verbose file when necessary.

 

Are you sure this is not a kernel problem where it crashes on shutdown (which will force automatic reboot)? Please increase verbosity level and look at serial console messages during shutdown, and check what are the last messages before loading u-boot.

Implemented backwards compatibility solves the problem with verbosity. Sorry for the question.

Unfortunately, I have no time to look and understand all commits done.

 

About rebooting instead of powering off this is the log with extended verbosity:

 

 

Linux egpr 4.8.4-sunxi #1 SMP Mon Oct 24 15:15:23 EEST 2016 armv7l
 _     _                  ____         __  __ __  __  ____
| |   (_)_ __ ___   ___  |___ \    ___|  \/  |  \/  |/ ___|
| |   | | '_ ` _ \ / _ \   __) |  / _ \ |\/| | |\/| | |
| |___| | | | | | |  __/  / __/  |  __/ |  | | |  | | |___
|_____|_|_| |_| |_|\___| |_____|  \___|_|  |_|_|  |_|\____|


Welcome to ARMBIAN Debian GNU/Linux 8 (jessie) 4.8.4-sunxi
System load:   0.74             Up time:       50 sec
Memory usage:  7 % of 999Mb     IP:            192.168.1.173,192.168.2.1
CPU temp:      32°C             HDD temp:      27°C
Usage of /:    10% of 12G       storage/:      4% of 99G

New to Armbian? Check the documentation first: docs.armbian.com

root@egpr:~# poweroff
[  OK  ] Removed slice system-ifup.slice.
[  OK  ] Removed slice system-systemd\x2dfsck.slice.
         Stopping User Manager for UID 0...
         Stopping Authenticate and Authorize Users to Run Privileged Tasks...
[  OK  ] Stopped target Host and Network Name Lookups.
[  OK  ] Stopped target Graphical Interface.
         Stopping Entropy daemon using the HAVEGE algorithm...
[  OK  ] Stopped target Multi-User System.
         Stopping dnsmasq - A lightweight DHCP and caching DNS server...
         Stopping The PHP FastCGI Process Manager...
         Stopping OpenBSD Secure Shell server...
         Stopping A high performance web server and a reverse proxy server...
         Stopping Network Manager...
         Stopping Regular background program processing daemon...
[   68.021659] IPv6: ADDRCONF(NETDEV_UP): bond0: link is not ready
[  OK  ] Stopped target Login Prompts.
         Stopping Getty on tty1...
         Stopping Serial Getty on ttyS0...
         Stopping LSB: triggerhappy hotkey daemon...
         Stopping LSB: Start NTP daemon...
         Stopping LSB: disk temperature monitoring daemon...
         Stopping LSB: Armbian gathering hardware information...
         Stopping LSB: RPi-Monitor daemon...
         Stopping LSB: Advanced IEEE 802.11 management daemon...
         Stopping LSB: Starts LIRC daemon....
         Stopping LSB: Set sysfs variables from /etc/sysfs.conf...
         Stopping LSB: Start/stop sysstat's sadc...
         Stopping D-Bus System Message Bus...
         Stopping System Logging Service...
         Starting Store Sound Card State...
[   68.560159] device wlan0 left promiscuous mode
[   68.564839] br0: port 1(wlan0) entered disabled state
         Starting Unattended Upgrades...
[  OK  ] Stopped Entropy daemon using the HAVEGE algorithm.
[  OK  ] Stopped OpenBSD Secure Shell server.
[  OK  ] Stopped Network Manager.
[  OK  ] Stopped Regular background program processing daemon.
[  OK  ] Stopped D-Bus System Message Bus.
[  OK  ] Stopped System Logging Service.
[  OK  ] Stopped The PHP FastCGI Process Manager.
[  OK  ] Stopped Authenticate and Authorize Users to Run Privileged Tasks.
[  OK  ] Stopped Getty on tty1.
[  OK  ] Stopped Serial Getty on ttyS0.
[  OK  ] Stopped User Manager for UID 0.
[  OK  ] Stopped A high performance web server and a reverse proxy server.
[  OK  ] Stopped dnsmasq - A lightweight DHCP and caching DNS server.
[  OK  ] Stopped LSB: triggerhappy hotkey daemon.
[  OK  ] Stopped LSB: Start NTP daemon.
[  OK  ] Stopped LSB: disk temperature monitoring daemon.
[  OK  ] Stopped LSB: Armbian gathering hardware information.
[  OK  ] Stopped LSB: RPi-Monitor daemon.
[  OK  ] Stopped LSB: Advanced IEEE 802.11 management daemon.
[  OK  ] Stopped LSB: Starts LIRC daemon..
[  OK  ] Stopped LSB: Set sysfs variables from /etc/sysfs.conf.
[  OK  ] Stopped LSB: Start/stop sysstat's sadc.
[FAILED] Failed to start Store Sound Card State.
See 'systemctl status alsa-store.service' for details.
[  OK  ] Started Unattended Upgrades.
         Stopping LSB: set CPUFreq kernel parameters...
[  OK  ] Stopped target Network is Online.
         Stopping Login Service...
[  OK  ] Removed slice user-0.slice.
[  OK  ] Removed slice system-serial\x2dgetty.slice.
[  OK  ] Removed slice system-getty.slice.
         Stopping /etc/rc.local Compatibility...
         Stopping Permit User Sessions...
[  OK  ] Stopped Login Service.
[  OK  ] Stopped /etc/rc.local Compatibility.
[  OK  ] Stopped LSB: set CPUFreq kernel parameters.
[  OK  ] Stopped Permit User Sessions.
         Stopping LSB: Load kernel modules needed to enable cpufreq scaling...
[  OK  ] Stopped target Network.
[  OK  ] Stopped LSB: Load kernel modules needed to enable cpufreq scaling.
[  OK  ] Stopped target Basic System.
[  OK  ] Stopped target Slices.
[  OK  ] Removed slice User and Session Slice.
[  OK  ] Stopped target Paths.
[  OK  ] Stopped target Timers.
[  OK  ] Stopped target Sockets.
[  OK  ] Closed UUID daemon activation socket.
[  OK  ] Closed D-Bus System Message Bus Socket.
[  OK  ] Closed Syslog Socket.
[  OK  ] Stopped target System Initialization.
         Stopping Load/Save RF Kill Switch Status of rfkill0...
         Stopping Restore / save the current clock...
         Stopping Apply Kernel Variables...
[  OK  ] Stopped Apply Kernel Variables.
[  OK  ] Stopped target Encrypted Volumes.
         Stopping Update UTMP about System Boot/Shutdown...
         Stopping Load Kernel Modules...
[  OK  ] Stopped Load Kernel Modules.
         Stopping LSB: Raise network interfaces....
[  OK  ] Stopped target Swap.
[  OK  ] Stopped target Remote File Systems.
[  OK  ] Stopped target Remote File Systems (Pre).
[  OK  ] Stopped Load/Save RF Kill Switch Status of rfkill0.
[  OK  ] Stopped Restore / save the current clock.
[  OK  ] Stopped Update UTMP about System Boot/Shutdown.
         Stopping Create Volatile Files and Directories...
[  OK  ] Stopped Create Volatile Files and Directories.
[  OK  ] Removed slice system-systemd\x2drfkill.slice.
[  OK  ] Stopped LSB: Raise network interfaces..
         Stopping Load/Save Random Seed...
[  OK  ] Stopped target Local File Systems.
         Unmounting /run/user/0...
         Unmounting /sys/kernel/debug/tracing...
[  OK  ] Unset automount app-home.automount.
         Unmounting /media/sda2...
         Unmounting /tmp...
[  OK  ] Stopped Load/Save Random Seed.
[  OK  ] Unmounted /run/user/0.
[  OK  ] Unmounted /sys/kernel/debug/tracing.
[  OK  ] Unmounted /media/sda2.
[  OK  ] Unmounted /tmp.
[  OK  ] Reached target Unmount All Filesystems.
[  OK  ] Stopped target Local File Systems (Pre).
         Stopping Create Static Device Nodes in /dev...
[  OK  ] Stopped Create Static Device Nodes in /dev.
         Stopping Remount Root and Kernel File Systems...
[  OK  ] Stopped Remount Root and Kernel File Systems.
[  OK  ] Reached target Shutdown.
[   75.135670] systemd-shutdow: 65 output lines suppressed due to ratelimiting
[   75.154441] systemd-shutdown[1]: Sending SIGTERM to remaining processes...
[   75.205615] systemd-journald[180]: Received SIGTERM from PID 1 (systemd-shutdow).
[   75.226925] systemd-shutdown[1]: Sending SIGKILL to remaining processes...
[   75.273947] systemd-shutdown[1]: Unmounting file systems.
[   75.281037] systemd-shutdown[1]: Unmounting /sys/kernel/config.
[   75.310103] systemd-shutdown[1]: Unmounting /sys/fs/fuse/connections.
[   75.349858] systemd-shutdown[1]: Unmounting /sys/kernel/debug.
[   75.389798] systemd-shutdown[1]: Unmounting /dev/mqueue.
[   75.483326] EXT4-fs (sda1): re-mounted. Opts: (null)
[   75.516714] EXT4-fs (sda1): re-mounted. Opts: (null)
[   75.522589] EXT4-fs (sda1): re-mounted. Opts: (null)
[   75.527660] systemd-shutdown[1]: All filesystems unmounted.
[   75.533407] systemd-shutdown[1]: Deactivating swaps.
[   75.538981] systemd-shutdown[1]: All swaps deactivated.
[   75.555467] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[   75.561842] sd 0:0:0:0: [sda] Stopping disk
[   75.769668] reboot: Power down
â–’
U-Boot SPL 2016.09-armbian (Oct 19 2016 - 16:50:37)
DRAM: 1024 MiB
CPU: 912000000Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC2

 

 

 

The only fail:

[FAILED] Failed to start Store Sound Card State.

is not a problem because it exists for months.

 

No other crashes especially the Kernel once.

 

Unfortunately, I cannot say when this begins because relatively long time passed from my previous builds.

 

Best regards

Chris

 

[chradev]

Hi to All,

 

The problem with rebooting instead of powering off looks more strange after last my findings.

 

If brake off the console connection the board is powering off as before.

EDIT: Disconnecting console RxD only is enough the problem to disappear.

 

Main difference with the situation before the rise of this problem is that console and power button are connected via additional interconnection board. For wiring the console is used GPIO-1 connector. Additional wires are used for second power button wired in parallel to the Lime2 PWR one and mounted on the interconnection board for accessing it from the front panel.

 

Any ideas where the problem is coming from?

 

Best regards

Chris

[chradev]

Hi to All,

 

I have succeeded to get rootfs in read only mode but using unionfs-fuse instead of overlayfs & overlayroot.

The idea is offered and reported here. It is also applied for RPi.

 

Of course some change has to be applied because of using Kernel command line for rootfs options instead of /etc/fstab.

 

Best regards

Chris

[zador.blood.stained]

Hi to All,

 

The problem with rebooting instead of powering off looks more strange after last my findings.

 

If brake off the console connection the board is powering off as before.

EDIT: Disconnecting console RxD only is enough the problem to disappear.

 

Main difference with the situation before the rise of this problem is that console and power button are connected via additional interconnection board. For wiring the console is used GPIO-1 connector. Additional wires are used for second power button wired in parallel to the Lime2 PWR one and mounted on the interconnection board for accessing it from the front panel.

 

Any ideas where the problem is coming from?

Most USB-UART adapters will provide enough current (via pull-up resistors) that it may prevent SoC from powering off completely.

[chradev]

Thanks Zador,

Most USB-UART adapters will provide enough current (via pull-up resistors) that it may prevent SoC from powering off completely.

It can be but it cannot explain that when USB to serial adapter is connected to Lime2 console connector no such problem.

I will try to find some test case based on your supposition.

 

Best regards

Chris

[zador.blood.stained]

It can be but it cannot explain that when USB to serial adapter is connected to Lime2 console connector no such problem.

I will try to find some test case based on your supposition.

I know that similar thing happens on Cubietruck with PL2303 based adapters: power LED doesn't turn off but still lights at half brightness and SD card may fail to be detected after powering off, but I don't remember experiencing your issue and we still don't have Lime2 boards for experiments.