Commit Graph

18 Commits (fbd4214bb0727268aa535af5b600d38939ec8dbc)

Author SHA1 Message Date
Adrian Schmutzler a9703db720 mvebu: fix sysupgrade experience for early DSA-adopters
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>
4 years ago
Adrian Schmutzler 664237deaa mvebu: fix alphabetic sorting in 02_network
This has been overlooked when removing solidrun,clearfog-a1 entry.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
4 years ago
Adrian Schmutzler e496eefccc mvebu: increase compat version for SolidRun ClearFog Base
When changing the Pro variant to DSA, the ethernet interface rename
script was dropped by all devices to keep them in sync:

  be309bfd74 ("mvebu: drop 06_set_iface_mac preinit script")

Therefore, network config will be broken after upgrade for the
Base variant as well. Increase the compat version and provide a
message to signal that to the users.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
4 years ago
Adrian Schmutzler 494f12c52d mvebu: implement compatibility version for DSA migration
This implements the newly introduced compat-version to prevent
upgrade between swconfig and DSA for mvebu.

Just define a compat version with minor increment and an appropriate
message for both image (in Makefile) and device (in base-files).

Having taken care of sysupgrade, we can put back the SUPPORTED_DEVICES
that have been removed in previous patches to prevent broken config.

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>
4 years ago
Alberto Bursi 480003e9eb mvebu: add Kobol Helios 4 device
The Helios 4 is a NAS from Kobol
that is powered by an Armada 38x
MicroSOM from Solidrun, similarly
to Clearfog.

This device has:
-Armada 38x CPU
 (dual core ARMv7 1.6 Ghz)
-2 GB of ECC RAM
-Gigabit ethernet (Marvell)
-2x USB 3.0 ports
-4x Sata 3.0 ports
-i2c header (J9 |>GND|SDA|SCL|VCC)
-2x 3-pin fan headers with PWM
-micro-usb port is a TTL/UART to
 USB converter connected to TTL
-MicroSD card slot
-System, 4xSata and 1xUSB LEDs

NOT WORKING: fan control

Fan Control requires a kernel patch
that is available in the Armbian
project (the "default firmware"
of this device) and named
mvebu-gpio-remove-hardcoded
-timer-assignment
This patch isn't acceptable
by OpenWrt, it should be upstreamed.
I also have that patch in my own
local OpenWrt builds,
in case you want a more
clean and less confusing patch
for upstreaming.

To install, write the disk image
on a micro SD card with dd or
win32 disk imager, insert the
card in the slot.
Check that the dip switch battery
for boot selection is as follows
Switch 1 and 2 down/off, switches
3, 4, 5 up/on.

Signed-off-by: Alberto Bursi <bobafetthotmail@gmail.com>
4 years ago
Adrian Schmutzler 89bb4ee450 mvebu: remove non-existant board name solidrun,clearfog-a1
In 02_network, the board name solidrun,clearfog-a1 is used in a
case, but it does not seem to be used/exist anywhere else in OpenWrt.

The valid strings are:
- solidrun,clearfog-pro-a1
- solidrun,clearfog-base-a1

