Hardware
--------
SoC: Qualcomm IPQ4029
RAM: 512M DDR3
FLASH: - 128MB NAND (Macronix MX30LF1G18AC)
- 4MB SPI-NOR (Macronix MX25R3235F)
TPM: Atmel AT97SC3203
BLE: Texas Instruments CC2540T
attached to ttyMSM0
ETH: Atheros AR8035
LED: WiFi (amber / green)
System (red / green)
BTN: Reset
To connect to the serial console, you can solder to the labled pads next
to the USB port or use your Aruba supplied UARt adapter.
Do NOT plug a standard USB cable into the Console labled USB-port!
Aruba/HPE simply put UART on the micro-USB pins. You can solder yourself
an adapter cable:
VCC - NC
D+ - TX
D- - RX
GND - GND
The console setting in bootloader and OS is 9600 8N1. Voltage level is
3.3V.
To enable a full list of commands in the U-Boot "help" command, execute
the literal "diag" command.
Installation
------------
1. Get the OpenWrt initramfs image. Rename it to ipq40xx.ari and put it
into the TFTP server root directory. Configure the TFTP server to
be reachable at 192.168.1.75/24. Connect the machine running the TFTP
server to the ethernet port of the access point.
2. Connect to the serial console. Interrupt autobooting by pressing
Enter when prompted.
3. Configure the bootargs and bootcmd for OpenWrt.
$ setenv bootargs_openwrt "setenv bootargs console=ttyMSM1,9600n8"
$ setenv nandboot_openwrt "run bootargs_openwrt; ubi part aos1;
ubi read 0x85000000 kernel; bootm 0x85000000"
$ setenv ramboot_openwrt "run bootargs_openwrt;
setenv ipaddr 192.168.1.105; setenv serverip 192.168.1.75;
netget; set fdt_high 0x87000000; bootm"
$ setenv bootcmd "run nandboot_openwrt"
$ saveenv
4. Load OpenWrt into RAM:
$ run ramboot_openwrt
5. After OpenWrt booted, transfer the OpenWrt sysupgrade image to the
/tmp folder on the device.
6. Flash OpenWrt:
$ ubidetach -p /dev/mtd1
$ ubiformat /dev/mtd1
$ sysupgrade -n /tmp/openwrt-sysupgrade.bin
To go back to the stock firmware, simply reset the bootcmd in the
bootloader to the original value:
$ setenv bootcmd "boot"
$ saveenv
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit 102c8c55f217606cdbdc9a449667e034676b3e75)
Refreshed all patches.
Removed patches because included in upstream:
- 499-mtd-parser-cmdline-Fix-parsing-of-part-names-with-co.patch
- 0071-2-PCI-qcom-Fixed-IPQ806x-PCIE-reset-changes.patch
Compile-tested on: ipq40xx, lantiq/xrx200, x86/64, ipq806x
Runtime-tested on: ipq40xx, lantiq/xrx200, x86/64
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Currently it's not possible to tftpboot initramfs image on archer-c7-v5
as the image contains tplink-v1-header which leads to:
ath> bootm
## Booting image at 81000000 ...
Bad Magic Number
as U-Boot expects uImage wrapped image. This is caused by following
inheritance issue:
define Device/Init
KERNEL_INITRAMFS = $$(KERNEL)
define Device/tplink-v1
KERNEL := kernel-bin | append-dtb | lzma
KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | tplink-v1-header
define Device/tplink-safeloader
$(Device/tplink-v1)
define Device/tplink-safeloader-uimage
$(Device/tplink-safeloader)
KERNEL := kernel-bin | append-dtb | lzma | uImageArcher lzma
define Device/tplink_archer-c7-v5
$(Device/tplink-safeloader-uimage)
where tplink-v1 defines KERNEL_INITRAMFS with tplink-v1-header and it's
then used by all devices inheriting from tplink-safeloader. Fix this by
overriding KERNEL_INITRAMFS to KERNEL variable again.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit ceeece9ffaa5a3a336505332c39794d76c08b2ca)
Refreshed all patches.
Removed patches because included in upstream:
- 315-v5.10-usbnet-ipeth-fix-connectivity-with-ios-14.patch
Compile-tested on: ipq40xx, ath79, x86/64
Runtime-tested on: ipq40xx, ath79
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Previously only the power LED was working.
With this patch all leds except 5GHz are working.
Signed-off-by: Davide Fioravanti <pantanastyle@gmail.com>
[rephrased commit title, drop status property]
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit 67d019ac94015707926235a3ac0aa6bb12cee8c2)
This fixes tethering with devices using iOS 14. Prior to this patch,
connections to remote endpoints were not possible while data transfers
between the OpenWrt device and the iOS endpoints worked fine.
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit f64496f30f2ef97124dc4e13a48ee0de9d51832e)
Fixup dfa357a3de "mvebu: base-files: Update Turris Omnia U-Boot
environment" which should have included this file as well.
By rebasing the initial patch this file somehow disappeared.
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Reviewed-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Tested-by: W. Michael Petullo <mike@flyn.org> (Turris Omnia "2020")
Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com> (Turris Omnia)
[explain fixup in commit message]
Signed-off-by: Paul Spooren <mail@aparcar.org>
(backported from commit 485ce5bbe5cc33526e56817694a79a7d94160e01)
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Move the update procedure from sysupgrade to first boot, which is much
more convenient in the sysupgrade case (otherwise the environment is
always one generation behind).
Check whether we have an old U-Boot release installed, and update the
environment only if necessary.
Some notes on the U-Boot environment:
The first 9 lines are a copy of the default environment of the old U-Boot
release - only modified, to run "distro_bootcmd", in case "mmcboot" fails
to boot the factory OS.
The remaining 16 lines are a backport of the default environment of the
new U-Boot release (shipped with CZ11NIC23). The main entry point is
"distro_bootcmd", which eventually sources boot.scr. This way, we have
a unified boot protocol for all Turris Omnia revisions so far.
This commit also fixes a shortcoming of previous Turris Omnia support:
Users may install OpenWrt with the Turris Omnia in factory state
(i.e. invalid environment store). In that case, neither fw_setenv, nor
U-Boot itself, would import the default environment from the image -
screwing up the rescue system, at least!
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Reviewed-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Tested-by: W. Michael Petullo <mike@flyn.org> (Turris Omnia "2020")
Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com> (Turris Omnia)
(cherry picked from commit dfa357a3def512c13f22371d24138b6e8093be18)
In contrast to the U-Boot version shipped with older versions of Turris
Omnia (CZ11NIC13, CZ11NIC20), the version shipped with Turris Omnia 2019
(CZ11NIC23) relies on the existence of /boot.scr.
Consequently, add a suitable boot script to the sysupgrade image.
Flash instructions for Turris Omnia 2019:
- Download openwrt-...-sysupgrade.img.gz, gunzip it, and copy the resulting
.img file to the root of a USB flash drive (FAT32 or ext2/3/4).
- Enter a rescue shell: Either via 5-LED reset and ssh root@192.168.1.1
on LAN port 4, or via 7-LED reset and the serial console.
- Insert the USB drive and mount it:
mkdir /mnt; mount /dev/sda1 /mnt
- Flash the OpenWrt image to eMMC:
dd if=/mnt/openwrt-...-sysupgrade.img of=/dev/mmcblk0 bs=4096 conv=fsync
- Reboot.
Flash instructions using a temporary "medkit" installation were written for
the older versions of Turris Omnia, and will *not* work on the Turris Omnia
2019.
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Reviewed-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Tested-by: W. Michael Petullo <mike@flyn.org> (Turris Omnia "2020")
(cherry picked from commit afd4375a33840fa949c898fb6bc603e8645edd61)
This commit disables the double tagging recently backported to 19.07.
Operating the switch on the S-Tag had the advantage of being able to
have separate VLANs for the same C-VID on LAN and WAN. However, this
broke the ability to configure C-TAG modifications on the switch. Also
performance took a significant toll.
Fixes: commit 8c19171255 ("ipq40xx: fix ethernet vlan double tagging")
Signed-off-by: David Bauer <mail@david-bauer.net>
Some devices (especially QCA ones) are already using hardcoded partition
names with colons in it. The OpenMesh A62 for example provides following
mtd relevant information via cmdline:
root=31:11 mtdparts=spi0.0:256k(0:SBL1),128k(0:MIBIB),384k(0:QSEE),64k(0:CDT),64k(0:DDRPARAMS),64k(0:APPSBLENV),512k(0:APPSBL),64k(0:ART),64k(custom),64k(0:KEYS),0x002b0000(kernel),0x00c80000(rootfs),15552k(inactive) rootfsname=rootfs rootwait
The change to split only on the last colon between mtd-id and partitions
will cause newpart to see following string for the first partition:
KEYS),0x002b0000(kernel),0x00c80000(rootfs),15552k(inactive)
Such a partition list cannot be parsed and thus the device fails to boot.
Avoid this behavior by making sure that the start of the first part-name
("(") will also be the last byte the mtd-id split algorithm is using for
its colon search.
Fixes: 9c718b5478 ("kernel: bump 4.14 to 4.14.200")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
(backported from commit 223eec7e81f8506592fc89cf79a2f14360f5c57b)
Commit c9c7b4b394 ("kernel: add netfilter-actual-sk patch") has
touched net/ipv6/netfilter/ip6table_mangle.c which in turn has affected
910-unaligned_access_hacks.patch so the patch needs to be refreshed.
Fixes: c9c7b4b394 ("kernel: add netfilter-actual-sk patch")
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Backport of linux kernel commit 46d6c5a to 4.14 kernel.
netfilter: use actual socket sk rather than skb sk when routing harder
Signed-off-by: Aaron Goodman <aaronjg@stanford.edu>
The fsl_destroy_mc_io() function was moved, add the new checks to the
moved copy and not just remove it.
Fixes: ac5297340e ("kernel: bump 4.14 to 4.14.206")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The MAC address for the wmac 2.4 GHz radio of the Ubiquiti UniFi AC
family of devices is actually embedded in the mtd-cal-data, so there
is no need for mtd-mac-address (which was incorrectly forcing wmac
to have the same MAC as eth0). This makes it coherent with the stock
firmware and the ar71xx target:
· XX:XX:XX:X0:XX:XX eth0
· XX:XX:XX:X1:XX:XX ath0/wlan1 (2.4 GHz)
· XX:XX:XX:X2:XX:XX ath1/wlan0 (5 GHz)
Checked on a UniFi AC Mesh, a UniFi AC LR and a UniFi Lite.
Signed-off-by: Roger Pueyo Centelles <roger.pueyo@guifi.net>
(cherry picked from commit 20ace70db65c3f1cb6a842d3092ac2eb7be81b5a)
The Ubiquiti UniFi AP does not have a AHB connected radio but a PCI one.
Also the EEPROM ist only 0x440 bytes of length.
Reported-by: Martin Weinelt <martin@darmstadt.freifunk.net>
Tested-by: Martin Weinelt <martin@darmstadt.freifunk.net>
Signed-off-by: David Bauer <mail@david-bauer.net>
(backported from commit 4c5eb1040f94871626f6a533242c3a9c068d5bb6)
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The D-Link DIR-645 currently uses an incorrect logic level for its
buttons.
Correct them in order to prevent unintentional activation of failsafe
mode.
Reported-by: Perry Melange <isprotejesvalkata@gmail.com>
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit 929e8f0f553637076f2612fb1c2225c5cee1f7ab)
The order of function and color in the labels in inverted for the
LAN LEDs. Fix it.
Fixes: 915966d861 ("ath79: Port PowerCloud Systems CAP324 support")
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
(cherry picked from commit 96023cd4ba66c33e77d9df562dda44b0a1ba1ac9)
The generic bootscript is tailored around a downstream firmware and
doesn't work on a firmware built from mainline components.
Add a bootscript which:
* sets $console since mainline u-boot doesn't do that
* uses distro boot variables, so OpenWRT can be booted off any supported
device when using a mainline firmware
* sets missing distro boot variables for the downstream firmware
Booting with a downstream firmware is unchanged.
Booting with a mainline firmware now works.
Signed-off-by: Andre Heider <a.heider@gmail.com>
(cherry picked from commit c43b45863e38fb18a486601c1601f1485d649c0b)
This fixes a regression after a kernel change in 4.14.200 [1] that
led to build failure on oxnas/ox820:
drivers/ata/sata_oxnas.c:2238:13: error: initialization of
'enum ata_completion_errors (*)(struct ata_queued_cmd *)'
from incompatible pointer type
'void (*)(struct ata_queued_cmd *)' [-Werror=incompatible-pointer-types]
.qc_prep = sata_oxnas_qc_prep,
^~~~~~~~~~~~~~~~~~
drivers/ata/sata_oxnas.c:2238:13: note:
(near initialization for 'sata_oxnas_ops.qc_prep')
Our local driver is changed the same way as prototyped in the
kernel patch, i.e. return type is changed and AC_ERR_OK return
value is added.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=306a1c5b5683c1d37565e575386139a64bdbec6f
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
(cherry picked from commit f6ca57e4f40528a8a0103c9f0e9647a2e11d10c3)
reg accesses on integrated ar8229 sometimes fails. As a result, phy read
got incorrect port status and wan link goes down and up mysteriously.
After comparing ar8216 with the old driver, these local_irq_save/restore
calls are the only meaningful differences I could find and it does fix
the issue.
The same changes were added in svn r26856 by Gabor Juhos:
ar71xx: ag71xx: make switch register access atomic
As I can't find the underlying problem either, this hack is broght
back to fix the unstable link issue.
This hack is only suitable for ath79 mdio and may easily break the
driver on other platform. Limit it to ath79-only as a target patch.
Fixes: FS#2216
Fixes: FS#3226
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
(cherry picked from commit 86fdc8abed5992a74078b000b5ff9da723b6f46b)
The LED color was missing in 01_leds.
Fixes: 745dee11ac ("ath79: add support for WD My Net Wi-Fi Range
Extender")
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
(cherry picked from commit d232a8ac7d1679f7ff97cbc66b4c49c940bd009f)
The current code acknowledged interrupts *after* polling.
This is the wrong way around, and could cause an interrupt to
be missed.
This is not likely to be fatal as another packet, and so another
interrupt, should come along soon. But maybe it is causing
problems, so let's fix it anyway.
Signed-off-by: NeilBrown <neil@brown.name>
(Note that this matches the upstream driver.)
Signed-off-by: Rosen Penev <rosenp@gmail.com>
After years of trying to find the reason for random kernel crashes
while both CPU and SATA are under load it has been found.
Some odd commented-out #defines in kref's single-port driver [1] which
were copied from the vendor driver made me develop a theory:
The IO-mapped memory area for DMA descriptors apparetly got some holes
just before the alignment boundaries.
This feels like an off-by-one bug in the hardware or maybe those fields
are used internally by the SATA controller's firmware.
Whatever the cause is: they cannot be used and trying to use them
results in reading back unexpected stuff and ends up with oopsing
Unable to handle kernel paging request at virtual address d085c004
Work around the issue by reducing the area used for bmdma descriptors.
This reduces SATA performance (iops) quite a bit, but finally makes
things work reliably. Possibly one could optimize this much more by
really just skipping the holes in that memory area -- however, that
seems to be non-trivial with the driver and libata in it's current form
(suggestions are welcome).
The 'proper' way to have good SATA performance would be to make use of
the hardware RAID features (one can use the JBOD mode to access even
just a single disc transparently through the RAID controller integrated
in the SATA host instead of accessing the SATA ports 'raw' as we do
now).
[1]: https://github.com/kref/linux-oxnas/blob/master/drivers/ata/sata_oxnas.c#L25
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
(cherry picked from commit 5793112f751ee3d9f841af4846d68e6b1ff1bff4,
including fixup commit d75e75306301852a848824cf268d8b58eda28a8a)
This adds support for the TP-Link TL-WR710N v2.1. It is basically a
re-issue of the v1.2.
Specifications:
SoC: Atheros AR9331
CPU: 400 MHz
Flash: 8 MiB
RAM: 32 MiB
WiFi: 2.4 GHz b/g/n
Ethernet: 2x 100M ports
USB: 1x 2.0
The only difference from the v1 is the TP-Link hardware ID/revision.
Attention:
The TL-WR710N v2.0 (!) has only 4 MB flash and cannot be flashed with
this image. It has a different TPLINK_HWREV, so accidental flashing
of the factory image should be impossible without additional measures.
Unfortunately, the v2.0 in ar71xx has the same board name, so sysupgrade
from ar71xx v2.0 into ath79 v1/v2.1 will not be prevented, but will brick
the device.
Flashing instruction:
Upload the factory image via the OEM firmware GUI upgrade mechanism.
Further notes:
To make implementation easier if somebody desires to port the 4M v2.0,
this already creates two DTSI files.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Tested-by: Fabian Eppig <fabian@eppig.de>
(backported from eb531337a779a48a2d17bc66f0d222325d6c1563)
The test is meant to check the result of the preceding kmalloc()
Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
(cherry picked from commit d0498872ff71a79f0676cfc6b6b547c499bff712)
All other SoC DTSI files have gpio enabled by default, only
ar9330/ar9331 disable it by default, only to have it enabled again
afterwards for each individual device.
So, do not disable it in the first place, and drop all device-specific
status statements afterwards.
Though this is a cosmetic commit, it might be a pitfall for
device-support backporters if missing. Since backporting it is trivial,
let's just do it.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
(cherry picked from commit dc1280ef652c6522269c7a864810c19362d33dc4)
The node needs to be terminated by a semicolon.
Fixes: 8484a764df20 ("ath79: ar724x: make sure builtin-switch is
enabled in DT")
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
(cherry picked from commit e329e71c6915ffdf7fe99efc323a6de7867d0cbe)
On ar7240/ar7241 the mdioX node with the builtin-switch is enabled
in the DTSI files, but the parent ethX node is left disabled. It
only gets enabled per device or device family, and has not been
enabled at all yet for the TP-Link WA devices with ar7240, making
the switch unavailable there.
This patch makes sure ð0/ð1 nodes are enabled together with
the &mdio0/&mdio1 nodes containing the builtin-switch.
For ar7240_tplink_tl-wa.dtsi, ð0 is properly hidden again via
compatible = "syscon", "simple-mfd";
This partially fixes FS#2887, however it seems dmesg still does
not show cable (dis)connect in dmesg for ar7240 TP-Link WA
devices.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
(cherry picked from commit 8484a764df20cdd673c74b583bfbf71e10c02726)
This patch improves ath79 support for Netgear WNR612v2.
Router functionality becomes identical to ar71xx version.
Changes include:
* software control over LAN LEDs via sysfs
* correct MAC addresses for network interfaces
* correct image size in device definition
* dts: 'keys' renamed to 'ath9k-keys'
* dts: 'label-mac-device' set to eth1 (LAN)
* dts: formatting adjustments
Signed-off-by: Michal Cieslakiewicz <michal.cieslakiewicz@wp.pl>
(cherry picked from commit d74324e407de7fb641310070762923f7e4cd2d6c)
[remove label-mac-device]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Currently AR724x pinmux for register 0x18040028 controls only JTAG disable bit.
This patch adds new DTS settings to control LAN LEDs and CLKs that allow
full software control over these diodes - exactly the same is done by ar71xx
target in device setup phase for many routers (WNR2000v3 for example).
'switch_led_disable_pins' clears AR724X_GPIO_FUNC_ETH_SWITCH_LED[0-4]_EN bits.
'clks_disable_pins' clears AR724X_GPIO_FUNC_CLK_OBS[1-5]_EN and
AR724X_GPIO_FUNC_GE0_MII_CLK_EN bits. These all should be used together, along
with 'jtag_disable_pins', to allow OS to control all GPIO-connected LEDs and
buttons on device.
Signed-off-by: Michal Cieslakiewicz <michal.cieslakiewicz@wp.pl>
(cherry picked from commit 69df7eb73d9922e5e717b004aae06f93fe692dba)
Based on OpenWRT Table of Hardware > Xiaomi > Xiaomi Mi WiFi Mini
Switch Ports Defaults:
0, 1: LAN
4: WAN
6: CPU
Port in Web GUI (word printed on bottom of case)
WAN(Internet) map to switch port 4
LAN1(.) map to switch port 1
LAN2(..) map to switch port 0
CPU map to switch port 6
current setting is 1 WAN/ 4 LAN port, fix it.
Signed-off-by: Chih-Wei Chen <changeway@gmail.com>
[rebased after base-files split, fixed commit title]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
(backported from commit 3e88ab79b03917bc4b03b34db12edf622bde1de1)
The CONFIG_EFI_CUSTOM_SSDT_OVERLAYS option was added in kernel 4.14.188,
set it for the x86/generic target.
This fixes a build problem in the x86/generic target.
Fixes: 148d59c67e ("kernel: update kernel 4.14 to version 4.14.193")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The device uses a rf-kill switch instead of a button. Furthermore the
GPIO is active high.
Signed-off-by: Christoph Krapp <achterin@googlemail.com>
(cherry picked from commit 0af656e978f1adac4061516d9d2e661e101ba64c)
As the ath79 port of this device uses a combined kernel + root
partition the uboot bootcmd variable needs to be changed. As using
cli/luci is more convenient than opening up the case and using a uart
connection, lets unlock the uboot-env partition for write access.
Signed-off-by: Christoph Krapp <achterin@googlemail.com>
(cherry picked from commit 982c1f6e42c5b3e0f23eedd825a317a2872aa37b)
WizFi630S had some pins changed in the release version of the board.
The run led, wps button and a slide switch where affected.
This patch is correcting this.
i2c is removed as it is sharing a pin with the run (system) led.
uart2 is enabled as it is also enabled in the OEM firmware.
Signed-off-by: Tobias Welz <tw@wiznet.eu>
(backported from commit d0b229f553a814b22c16976e40a197f892c0c0df)
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
WIZnet WizFi630s board name is written slightly different it its OEM
OpenWrt firmware. This causes an incompatibility warning during flashing
with sysupgrade. This patch is adding the vendor board name to the
supported devices list to avoid this warning. For initial flashing you
can use sysupgrade via command line or luci beside of TFTP.
Do not keep the OEM configuration during sysupgrade.
Signed-off-by: Tobias Welz <tw@wiznet.eu>
(cherry picked from commit 816973f42aa47d910d3e35c2f8f8eb9d67416396)
Jan Alexander