staging/pepe2k/target, branch v19.07.5

mvebu: fixup Turris Omnia U-Boot environment

2020-12-04T16:57:25Z

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 Reviewed-by: Tomasz Maciej Nowak Tested-by: W. Michael Petullo (Turris Omnia "2020") Tested-by: Klaus Kudielka (Turris Omnia) [explain fixup in commit message] Signed-off-by: Paul Spooren (backported from commit 485ce5bbe5cc33526e56817694a79a7d94160e01) Signed-off-by: Adrian Schmutzler

mvebu: base-files: Update Turris Omnia U-Boot environment

2020-12-04T16:57:25Z

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 Reviewed-by: Tomasz Maciej Nowak Tested-by: W. Michael Petullo (Turris Omnia "2020") Tested-by: Klaus Kudielka (Turris Omnia) (cherry picked from commit dfa357a3def512c13f22371d24138b6e8093be18)

mvebu: Add turris-omnia.bootscript

2020-12-04T16:57:25Z

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 Reviewed-by: Tomasz Maciej Nowak Tested-by: W. Michael Petullo (Turris Omnia "2020") (cherry picked from commit afd4375a33840fa949c898fb6bc603e8645edd61)

kernel: backport GD25Q256 support from 4.15

2020-12-01T20:59:30Z

Backport below changes for GigaDevice GD25Q256 support from v4.15: e27072851bf7 mtd: spi-nor: add a quad_enable callback in struct flash_info 65153846b18c mtd: spi-nor: add support for GD25Q256 This chip is used on newer Quad-E4G boards. Before: [ 2.366493] m25p80 spi0.0: unrecognized JEDEC id bytes: c8, 40, 19 [ 2.372853] m25p80: probe of spi0.0 failed with error -2 After: [ 2.371722] m25p80 spi0.0: gd25q256 (32768 Kbytes) [ 2.376694] 5 fixed-partitions partitions found on MTD device spi0.0 [ 2.383043] Creating 5 MTD partitions on "spi0.0": [ 2.387824] 0x000000000000-0x000000030000 : "u-boot" [ 2.394138] 0x000000030000-0x000000031000 : "u-boot-env" [ 2.400608] 0x000000031000-0x000000040000 : "config" [ 2.406830] 0x000000040000-0x000000050000 : "factory" [ 2.413169] 0x000000050000-0x000002000000 : "firmware" Signed-off-by: Kuan-Yi Li

kernel: bump 4.14 to 4.14.209

2020-12-01T20:57:55Z

Refreshed all patches. Altered patches: - 804-i2c-support-layerscape.patch Compile-tested on: ipq40xx, ath79, layerscape/armv8_64b Runtime-tested on: ipq40xx, ath79 Signed-off-by: Hauke Mehrtens

ipq40xx: disable double-tagging for PSGMII devices

2020-11-30T14:27:58Z

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 8c191712558c ("ipq40xx: fix ethernet vlan double tagging") Signed-off-by: David Bauer

kernel: mtd: parser: cmdline: Fix parsing of part-names with colons

2020-11-24T08:48:48Z

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: 9c718b5478ac ("kernel: bump 4.14 to 4.14.200") Signed-off-by: Sven Eckelmann (backported from commit 223eec7e81f8506592fc89cf79a2f14360f5c57b)

ar71xx,ath79: refresh 910-unaligned_access_hacks.patch

2020-11-24T08:27:50Z

Commit c9c7b4b3945c ("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: c9c7b4b3945c ("kernel: add netfilter-actual-sk patch") Signed-off-by: Petr Štetiar

kernel: add netfilter-actual-sk patch

2020-11-23T21:34:37Z

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

layerscape: Fix check after kernel update

2020-11-16T18:31:23Z

The fsl_destroy_mc_io() function was moved, add the new checks to the moved copy and not just remove it. Fixes: ac5297340e64 ("kernel: bump 4.14 to 4.14.206") Signed-off-by: Hauke Mehrtens