Fixes: 12795ec9f1 ("mvebu: split interface configuration for
clearfog pro and base")

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
4 years ago
Jose Olivera d0e8b8310f mvebu: fix default EU regdomain for Linksys WRT AC devices
The mwlwifi driver sets the default country code for EU (fi-
rmware region code 0x30) certified devices to FR (France),
not DE (Germany). Whilst this is a trivial fix, novice users
may not know how mwlwifi negatively reacts to a non-matching
country code and may leave the setting alone. Especially si-
nce it is under the advanced settings section in LuCI.

Relevant mwlwifi driver code:
0a550312dd

The mwlwifi driver readme states "Please don't change country
code and let mwlwifi set it for you." However, OpenWrt's current
behaviour does not adhere to this with its default, 'just flashed
from factory' setting for EU devices.

Signed-off-by: Jose Olivera <oliverajeo@gmail.com>
[rebase, extend commit message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
4 years ago
Adrian Schmutzler 48c1fdd046 treewide: drop shebang from non-executable target files
This drops the shebang from all target files for /lib and
/etc/uci-defaults folders, as these are sourced and the shebang
is useless.

While at it, fix the executable flag on a few of these files.

This does not touch ar71xx, as this target is just used for
backporting now and applying cosmetic changes would just complicate
things.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
4 years ago
Paul Spooren df6f3090c4 mvebu: rename Linksys devices based on their common names
The Linksys devices in mvebu target feature a mixed naming,
where parts are based on the official product name (device
node, image; e.g. WRT3200ACM) and parts are based on the
internal code name (DTS file name, compatible, LED labels;
e.g. rango). This inconsistent naming has been perceived
as quite confusing.

A recent attempt by Paul Spooren to harmonize this naming
in kernel has been declined there. However, for us it still
makes sense to apply at least a part of these changes
locally.

Primarily, this patch changes the compatible in DTS and thus
the board name used in various scripts to have them in line
with the device, model and image names. Due to the recent
switch from swconfig to DSA, this allows us to drop
SUPPORTED_DEVICES and thus prevent seamless upgrade between
these incompatible setups.

However, this does not include the LED label rename from
Paul's initial patch: I don't think it's worth keeping the
enormous diff locally for this case, as we can implement
this much easier in 01_leds if we have to live with the
inconsistency anyway.

Signed-off-by: Paul Spooren <mail@aparcar.org>
[rebase, extend to all devices, drop DT LED changes]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
4 years ago
DENG Qingfang be309bfd74 mvebu: drop 06_set_iface_mac preinit script
MAC address is set in board.d script
Interface swapping is not needed anymore as switching to DSA breaks
previous configuration anyway

Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
4 years ago
DENG Qingfang 9b34ea4f62 mvebu: use ucidef to set up MAC address
Use ucidef to set up MAC address instead of preinit script

Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
4 years ago
DENG Qingfang f799c65946 mvebu: update default config for DSA
Update network/LED configuration for DSA driver.
sysupgrade from images prior to this commit with config preserved
will break the ethernet.

Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
4 years ago
Daniel González Cabanelas 85ef69b202 mvebu: add support for Buffalo LinkStation LS421DE
Buffalo LinkStation LS421DE is a dual bay NAS, based on Marvell Armada 370

Hardware:
   SoC:         Marvell Armada 88F6707-A1
   CPU:         Cortex-A9 1200 MHz, 1 core
   Flash:       SPI-NOR 1 MiB, NAND 512 MiB
   RAM:         DDR3 512 MiB
   Ethernet:    1x 10/100/1000 Mbps
   USB:         1x 2.0, 1x 3.0
   SATA:        2x 3.0 Gbps
   LEDs/Input : 5x / 2x (1x button, 1x slide-switch)
   RTC:         Ricoh RS5C372A, I2C, no battery

Flash instruction (UART+TFTP):
  1. Downgrade the OEM firmware to 1.34 version (BUFFALO_BOOTVER=0.13)
  2. Remove any hard drive from inside the bays.
  3. Boot the Openwrt initramfs image using the U-Boot serial console:
         tftpboot 0x1200000 buffalo_ls421de-initramfs-kernel.bin
         bootm 0x1200000
  4. Flash the sysupgrade image using the Openwrt console:
         sysupgrade -n buffalo_ls421de-squashfs-sysupgrade.bin
  5. Wait until it finish, the device will reboot with Openwrt installed
     on the NAND flash.

Note:
  - Device shuting down doesn't work, even if the power slide switch is
    used. We must first, via MDIO, set the unused LED2 at the ethernet
    phy0 to off state. Reboot works ok.

Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
Reviewed-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
4 years ago
Tomasz Maciej Nowak 2d61f8821c mvebu: cortexa9: correct cpu subtype
Armada 370  processors have only 16 double-precision registers. The
change introduced by 8dcc108760 ("toolchain: ARM: Fix toolchain
compilation for gcc 8.x") switched accidentally the toolchain for mvebu
cortexa9 subtarget to cpu type with 32 double-precision registers. This
stems from gcc defaults which assume "vfpv3-d32" if only "vfpv3" as mfpu
is specified. That change resulted in unusable image, in which kernel
will kill userspace as soon as it causing "Illegal instruction".

Ref: https://forum.openwrt.org/t/gcc-was-broken-on-mvebu-armada-370-device-after-commit-on-2019-03-25/43272
Fixes: 8dcc108760 ("toolchain: ARM: Fix toolchain compilation for
gcc 8.x")
Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
4 years ago
Adrian Schmutzler 1fa04b5d9f mvebu: split base-files across subtargets
For the mvebu target in particular, there is a lot of files in
base-files that are only relevant for one subtarget. Improve
overview and reduce size per subtarget by moving/splitting
base-files depending on the subtarget they belong to.

While at it, consolidate 01_leds by using the model part of
the board name as variable.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Acked-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
4 years ago
Tomasz Maciej Nowak 9f6c4ba25c mvebu: move HARDEN_BRANCH_PREDICTOR to common config
This symbol is enabled in all subtargets, move it to common kernel
config.

Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Acked-by: Rosen Penev <rosenp@gmail.com>
5 years ago
Koen Vandeputte ca88f4153f kernel: bump 4.14 to 4.14.77
Refreshed all patches.

Altered patches:
- 666-Add-support-for-MAP-E-FMRs-mesh-mode.patch

New symbol for arm targets:
- HARDEN_BRANCH_PREDICTOR

Compile-tested on: ar71xx, cns3xxx, imx6
Runtime-tested on: ar71xx, cns3xxx, imx6

Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
6 years ago
Hauke Mehrtens be3da900cd mvebu: Add subtarget for Cortex A9 build
This is in preparation for adding a subtarget for the Cortex A53 later.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
6 years ago