The Seagate BlackArmor NAS220 is a consumer NAS
with two internal drive bays. The stock OS runs
RAID 1 over the disks via mdadm.
Device specification:
- SoC: Marvell 88F6192 800 MHz
- RAM: 128 MB
- Flash: 32 MB
- 2 x internal SATA II drives
- Ethernet: 10/100/1000 Mbps (single port, no switch)
- WLAN: None
- LED: Power, Status, Sata Activity
- Key: Power, Reset
- Serial: 10 pin header, (115200,8,N,1), 3.3V TTL
9|x - x|10
7|x - x|8
5|x - GND|6
3|x - RX|4
1|TX - x|2
front of case
- USB ports: 2 x USB 2.0
Flash instruction:
NOTE: this process uses a serial connection. It will upgrade the
bootloader and reset the bootloader environment variables
TFTP server setup
- Setup PC with TFTP server set the PC IP to 10.4.50.5 as TFTP server
- Copy these files to TFTP server location
- u-boot.kwb
- seagate_blackarmor-nas220-initramfs-uImage
- seagate_blackarmor-nas220-squashfs-sysupgrade.bin
- seagate_blackarmor-nas220-squashfs-factory.bin
Seagate NAS setup
- Connect LAN cable between PC and seagate device
- Connect to serial to seagate device
Install u-boot
- Boot seagate device and stop in bootloader by pressing any key
- run 'printenv' from u-boot and save the values
- tftpboot 0x2000000 u-boot.kwb
- nand erase.part uboot
- nand write 0x2000000 0x0 ${filesize}
- reset
Update MAC address in u-boot env
- Stop in u-boot by pressing any key
- Get your MAC address from your saved printenv. Is also on chassis
- setenv ethaddr <your MAC>
- saveenv
Option 1 (recommended) - Install OpenWrt via initramfs and sysupgrade
- tftpboot 0x2000000 seagate_blackarmor-nas220-initramfs-uImage
- bootm 0x2000000
- *OpenWrt should be running now, however it is not written to flash yet*
- From the running instance of OpenWrt use Luci's "flash image" feature
from the web site or use sysupgrade from the console to write
seagate_blackarmor-nas220-squashfs-sysupgrade.bin to flash
Option 2 - Install OpenWrt by flashing factory image from u-boot
- nand erase.part ubi
- tftpboot 0x2000000 seagate_blackarmor-nas220-squashfs-factory.bin
- nand write 0x2000000 ubi ${filesize}
- reset
Signed-off-by: Kip Porterfield <kip.porterfield@gmail.com>
The uci-default mechanism to update the compat-version was only
meant for early DSA-adopters, which should have updated by now.
Remove this workaround again in order to prevent the intended
experiences for all the other people.
This reverts:
a9703db720 ("mvebu: fix sysupgrade experience for early DSA-adopters")
86c89bf5e8 ("kirkwood: fix sysupgrade experience for early DSA-adopters")
Partially reverted:
1eac573b53 ("ramips: mt7621: implement compatibility version for DSA migration")
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Conceptually, the compat-version during sysupgrade is meant to
describe the config. Therefore, if somebody starts with a device on
19.07 and swconfig, and that person does a forceful upgrade into a
DSA-based firmware without wiping his/her config, then the local
compat-version should stay at 1.0 according to the config present
(and not get updated).
However, this poses a problem for those people that early-adopted
DSA in master, as they already have adjusted their config for DSA,
but it still is "1.0" as far as sysupgrade is concerned. This can
be healed by a simple
uci set system.@system[0].compat_version="1.1"
uci commit system
But this needs to be applied _after_ the upgrade (as the "old" fwtool
on the old installation does not know about compat_version) and it
requires access via SSH (i.e. no pure GUI solution is available for
this group of people, apart from wiping their config _again_ for
no technical reason). Despite, the situation will not become
obvious to those just upgrading via GUI, they will just have the
experience of a "broken upgrade".
This is a conflict which cannot be resolved by achieving both goals,
we have to decide to either keep the strict concept or improve the
situation for early adopters.
In this patch, we address the issue by providing a uci-defaults
script that will raise the compat_version for _all_ people upgrading
into a 1.1 image, no matter whether they have reset config or not.
The idea is to implement this as a _temporary_ solution, so early
adopters can upgrade into the new mechanism without issues, and
after a few weeks/months we could remove the uci-defaults script
again.
If we e.g. remove the script just before 20.xx.0-rc1, early adopters
should have moved on by then, and existing stable users would still
get the intended experience.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This replaces the internal device names "Audi" and "Viper" with the
real model names, which a user would look for. This makes the
Linksys devices on this target consistent with the names recently
changed for mvebu based on the same idea.
As a consequence, the "viper" device definition is split into two
separate definitions with the correct names for both real models.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This implements the newly introduced compat-version to prevent
upgrade between swconfig and DSA for kirkwood.
Just define a compat version with minor increment and an appropriate
message for both image (in Makefile) and device (in base-files).
Since we never removed SUPPORTED_DEVICES for this target, we don't
have to add it back either.
Attention:
All users that already updated to the DSA versions in master will
receive the same incompatibility warning since their devices are still
"1.0" as far as fwtool can tell.
Those, and only those, can bypass the upgrade check by using force (-F)
without having to reset config again. In addition, the new version
string needs to be put into uci config manually, so the new fwtool
knows that it actually deals with a "1.1":
uci set "system.@system[-1].compat_version=1.1"
uci commit system
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Zyxel NSA310S is a NAS based on Marvell kirkwood SoC.
Specification:
- Processor Marvell 88F6702 1 GHz
- 256MB RAM
- 128MB NAND
- 1x GBE LAN port (PHY: Marvell 88E1318)
- 2x USB 2.0
- 1x SATA
- 3x button
- 7x leds
- serial on J1 connector (115200 8N1) (GND-NOPIN-RX-TX-VCC)
Known issues:
- no kernel module for RTC. [*]
- buzzer (connected to MPP43) need to be drived by 1kHz signal
- no kernel module for internal MCU connected via I2C[**]
[*]
Karoly Pocsi made simple, unofficial driver for HT1382.
It can be found here:
https://www.madadmin.com/zyxel-nsa320s-es-debian-linux-4-resz/
[**]
Karoly Pocsi found how CPU talk with MCU:
It is possible to query the MCU-controlled fan speed and temperature:
i2cget -y 0x0 0x0a 0x07
i2cget -y 0x0 0x0a 0x08
The first value (0x07) is the temperature in ° C, the second (0x08) is
the time in milliseconds to complete one fan revolution (rpm = 60,000 / value).
Info translated from:
https://www.madadmin.com/zyxel-nsa320s-es-debian-linux-4-resz/
Installation:
TFTP:
1. Run serial console and go to u-boot.
2. Copy u-boot via tftp and write to NAND:
=> mw 0x0800000 0xffff 0x100000
=> nand erase 0x0 100000
=> setenv ipaddr 192.168.1.2
=> setenv serverip 192.168.1.4
=> tftp 0x0800000 nsa310s-u-boot.kwb
=> nand write 0x0800000 0x0 0x100000
=> reset
3. Run new u-Boot, repair bootcmd and restore MAC address from sticker
=> setenv ethaddr AA:BB:CC:DD:EE:FF
=> saveenv
4. Copy and run initramfs image
=> setenv ipaddr 192.168.1.2
=> setenv serverip 192.168.1.4
=> tftpboot zyxel_nsa310s-initramfs-uImage
=> bootm 0x800000
5. Download sysupgrade image and perform sysupgrade
USB:
1. Prepare usb fat32 drive with u-boot.kwb and initramfs image.
Stick it to USB 2.0 port.
2. Run serial console and go to u-boot.
3. Copy u-boot from usb and write to NAND:
=> mw 0x0800000 0xffff 0x100000
=> nand erase 0x0 100000
=> usb start
=> fatload usb 0 0x0800000 u-boot.kwb
=> nand write 0x0800000 0x0 0x100000
=> reset
4. Run new u-Boot, repair bootcmd and restore MAC address from sticker
=> setenv ethaddr AA:BB:CC:DD:EE:FF
=> saveenv
5. Copy and run initramfs image:
=> usb start
=> fatload usb 0 0x0800000 initramfs-uImage
=> bootm 0x800000
6. Download sysupgrade image and perform sysupgrade.
Based on work ThBexx <thomas.beckler@hotmail.com>
DTS based on dropped support in 0ebdf0c.
Tested-by: Lech Perczak <lech.perczak@gmail.com>
Reviewed-by: Lech Perczak <lech.perczak@gmail.com>
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
[NSA310s -> NSA310S in DEVICE_MODEL]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
This patch moves led trigger settings from 01_leds file to dts.
Now "linux,default-trigger" property is used.
Tested-by: Alberto Bursi <bobafetthotmail@gmail.com> [nsa310,nsa325]
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
This patch removes support for swconfig and switches to dsa driver.
swconfig and switch drivers are removed. DSA driver is enabled and
configuration is adjusted.
In kirkwood only two devices have switches: Linksys EA3500 and EA4500.
WAN MAC configuration in 02_network is required because otherwise WAN
would have the same MAC address as lan interfaces. In swconfig solution
the WAN address was assigned in u-Boot to eth1. Now, as eth1 is disabled
and wan is part of the switch, we have to set it manually.
Compile tested: EA3500, EA4500
Run tested: EA4500
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
[minor commit title/message adjustments, remove swconfig package
for devices]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Add indent and sort board_name alphabetically.
Sourcing /lib/functions.sh is already handled by /etc/rc.common. Drop the line.
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
So far, the state of status LEDs is set up in 01_leds for many devices
in kirkwood target. As those LEDs are also controlled by diag.sh,
exposing them to the user via uci config by default seems not helpful
and might even have confusing results for the user.
Thus, remove the ucidef_set_led_default setup for power/status LED, but
do not touch the rest where user control is actually a feature.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This commit removes the target-specific diag.sh script. This way, the
generic one is used for the target, which uses DT-aliases to specify the
LEDs used.
Generic diag.sh allow to use different LEDs to indicate different states.
Non-red status LEDs for indicating boot and a running system.
Where possible, the red or orange LEDs are used to indicate failsafe
mode and a running upgrade.
Compile-tested: all target devices.
Run-tested: CheckPoint L-50
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
[remove unrelated cosmetic changes, rename some labels, add pogo_e02]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Change the LED labels for hdd1/hdd2 in 01_leds to match their
counterpart in DTS.
Signed-off-by: Stephan Knauss <openwrt@stephans-server.de>
[improve commit title and message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This commit made the following changes to sync all bootcount scripts:
1. use boot() instead of start()
This script only needs to be executed once when boot is complete.
use boot() to make this explicit.
2. drop sourcing of /lib/functions.sh
This is aready done in /etc/rc.common.
3. ramips: replace board name checking with a case
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
Consistently handle boot-count reset and upgrade across
ipq40xx, ipq806x, kirkwood, mvebu
Dual-firmware devices often utilize a specific MTD partition
to record the number of times the boot loader has initiated boot.
Most of these devices are NAND, typically with a 2k erase size.
When this code was ported to the ipq40xx platform, the device in hand
used NOR for this partition, with a 16-byte "record" size. As the
implementation of `mtd resetbc` is by-platform, the hard-coded nature
of this change prevented proper operation of a NAND-based device.
* Unified the "NOR" variant with the rest of the Linksys variants
* Added logging to indicate success and failure
* Provided a meaningful return value for scripting
* "Protected" the use of `mtd resetbc` in start-up scripts so that
failure does not end the boot sequence
* Moved Linksys-specific actions into common `/etc/init.d/bootcount`
For upgrade, these devices need to determine which partition to flash,
as well as set certain U-Boot envirnment variables to change the next
boot to the newly flashed version.
* Moved upgrade-related environment changes out of bootcount
* Combined multiple flashes of environment into single one
* Current-partition detection now handles absence of `boot_part`
Runtime-tested: Linksys EA8300
Signed-off-by: Jeff Kletsky <git-commits@allycomm.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
[checkpatch.pl fixes, traded split strings for 80+ chars per line]
also known as
POGO-V4-A3-02
or
POGO-V4-A3-01
SoC: Marvell 88F6192 800Mhz
SDRAM memory: 128MB
Gigabit ethernet: 1 Marvell 88E1310
Flash memory: 128MB
2 status LEDs (one green one red)
1 "Eject" button on the back (used as "Reset" button)
1 USB 2.0 port (on upper side)
1 sata slot (power + data) for 2.5'' drives (upper side)
2 USB 3.0 ports from a controller on PCIe x1 of the SoC
1 full-size SDcard slot (fits a whole SD card into it)
This device supports the (linux-only) kwboot tool to send
a new uboot over serial console, so it is easy to unbrick
in case the uboot is erased and the device won't boot.
-----
Install instructions:
-----
Since it's not possible to get ssh access to these
devices, the only way to take control is to
solder pins to get TTL serial access.
Case can be opened by removing screws beneath two rubber
feet at back of device, then lifting while prying the
sides of the upper part out to unhook a latch on each
side about 2/3rds of the way toward the front.
Serial connection pins are those labeled "J11", left
of SD as you face SD opening.
Pins are (from left to right, i.e. the first in the list
is the nearest to the SD slot) GND, Rx, Tx.
Do not connect +V pin if you use a USB (self-powered)
TTL-to-USB dongle. Any USB TTL-to-USB converter will work.
Baud rate is 115200, parity "none", databits "8",
flow control "none".
Stock uboot is unable to read ubi partitions (nor usb)
so we will replace it first with our uboot.
Start a TFTP server at IP address 169.254.254.254, and
place the uboot.kwb file in the folder of the server.
Start the serial session and then power up the device.
As soon as you see text on the serial start pressing random
letter keys to stop the boot process.
If you see something like the following line you can proceed:
CE>>
Otherwise if text is still scrolling by you missed the
opportunity, pull the plug and try again.
write
printenv ethaddr
The uboot will write something like this:
ethaddr=00:50:43:00:02:02
This is the device's MAC address, also present in the sticker
under the device.
Write this down as we will need to add it in the
new uboot configuration.
Use the following commands to load the new uboot:
tftp 0x20000 u-boot.kwb
If the uboot confirms that the transfer was successful,
then you can write it to flash with the following commands:
nand erase 0 0x200000
nand write 0x20000 0 0x1c0000
if after the last command the uboot wrote
"xxxx bytes written: OK"
then it was written correctly and we can proceed.
If it did not go well, try again or ask assistence in forums.
Shutting down or rebooting at this time will brick
the device, to unbrick it you will need to use the kwboot
tool from a Linux PC or Virtual Machine.
Now write:
reset
and press enter, the device will reboot and you should see
again text scrolling by.
Press a random key to stop it, and now you should see
pogoplugv4>
We now add the MAC address back, write:
setenv ethaddr '00:50:43:00:02:02'
Confirm that the uboot has understood by writing
printenv ethaddr
If all looks ok, save the setting with
saveenv
At this point the uboot is configured, and we only need to load
the firmware in the flash memory.
Follow the steps below in "Firmware recovery procedure".
----
Firmware recovery procedure
----
The new uboot allows easy recovery from a bad firmware upgrade
where you can't access the device anymore over ssh or luci.
Take a USB flash drive formatted as FAT32, and copy the
initramfs image file in it (it will have "initramfs" in the
file name), then rename it as "initramfs.bin".
Insert the USB drive in the USB 2.0 port of the pogoplug
(the port at the top).
Power up the device, and wait for it to finish booting.
The uboot should find and load the "initramfs.bin"
from usb and if you are connected with serial you should
see the linux kernel boot log (text scrolling by).
Once it is done, press Enter and you will be greeted by
the OpenWRT banner.
If you were not connected with serial just wait a bit and,
you will be able to access it with ssh or luci web interface
(once you find its IP).
The recovery "initramfs" images are run from RAM, so you will
have to do a normal sysupgrade (firmware upgrade) to write
a firmware image to flash memory.
Signed-off-by: Alberto Bursi <alberto.bursi@outlook.it>
No image build code for the Guruplug, Sheevaplug and NSA310S exists. Drop
support for the boards for now.
Signed-off-by: Mathias Kresin <dev@kresin.me>
The Cisco ON100 device is a Kirkwood based router:
SoC: Marvell 88F6282 1600Mhz
SDRAM memory: 512MB DDR3 1333Mhz
Gigabit ethernet: 2x Marvell 88E1310 (over RGMII)
Flash memory: 512MB
2 bi-colour status LEDs (green/red)
1 Reset button
1 USB 2.0 port (on back)
1 SDIO slot (on back)
This commit adds a target profile of "Cisco Systems ON100" under the target
system "Marvell Kirkwood".
Flashing can be performed over tftp, once "dhcp" has been issued:
tftpboot ${loadaddr} lede-kirkwood-on100-squashfs-factory.bin
nand erase 0x0c0000 ${filesize}
nand write ${loadaddr} 0x0c0000 ${filesize}
Once flashed, set environment variables to boot:
setenv bootcmd nand read \${loadaddr} 0x0c0000 0x540000\; setenv bootargs
\; bootm
saveenv
Signed-off-by: Makoto Takeuchi <mak0@lxsys.co.uk>
these two devices have a Sata led for each sata port.
These leds must be controlled separately by a special
sata led trigger already used in oxnas target.
Both these devices have a single USB led, and to keep
consistent behaviour with the Sata leds that show
sata activity, this led uses usb-host trigger
to show usb activity.
Signed-off-by: Alberto Bursi <alberto.bursi@outlook.it>
the mtd_get_mac_ascii function called within this script requires the inclusion of /lib/functions/system.sh
Signed-off-by: Alberto Bursi <alberto.bursi@outlook.it>
This patch add ZyXEL NSA325 2-Bay Media Server
The ZyXEL NSA325 device is a Kirkwood based NAS:
- SoC: Marvell 88F6702 1600Mhz
- SDRAM memory: 512MB DDR2 400Mhz
- Gigabit ethernet: Marvell Alaska
- Flash memory: 128MB
- 1 Power button
- 1 Power LED (blue)
- 5 Status LED (green/red)
- 1 Copy/Sync button
- 1 Reset button
- 2 SATA II ports (internal)
- 2 USB 2.0 ports (back)
- 1 USB 3.0 port (front)
- Fan (fixed speed)
- hardware watchdog in a mcu
Basically a bigger, more powerful version of NSA310,
installation is the same as they share the same flash layout.
A notable difference is that there is a hardware watchdog
in a mcu on the board, which is disabled by default in the LEDE u-boot.
The watchdog is also disabled with a GPIO activation through
raw register change when kwbooting or it would reset the board before
the new uboot was transferred.
Signed-off-by: Alberto Bursi <alberto.bursi@outlook.it>
Signed-off-by: Felix Fietkau <nbd@nbd.name> [remove dead code]
switch nsa310b mac address reading to mtd_get_mac_ascii helper as
it seems the fw_env.config file is created way later than when
network is set up, when I tested I still had that file included
in the image through /files folder.
Signed-off-by: Alberto Bursi <alberto.bursi@outlook.it>
The ZyXEL NSA310 device is a Kirkwood based NAS:
- SoC: Marvell 88F6702 1200Mhz
- SDRAM memory: 256MB DDR2 400Mhz
- Gigabit ethernet: Realtek (over pcie)
- Flash memory: 128MB
- 1 Power button
- 1 Power LED (blue)
- 5 Status LED (green/red)
- 1 Copy/Sync button
- 1 Reset button
- 2 SATA II port (1 internal and 1 external)
- 2 USB 2.0 ports (1 front and 1 back)
- Smart fan
The stock u-boot cannot read ubi so it should be replaced with the
LEDE/OpenWRT's u-boot or with a u-boot from here
https://github.com/mibodhi/u-boot-kirkwood
This device's boot ROM supports "kwboot" tool
(in mainline u-boot, built automatically if CONFIG_KIRKWOOD is declared)
that sends an uboot image to the board over serial connection, it is very easy to unbrick.
The stock bootloader can use usb and read from FAT filesystems,
so the installation process is simple, place the uboot file on a USB flashdrive
formatted as FAT (here it is "openwrt-kirkwood-nsa310.bin", then connect TTL
to the board and write the following commands in the bootloader console:
usb reset
fatload usb 0 0x1000000 openwrt-kirkwood-nsa310.bin
nand write 0x1000000 0x00000 0x100000
reset
Now you are rebooting in the new u-boot, write this in its console to install the firmware:
usb reset
fatload usb 0 0x2000000 lede-kirkwood-nsa310b-squashfs-factory.bin
nand erase.part ubi
nand write 0x2000000 ubi 0x600000
If your firmware file is bigger than 6 MiBs you should write its size in hex
instead of 0x600000 above, or remove that number entirely (it will take a while in this case).
If you are using another uboot that can read ubi, set mtdparts like this
mtdparts=mtdparts=orion_nand:0x00c0000(uboot),0x80000(uboot_env),0x7ec0000(ubi)
And set your bootcmd to be like this
bootcmd=run setenv bootargs; ubi part ubi; ubi read 0x800000 kernel; bootm 0x800000
Then you can install the firmware as described above.
After you installed (or configured) the u-boot for booting the firmware,
write the device's mac address in the ethaddr u-boot env.
The MAC address is usually on a sticker under the device (one of the two codes is the serial),
it should begin with "107BEF" as it is assigned to ZyXEL.
write in the u-boot console (use your MAC address instead of the example)
setenv ethaddr 10:7B:EF:00:00:00
saveenv
to save the mac address in the u-boot.
Signed-off-by: Alberto Bursi <alberto.bursi@outlook.it>
Remove redundant code: merge boards/cases that share
the same network configuration.
Also fix the alphabetical ordering of the cases.
Signed-off-by: Paul Wassi <p.wassi@gmx.at>
- quote the interface name
- remove call of not existing function
- remove the proto if it's the default proto
Signed-off-by: Mathias Kresin <dev@kresin.me>
Replace former uci-defaults.sh implementation with the uci-defaults-new.sh one
and update all users accordingly.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
SVN-Revision: 47867
This is done with existing code from the WRT1900AC port.
It makes sure the "auto_recovery" bootloader option is set,
and resets the s_env boot counter after a successful boot.
This gives users without a serial console connection some
measure of safety.
Signed-off-by: Claudio Leite <leitec@staticky.com>
SVN-Revision: 47433
Add GoFlex Net "Board Name" , set and cleanup network default and LEDs.
Remove kmod-rtc-marvell from default packages, as the GoFlex net does not have a RTC.
Signed-off-by: L. D. Pinney <ldpinney@gmail.com>
SVN-Revision: 44422
Using port-based VLANs depends on a non-standard
swconfig parameter, which compilcates things like
LuCI that don't know about it. This patch changes
the default to use 802.1q VLANs internally in the
switch, but without tagging packets since we have
two Ethernet ports.
iperf3 tests indicate no difference in performance
versus port-based VLANs when the CPU port is not
using tags.
Signed-off-by: Claudio Leite <leitec@staticky.com>
SVN-Revision: 44122
Set defaults health led to a timer heartbeet (200/800)
and populate network for:
- GuruplugServerPlus
- SheevaPlug
- SheevaPlug with eSATA
Signed-off-by: Gerald Kerma <dreagle@doukki.net>
SVN-Revision: 43752
This maps the LAN ports to eth0 and WAN port to eth1.
Since there are two interfaces the 802.1q VLAN mode
is unnecessary and left disabled. Port-based VLANs
are used instead.
Signed-off-by: Claudio Leite <leitec@staticky.com>
SVN-Revision: 43750
This new argument is used right after starting regular preinit (which
happens if failsafe wasn't triggered). The main purpose of "preinit"
argument is to indicate that failsafe can be triggered, however we were
missing a way to inform user that we don't wait for a trigger anymore.
With this change it's clear when failsafe mode can be triggered.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 43715
