Commit Graph

886 Commits

Author SHA1 Message Date
Fabian Bläse
16c47c23df mvebu: rb5009: add label-mac-device
Add the label-mac-device alias.

Signed-off-by: Fabian Bläse <fabian@blaese.de>
Link: https://github.com/openwrt/openwrt/pull/17313
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-12-21 12:19:13 +01:00
Rosen Penev
6280b4abfb mvebu: devm for mutex_init
It's common to avoid calling mutex_destroy when done. It's not correct
strictly speaking.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16753
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2024-11-23 17:19:56 +01:00
Rosen Penev
cd92cbddf8 kernel: filter out compiler opts from config
These get dynamically set based on compiler version. Not relevant for
targets.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16770
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2024-11-17 14:55:16 +01:00
Rosen Penev
da8abd4a1e kernel: remove GCC11_NO_ARRAY_BOUNDS
This symbol is no longer present.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16770
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2024-11-17 14:55:16 +01:00
Marek Behún
749a43325b utils: Add the omnia-eeprom utility
Add a new utility, `omnia-eeprom`, which can be used to print / set
EEPROM fields on Turris Omnia.

One example when this utility might be useful is if the board
experiences random crashes due to newer versions of the DDR training
algorithm in newer U-Boot. The user can change the DDR speed from 1600K
to 1333H to solve these issues, with

  ```
  omnia-eeprom set ddr_speed 1333H
  ```

Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://github.com/openwrt/openwrt/pull/16264
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-11-15 13:01:31 +01:00
Christian Marangi
d6c6e4f722
mvebu: cortexa9: drop removal of firewall4 package
Drop removal of firewall4 package for Synology DS213j device.

With OPKG the firewall4 package was installed anyway as it's a
dependency of luci-app-firewall and was silently installed again later
in such condition. Drop it to fix support for APK.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
2024-10-30 14:17:33 +01:00
Hauke Mehrtens
1306885968 kernel: Reorder config files
Reorder the kernel configuration files.

This was done uisng:
./scripts/kconfig-reorder.sh

Link: https://github.com/openwrt/openwrt/pull/16743
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2024-10-22 21:13:26 +02:00
John Audia
51bbc8114b kernel: bump 6.6 to 6.6.57
1. Update target/linux/generic/config-6.6 for new ksym
2. Refresh patches

Changelog: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.57

Added:
	generic/backport-6.6/777-netfilter-xtables-fix-typo-causing-some-targets-to-not-load-on-IPv6.patch[1]

Manually rebased:
	generic/hack-6.6/645-netfilter-connmark-introduce-set-dscpmark.patch

Removed upstreamed:
	gemini/patches-6.6/0001-net-ethernet-cortina-Drop-TSO-support.patch[2]
	gemini/patches-6.6/0004-net-ethernet-cortina-Restore-TSO-support.patch[3]

All other patches automatically rebased.

1. https://lore.kernel.org/all/20241019-xtables-typos-v2-1-6b8b1735dc8e@0upti.me/
2 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.6.57&id=452c0740d72c6a77a41f6ddc318a48f18c3d2346
3. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.6.57&id=611f74b0e7fb93ee2366d9d7edca546806b220e9

Build system: x86/64
Build-tested: x86/64/AMD Cezanne, flogic/xiaomi_redmi-router-ax6000-ubootmod, ramips/tplink_archer-a6-v3
Run-tested: x86/64/AMD Cezanne, flogic/xiaomi_redmi-router-ax6000-ubootmod, ramips/tplink_archer-a6-v3

Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/16726
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2024-10-19 16:21:32 +02:00
Robert Marko
5338c8da6c mvebu: cortex-a9: add upgrade methode to nas1dual
The blamed commit adds a upgrade recipe for nas1dual to specify the
firmware partition name, but does not actually include the recipe that
will be called.

Since it previously relied on the default one, add that one.

Fixes: d21720fa90 ("mvebu: fix default partition name")
Link: https://github.com/openwrt/openwrt/pull/16704
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-10-14 13:17:01 +02:00
Boris Krasnovskiy
d21720fa90 mvebu: fix default partition name
The firmware partition name is specifc to ipTIME NAS1dual and should not be
set globally.

Fixes: #16148
Fixes: 6ff970bb51 ("mvebu: add support for ipTIME NAS1dual")
Signed-off-by: Boris Krasnovskiy <borkra@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16690
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-10-13 14:18:21 +02:00
John Thomson
7d33aedd10 generic: platform/mikrotik: add wlan lz77 decompress
A number of new (or with recently updated caldata)
Mikrotik devices are using LZ77 magic for wlan tag hard_config data.
New devices include the Chateau LTE12 [1], and ax devices [2]
Newly factory flashed devices may include the hap ac3 [3]

This can be seen in decoded OEM supout [4] dmesg:
"radio data lz77 decompressed from"…

Investigating an arm RouterOS flash.ko module, and supplied example
hard_config dumps, the format was guessed via decompilation and live
debugging [5]. This decoder was then built from the guessed format
specification.

debug prints can be enabled in a DYNAMIC_DEBUG kernel build via the
kernel cmdline:

        chosen {
-               bootargs = "console=ttyS0,115200";
+               bootargs = "console=ttyS0,115200 dyndbg=\"file drivers/platform/mikrotik/* +p\"";
        };

[1]: https://forum.openwrt.org/t/no-wireless-mikrotik-rbd53ig-5hacd2hnd/157763/4
[2]: https://forum.openwrt.org/t/mikrotik-routeros-v7-x-and-openwrt-sysupgrade/148072/17
[3]: https://forum.openwrt.org/t/adding-support-for-mikrotik-hap-ax2/133715/47
[4]: https://github.com/farseeker/go-mikrotik-rif
[5]: https://github.com/john-tho/routeros-wlan-lz77-decode

Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au>
Link: https://github.com/openwrt/openwrt/pull/15774
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-10-08 10:45:58 +02:00
INAGAKI Hiroshi
06fed85948 mvebu: improve sysupgrade for FortiGate/FortiWiFi devices
Update sysupgrade script (fortinet.sh) for Fortinet devices in
mvebu/cortexa9 and fix the following issues,

- Some individuals of FortiGate/FortiWiFi 30E/5xE devices has wrong
  kernel/rootfs offsets in "firmware-info" partition and they are not
  updated with the current sysupgrade script for Fortinet devices
  (fortinet.sh).
  As a result, the bootloader tries to load kernel data from the wrong
  address and boot with it after OpenWrt installation.
  The new script handles offsets in addition to length values.

and improve the following points.

- Only 2 bytes are handled with the current sysupgrade script
  (fortinet.sh) for kernel/rootfs length. The new script handles 4 bytes
  instead.

- The image names of image0/image1 are not handled and not updated when
  sysupgrade. The new sysupgrade script handles it and update to
  "<dist> <version> <revision>" if firmware metadata is available.
  (ex.: "OpenWrt SNAPSHOT r27440-25384026")

log of new sysupgrade script (fortinet.sh):

Tue Sep 17 10:29:16 UTC 2024 upgrade: Performing system upgrade...
Image Index: 0
Image Name : "OpenWrt SNAPSHOT r27440-25384026"
             --> "OpenWrt SNAPSHOT r27441-b3a0806a05"

  kernel:
    old: 0x003c4e00@0x00200000
    new: 0x003c4e00@0x00200000

  rootfs:
    old: 0x005c0200@0x00800000
    new: 0x005c0200@0x00800000

Unlocking kernel ...

Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16409
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2024-09-22 15:29:16 +02:00
INAGAKI Hiroshi
27535ead72 mvebu: update triggers of "SPEED" LEDs on FortiGate/FortiWiFi devices
The mdio bus number of mv88e6xxx was changed to '0' from '1' and the
"mv88e6xxx-1:<addr>:<speed>" triggers are unavailable now.
Update triggers for "SPEED" LEDs to make working that LEDs again.

Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16409
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2024-09-22 15:29:16 +02:00
INAGAKI Hiroshi
5c43c157aa mvebu: fix "compatible" of regulator for FortiGate/FortiWiFi devices
The driver for fixed voltage regulater uses "regulator-fixed" for
compatible string, not "fixed-regulator".

Fixes: 102dc5a625 ("mvebu: add support for FortiGate 50E")
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16409
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2024-09-22 15:29:16 +02:00
Enrico Mioso
769c933069 mvebu: GL-MV1000: let u-boot-env be writable again
Allows easily changing boot media for GL-MV1000.

Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
2024-08-06 21:46:25 +02:00
Enrico Mioso
2d712021cd mvebu: enable CONFIG_MTD_SPI_NOR_USE_VARIABLE_ERASE=y config option
Enable the CONFIG_MTD_SPI_NOR_USE_VARIABLE_ERASE kernel option to allow for
U-Boot environment writing. This might be hiding a problem somewhere else,
since the w25q128fw chip supports 32K erases, still this change makes it
much easier to switch the GL-MV1000 boot media without an UART cable
connection.

Thanks to @robimarko and @hacks for the precious hints and suggesting a
better approach.

Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
2024-08-06 21:46:25 +02:00
Enrico Mioso
2aa760acd6 mvebu: GL-MV1000: add custom boot script
This allows booting from internal eMMC or SD card just changing the
U-Boot mmc_dev variable.
In particular, setting mmc_dev to 1 will result in booting from the SD card.
Setting the variable to 0 will result in internal eMMC boot (the default).
Should the variable be unset or an error condition occur while reading
from SD card, internal MMC booting will be tried.

Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
2024-08-06 21:46:25 +02:00
Marek Mojík
17ecd37c6a utils: Add the omnia-mcutool utility
Add a new utility, omnia-mcutool, which main purpose is to upgrade the
firmware on the microcontroller on the Turris Omnia router. Depends on
omnia-mcu-firmware, and the upgrade process is pretty simple:

  omnia-mcutool --upgrade

Besides firmware upgrade, the utility can be used to show and configure
various firmware settings.

Signed-off-by: Marek Mojík <marek.mojik@nic.cz>
Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://github.com/openwrt/openwrt/pull/13799
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-08-02 22:11:05 +02:00
Marek Mojík
56706d33cf firmware: Add CZ.NIC Turris Omnia MCU firmware
Add a new package, omnia-mcu-firmware, containing firmware binaries for
the microcontroller on the Turris Omnia router.

Signed-off-by: Marek Mojík <marek.mojik@nic.cz>
Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://github.com/openwrt/openwrt/pull/13799
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-08-02 22:11:05 +02:00
Marek Mojík
9129a67ec7 mvebu: Add kmod-turris-omnia-mcu
Add support for the MCU driver on CZ.NIC's Turris Omnia. This adds
the ability to do a true board poweroff, and to configure various
features (for example the user may configure that after poweroff, the
router should automatically wake up at a specific time).

Signed-off-by: Marek Mojík <marek.mojik@nic.cz>
Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://github.com/openwrt/openwrt/pull/13799
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-08-02 22:11:05 +02:00
Marek Behún
35aa38540a mvebu: 6.6: Backport Turris Omnia MCU patches from 6.11
This backports patches
  dt-bindings: firmware: add cznic,turris-omnia-mcu binding
  platform: cznic: Add preliminary support for Turris Omnia MCU
  platform: cznic: turris-omnia-mcu: Add support for MCU connected GPIOs
  platform: cznic: turris-omnia-mcu: Add support for poweroff and wakeup
  platform: cznic: turris-omnia-mcu: Add support for MCU watchdog
  platform: cznic: turris-omnia-mcu: Add support for MCU provided TRNG
  ARM: dts: turris-omnia: Add MCU system-controller node
  ARM: dts: turris-omnia: Add GPIO key node for front button
  platform: cznic: turris-omnia-mcu: Depend on OF
  platform: cznic: turris-omnia-mcu: Depend on WATCHDOG
  platform: cznic: turris-omnia-mcu: fix Kconfig dependencies
that will be released in 6.11 into mvebu/patches-6.6.

Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://github.com/openwrt/openwrt/pull/13799
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-08-02 22:11:05 +02:00
Robert Marko
d40f9ad48f mvebu: rb5009: wire SFP led by default
There is no reason not to wire up the default netdev trigger for the SFP
LED since we have a separate SFP interface visible.

Link: https://github.com/openwrt/openwrt/pull/15927
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-07-12 09:51:46 +02:00
Robert Marko
e0faad2a79 mvebu: rb5009: convert LEDs to color/function
Since we are trying to get rid of using labels, lets convert RB5009 to the
function/color combo.

Link: https://github.com/openwrt/openwrt/pull/15927
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-07-12 09:51:46 +02:00
Robert Marko
d44eb32317 mvebu: rb5009: fix QCA8081 LED polarity
Currently, QCA8081 LED is never configured and the default configuration
has the LED polarity inverted so it will be lit when there is nothing
connected to the PHY.

So lets define the LED as active-low and configure the trigger via 01_leds.

Fixes: 85d9fd6f0e ("mvebu: add support for RB5009UG+S+IN")
Link: https://github.com/openwrt/openwrt/pull/15927
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-07-12 09:51:46 +02:00
John Audia
3711557bdf kernel: bump 6.6 to 6.6.36
Changelog: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.36

Manually rebased:
        generic/hack-6.6/765-mxl-gpy-control-LED-reg-from-DT.patch
        bcm27xx/patches-6.6/950-0536-dmaengine-dw-axi-dmac-Fixes-for-RP1.patch

Removed upstreamed:
	bmips/patches-6.6/010-v6.10-mips-bmips-BCM6358-make-sure-CBR-is-correctly-set.patch[1]

All other patches automatically rebased.

1. 7c9644a7b5

Build system: x86/64
Build-tested: x86/64/AMD Cezanne, flogic/xiaomi_redmi-router-ax6000-ubootmod, ramips/tplink_archer-a6-v3
Run-tested: x86/64/AMD Cezanne, flogic/xiaomi_redmi-router-ax6000-ubootmod, ramips/tplink_archer-a6-v3

Signed-off-by: John Audia <therealgraysky@proton.me>
2024-07-04 22:07:10 +02:00
Robert Marko
85d9fd6f0e mvebu: add support for RB5009UG+S+IN
This patch adds support for Mikrotik RB5009UG+S+IN.

Specifications:
  - SoC: Marvell Armada 7040 (88F7040) - 4 cores, ARMv8 Cortex-A72, 1.4GHz, 64bit
  - RAM: 1024MB DDR4
  - Flash: 16MB SPI NOR flash, 1024MB NAND
  - Ethernet:
  	* Marvell 88E6393X - Amethyst:
  	* one 2.5G RJ45 port via Qualcomm QCA8081 PHY
  	* seven 1G RJ45 ports via built-in PHY-s
  	* one 10G SFP+ cage
  	* All ports share the same 10G switch uplink to the CPU
  - LED: User, SFP, Hdr1, Hdr2
  - Buttons: Reset
  - UART: 115200 8n1 on the MikroTik 16 pin header
  - USB: One USB3 port
  - Power: 24-57 V via
  	* DC jack
  	* 802.3af/at PoE on Ethernet 1
  	* 2-pin terminal on the side

16 Pin header pinout:
1   GND Vcc  RX  ?  GND
   #--------------------#
   |.-. .-. .-. .-. .-. |
   |'-' '-' '-' '-' '-' |
   |.-. .-. .-. .-. .-. |
   |'-' '-' '-' '-' '-' |
   #--------------------#
2   CLK  DO /CS  TX  DI

Do note that the default RouterBoot has disabled UART even when the
required hard-config bit is set to indicate UART support.
Patched RouterBoot must be used if UART is desired.

Also, since ARM64 Linux support does not support in any way appending the
DTB to the kernel image we use mainline U-Boot with added RB5009 support
in order to boot OpenWrt.
MikroTik uses YAFFS to store the boot kernel and we use YAFUT to put U-Boot
as the kernel which RouterBoot then simply boots as an ELF.

Install instructions:

NOTE: In case you are using an existing out of tree version of OpenWrt make
sure to reinstall RouterOS via Netinstall to return the expected partition
layout.

1. Prepare FAT or EXT4 formatted USB drive with OpenWrt initramfs:
* Copy bin/targets/mvebu/cortexa72/openwrt-mvebu-cortexa72-mikrotik_rb5009-initramfs-uImage.itb
to the root of FAT or EXT4 formatted USB drive.
* Plug in the drive to the RB5009 USB port

2. Boot the modified OpenWrt built U-Boot ELF:
u-boot.elf from bin/targets/mvebu/cortexa72/u-boot-rb5009/u-boot.elf

Consult OpenWrt wiki for common instructions on switching to boot from
Ethernet once as well as serving the file:
https://openwrt.org/toh/mikrotik/common

Once U-Boot is booted it will attempt to boot in the following order:
1. NAND
2. USB
3. Network

NAND is expected to fail but USB or Networking need to serve the OpenWrt
initramfs image and after booting it will be accessible from LAN ports
on the default 192.168.1.1 IP with default credentials.

3. Flash modified RouterBoot that enables UART (Optional but recommended):
https://public.robimarko.eu/RB5009/70x0-7.15-uart.fwf

* Copy the file over to the booted OpenWrt initramfs to /tmp
* Run: mtd erase RouterBOOT-primary
* Run: mtd write /tmp/70x0-7.15-uart.fwf RouterBOOT-primary

4. Install U-Boot to boot OpenWrt:
* Copy the u-boot.elf from bin/targets/mvebu/cortexa72/u-boot-rb5009/u-boot.elf
to OpenWrt initramfs to /tmp.
* Run: . /lib/functions.sh
* Run: yafut -d /dev/mtd$(find_mtd_index "YAFFS") -w -i /tmp/u-boot.elf -o kernel -T
This will use yafut to copy the U-Boot as kernel in YAFFS so that RouterBoot boots it.

5. Wipe the NAND UBI partition:
* Run: ubiformat /dev/mtd$(find_mtd_index "ubi") -y
This will prepare the existing RouterOS rootfs partition for OpenWrt.

6. Flash OpenWrt:
* Copy the bin/targets/mvebu/cortexa72/openwrt-mvebu-cortexa72-mikrotik_rb5009-squashfs-sysupgrade.bin
to OpenWrt initramfs to /tmp.
* Run: sysupgrade /tmp/openwrt-mvebu-cortexa72-mikrotik_rb5009-squashfs-sysupgrade.bin

Device will reboot, boot U-Boot and then OpenWrt.

Recovery:

In case you need to reinstall OpenWrt if it crashes after U-Boot, there is
a recovery mechanism in OpenWrt to boot the OpenWrt initramfs.
You need to hold the reset button while U-Boot is booting and then it will
boot the OpenWrt initramfs from:
1. USB
2. Networking

In recovery mode U-Boot will light all of the LED-s except for the switch
ones.

In case you want to return to RouterOS, you can simply do that via
Netinstall like on any other MikroTik board.

Credits also go to Serhii Serhieiev <adron@mstnt.com> who origininally
figured out the RouterBoot modification for UART, the missing 10G MVPP2
support in U-Boot as well as the custom aux loader to boot directly via
RouterBoot.

Link: https://github.com/openwrt/openwrt/pull/15765
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-06-24 09:46:19 +02:00
Robert Marko
b5004bac84 mvebu: cortex-a72: enable MikroTik NVMEM layout driver
RB5009 will take advantage of the driver to get MAC adress.

Link: https://github.com/openwrt/openwrt/pull/15765
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-06-24 09:46:19 +02:00
Robert Marko
62fa12e3c9 mvebu: cortex-a72: enable U-Boot NVMEM driver
In order to not have to ship envtools configuration per board, we can
instead rely on the kernel U-Boot environment NVMEM driver through which
envtools can read/write the environement.

Since size difference is negligeble and this subtarget has rather large
storage regardless, enable it by default.

Link: https://github.com/openwrt/openwrt/pull/15765
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-06-24 09:46:19 +02:00
Robert Marko
9f2b2d8dcd mvebu: cortex-a72: enable MikroTik platform drivers and NOR variable erase
MikroTik RB5009 will be using advantage of the MikroTik platform drivers,
RouterBoot partition parser and SPI NOR variable erase support.

Link: https://github.com/openwrt/openwrt/pull/15765
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-06-24 09:46:19 +02:00
Robert Marko
2b316f4e22 mvebu: cortex-a72: enable ARM SBSA Generic Watchdog
Marvell 70x0 and 80x0 both have ARM SBSA Generic Watchdog built-in,
so lets enable the required driver for them.

Link: https://github.com/openwrt/openwrt/pull/15765
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-06-24 09:46:19 +02:00
Robert Marko
8be64365c4 mvebu: cortex-a72: enable QCA8081 PHY support
MikroTik RB5009 uses Qualcomm QCA8081 PHY for the 2.5G RJ45 port,
so we need to enable the driver for it.

Link: https://github.com/openwrt/openwrt/pull/15765
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-06-24 09:46:19 +02:00
John Audia
a09a72d86d kernel: bump 6.6 to 6.6.34
Changelog: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.34

Removed upstreamed:
	backport-6.6/701-v6.8-net-sfp-bus-fix-SFP-mode-detect-from-bitrate.patch[1]

All other patches automatically rebased.

Build system: x86/64
Build-tested: x86/64/AMD Cezanne, flogic/xiaomi_redmi-router-ax6000-ubootmod, ramips/tplink_archer-a6-v3
Run-tested: x86/64/AMD Cezanne, flogic/xiaomi_redmi-router-ax6000-ubootmod, ramips/tplink_archer-a6-v3

1. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.6.34&id=9399baa02e4b7f101c39fdbc4d681d54bca4465b

Signed-off-by: John Audia <therealgraysky@proton.me>
2024-06-20 01:55:19 +02:00
Robert Marko
70088a7e4c
mvebu: uDPU/eDPU: mount F2FS with ZSTD compression
Now that we can pass the desired compression via cmdline, pass ZSTD as the
desired compression algorithm for F2FS.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
2024-06-17 20:16:20 +02:00
Robert Marko
149a1ab273
mvebu: uDPU/eDPU: mount misc partition with ZSTD compression
F2FS requires the compression algorith to be passed as argument while
mounting, so lets do so for the misc partition.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
2024-06-17 20:16:20 +02:00
Robert Marko
23191b4075
mvebu: uDPU/eDPU: format F2FS partitons with compression support
In order to prolong the eMMC life and utilize ZSTD compression on Methode
devices, we must format the F2FS rootfs and misc partition with xattr and
compression support feature flags first.

This will only happen if partitions are broken currently, but later
commits will add support to convert existing boards to use compression.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
2024-06-17 20:16:20 +02:00
Robert Marko
793b925f8b
mvebu: cortexa53: include mkfs.f2fs and fdisk for sysupgrade
Methode devices require mkfs.f2fs in order to format rootfs and misc
partitions if they have not already been formatted.
fdisk is required if partition table got broke so it can be regenerated.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
2024-06-17 20:16:19 +02:00
Robert Marko
ae358b8489
mvebu: cortexa53: enable F2FS ZSTD compression support
We would love to utilize ZSTD compression support in F2FS on the
Methode euroDPU so lets enable the required kernel support.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
2024-06-17 20:16:19 +02:00
Rosen Penev
6ff598306f
treewide: gpio to gpios
gpio is deprecated. Found with dtc's -Wdeprecated_gpio_property

Used git grep -E $'\tgpio = <' to make the changes.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/15681
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
2024-06-17 12:57:06 +02:00
Christian Marangi
37ff0ea726 mvebu: disable polling delay for passive trip point for puzzle thermal
We don't have any passive trip point hence we can set the polling delay
for passive trip to 0 effectively disabling this polling.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
2024-06-01 16:40:10 +01:00
Christian Marangi
611413cc3f mvebu: split thermal zone for puzzle chassis
Split thermal zone for puzzle chassis. Thermal platform supports only
one sensor per thermal zone.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2024-06-01 16:40:10 +01:00
Christian Marangi
e5c7b5ec43 mvebu: fix missing property in puzzle thermal
Fix missing property in puzzle thermal. The thing was never supposed to
work.

Property #thermal-sensor-cells was missing from the puzzle hwmon, making
the entire thermal platform referencing that fail to probe with -EINVAL.

The puzzle hwmon expose 2 termistor but they probably use an userspace
downstream utility to configure and handle thermal. For this reason we
really don't know what they use the sensor for or when it's attached.

We use them to sensor if the Chassis gets too hot due to ambient
temperature and generic components getting too warm.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
2024-06-01 16:40:10 +01:00
Daniel Golle
ac783b419b mvebu: improve thermal management of IEI Puzzle devices
- Make step_wise thermal governor respect hysteresis
   This is done by importing a downstream patch, backporting the same feature
   now present in Linux v6.10+ would be too messy.
 - Introduce thermal zone for the WT61P803 uC (chassis and board sensors)
 - Introduce thermal zones for AQR NBase-T PHYs
 - No longer modify existing SoC thermal zones (which are now only in charge
   for emergency shutdown, and can be interrupt driven instead of polled)

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
2024-06-01 16:40:10 +01:00
INAGAKI Hiroshi
34c875cf8b mvebu: add support for Fortinet FortiWiFi 51E
Fortinet FortiWiFi 51E (FWF-51E) is a UTM with 1x WLAN and 1x SSD, based
on Armada 385 (88F6820).

Specification:

- SoC          : Marvell Armada 385 88F6820
- RAM          : DDR3 2 GiB (4x Micron MT41K512M8DA-107, "D9SGQ")
- Flash        : SPI-NOR 128 MiB (Macronix MX66L1G45GMI-10G)
- SSD          : mSATA SSD 32 GB (A-DATA XM21E (AXM21ES3-32GM-B))
  - mode       : SATA III 6Gbps
  - power      : 3.3 VDC, 3.1 W (Max.)
- Ethernet     : 7x 10/100/1000 Mbps
  - LAN 1-5    : Marvell 88E6176
  - WAN 1, 2   : Marvell 88E1512 (2x)
- WLAN         : Fortinet EMP7618-FT (Atheros AR9382 (2T2R))
  - interface  : MiniPCIe
- LEDs/Keys    : 18x/1x
- UART         : "CONSOLE" port (RJ-45, RS-232C level)
  - port       : ttyS0
  - settings   : 9600bps 8n1
  - assignment : 1:NC , 2:NC , 3:TXD, 4:GND,
                 5:GND, 6:RXD, 7:NC , 8:NC
  - note       : compatible with Cisco console cable
- HW Monitoring: nuvoTon NCT7802Y
- Power        : 12 VDC, 2 A
  - plug       : Molex 5557-02R

Flash instruction using initramfs image:

 1. Power on FWF-51E and interrupt to show bootmenu
 2. Call "[I]: System information." -> "[S]: Set serial port baudrate."
    and set baudrate to 9600 bps
 3. Call "[R]: Review TFTP parameters.", check TFTP parameters and
    connect computer to "Image download port" in the parameters
 4. Prepare TFTP server with the parameters obtained above
 5. Rename OpenWrt initramfs image to "image.out" and put to TFTP
    directory
 6. Call "[T]: Initiate TFTP firmware transfer." to download initramfs
    image from TFTP server
 7. Type "R" key when the following message is showed, to boot initramfs
    image without flashing to spi-nor flash

    "Save as Default firmware/Backup firmware/Run image without saving:[D/B/R]?"

 8. On initramfs image, backup mtd if needed

    minimum:

    - "firmware-info"
    - "kernel"
    - "rootfs"

 9. On initramfs image, upload sysupgrade image to the device and perform
    sysupgrade
10. Wait ~200 seconds to complete flashing and rebooting.
    If the device is booted with stock firmware, login to bootmenu and
    call "[B]: Boot with backup firmware and set as default." to set the
    first OS image as default and boot it.

Notes:

- Both colors of Bi-color LEDs on the front panel cannot be turned on at
  the same time.

- "PWR" and "Logo" LEDs are connected to power source directly.

- The following partitions are added for OpenWrt.
  These partitions are contained in "uboot" partition (0x0-0x1fffff) on
  stock firmware.

  - "firmware-info"
  - "dtb"
  - "u-boot-env"
  - "board-info"

Image header for bootmenu tftp:

  0x0 - 0xf  : ?
 0x10 - 0x2f : Image Name
 0x30 - 0x17f: ?
0x180 - 0x183: Kernel Offset*
0x184 - 0x187: Kernel Length*
0x188 - 0x18b: RootFS Offset (ext2)*
0x18c - 0x18f: RootFS Length (ext2)*
0x190 - 0x193: DTB Offset
0x194 - 0x197: DTB Length
0x198 - 0x19b: Data Offset (jffs2)
0x19c - 0x19f: Data Length (jffs2)
0x1a0 - 0x1ff: ?

*: required for initramfs image

MAC addresses:

(eth0): 90:6C:AC:xx:xx:98 (board-info (OpenWrt), 0xd880 (hex))
WAN 1 : 90:6C:AC:xx:xx:99
WAN 2 : 90:6C:AC:xx:xx:9A
LAN 1 : 90:6C:AC:xx:xx:9B
LAN 2 : 90:6C:AC:xx:xx:9C
LAN 3 : 90:6C:AC:xx:xx:9D
LAN 4 : 90:6C:AC:xx:xx:9E
LAN 5 : 90:6C:AC:xx:xx:9F
WLAN  : 88:DC:96:xx:xx:xx (MiniPCIe Card)

Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Tested-by: Raylynn Knight <rayknight@me.com>
2024-05-25 20:03:00 +02:00
INAGAKI Hiroshi
26a2135c6d mvebu: add support for Fortinet FortiWiFi 50E-2R
Fortinet FortiWiFi 50E-2R (FWF-50E-2R) is a UTM with 2x WLAN, based on
Armada 385 (88F6820).

Specification:

- SoC          : Marvell Armada 385 88F6820
- RAM          : DDR3 2 GiB (4x Nanya NT5CC512M8EN-EK)
- Flash        : SPI-NOR 128 MiB (Macronix MX66L1G45GMI-10G)
- Ethernet     : 7x 10/100/1000 Mbps
  - LAN 1-5    : Marvell 88E6176
  - WAN 1, 2   : Marvell 88E1512 (2x)
- WLAN         : Gemtek WMDQ-177ACN (Qualcomm Atheros QCA9892 (2T2R))
                 (2x)
  - interface  : MiniPCIe
- LEDs/Keys    : 18x/1x
- UART         : "CONSOLE" port (RJ-45, RS-232C level)
  - port       : ttyS0
  - settings   : 9600bps 8n1
  - assignment : 1:NC , 2:NC , 3:TXD, 4:GND,
                 5:GND, 6:RXD, 7:NC , 8:NC
  - note       : compatible with Cisco console cable
- HW Monitoring: nuvoTon NCT7802Y
- Power        : 12 VDC, 2.5 A
  - plug       : Molex 5557-02R

Flash instruction using initramfs image:

 1. Power on FWF-50E-2R and interrupt to show bootmenu
 2. Call "[I]: System information." -> "[S]: Set serial port baudrate."
    and set baudrate to 9600 bps
 3. Call "[R]: Review TFTP parameters.", check TFTP parameters and
    connect computer to "Image download port" in the parameters
 4. Prepare TFTP server with the parameters obtained above
 5. Rename OpenWrt initramfs image to "image.out" and put to TFTP
    directory
 6. Call "[T]: Initiate TFTP firmware transfer." to download initramfs
    image from TFTP server
 7. Type "R" key when the following message is showed, to boot initramfs
    image without flashing to spi-nor flash

    "Save as Default firmware/Backup firmware/Run image without saving:[D/B/R]?"

 8. On initramfs image, backup mtd if needed

    minimum:

    - "firmware-info"
    - "kernel"
    - "rootfs"

 9. On initramfs image, upload sysupgrade image to the device and perform
    sysupgrade
10. Wait ~200 seconds to complete flashing and rebooting.
    If the device is booted with stock firmware, login to bootmenu and
    call "[B]: Boot with backup firmware and set as default." to set the
    first OS image as default and boot it.

Notes:

- Both colors of Bi-color LEDs on the front panel cannot be turned on at
  the same time.

- "PWR" and "Logo" LEDs are connected to power source directly.

- The following partitions are added for OpenWrt.
  These partitions are contained in "uboot" partition (0x0-0x1fffff) on
  stock firmware.

  - "firmware-info"
  - "dtb"
  - "u-boot-env"
  - "board-info"

Image header for bootmenu tftp:

  0x0 - 0xf  : ?
 0x10 - 0x2f : Image Name
 0x30 - 0x17f: ?
0x180 - 0x183: Kernel Offset*
0x184 - 0x187: Kernel Length*
0x188 - 0x18b: RootFS Offset (ext2)*
0x18c - 0x18f: RootFS Length (ext2)*
0x190 - 0x193: DTB Offset
0x194 - 0x197: DTB Length
0x198 - 0x19b: Data Offset (jffs2)
0x19c - 0x19f: Data Length (jffs2)
0x1a0 - 0x1ff: ?

*: required for initramfs image

MAC addresses:

(eth0): 90:6C:AC:xx:xx:98 (board-info (OpenWrt), 0xd880 (hex))
WAN 1 : 90:6C:AC:xx:xx:99
WAN 2 : 90:6C:AC:xx:xx:9A
LAN 1 : 90:6C:AC:xx:xx:9B
LAN 2 : 90:6C:AC:xx:xx:9C
LAN 3 : 90:6C:AC:xx:xx:9D
LAN 4 : 90:6C:AC:xx:xx:9E
LAN 5 : 90:6C:AC:xx:xx:9F
WLAN 1: 1C:49:7B:xx:xx:xx (MiniPCIe Card)
WLAN 2: 1C:49:7B:xx:xx:xx (MiniPCIe Card)

Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Tested-by: Raylynn Knight <rayknight@me.com>
2024-05-25 20:03:00 +02:00
INAGAKI Hiroshi
38d6c99dc0 mvebu: add support for Fortinet FortiGate 52E
Fortinet FortiGate 52E (FG-52E) is a UTM, based on Armada 385 (88F6820).

Specification:

- SoC          : Marvell Armada 385 88F6820
- RAM          : DDR3 2 GiB (4x Micron MT41K512M8DA-107, "D9SGQ")
- Flash        : SPI-NOR 128 MiB (Macronix MX66L1G45GMI-10G)
- SSD          : mSATA SSD 64 GB (2x A-DATA XM21E (AXM21ES3-32GM-B))
  - mode       : SATA III 6Gbps
  - power      : 3.3 VDC, 3.1 W (Max.)
- Ethernet     : 7x 10/100/1000 Mbps
  - LAN 1-5    : Marvell 88E6176
  - WAN 1, 2   : Marvell 88E1512 (2x)
- LEDs/Keys    : 18x/1x
- UART         : "CONSOLE" port (RJ-45, RS-232C level)
  - port       : ttyS0
  - settings   : 9600bps 8n1
  - assignment : 1:NC , 2:NC , 3:TXD, 4:GND,
                 5:GND, 6:RXD, 7:NC , 8:NC
  - note       : compatible with Cisco console cable
- HW Monitoring: nuvoTon NCT7802Y
- Power        : 12 VDC, 2.5 A
  - plug       : Molex 5557-02R

Flash instruction using initramfs image:

 1. Power on FG-52E and interrupt to show bootmenu
 2. Call "[I]: System information." -> "[S]: Set serial port baudrate."
    and set baudrate to 9600 bps
 3. Call "[R]: Review TFTP parameters.", check TFTP parameters and
    connect computer to "Image download port" in the parameters
 4. Prepare TFTP server with the parameters obtained above
 5. Rename OpenWrt initramfs image to "image.out" and put to TFTP
    directory
 6. Call "[T]: Initiate TFTP firmware transfer." to download initramfs
    image from TFTP server
 7. Type "R" key when the following message is showed, to boot initramfs
    image without flashing to spi-nor flash

    "Save as Default firmware/Backup firmware/Run image without saving:[D/B/R]?"

 8. On initramfs image, backup mtd if needed

    minimum:

    - "firmware-info"
    - "kernel"
    - "rootfs"

 9. On initramfs image, upload sysupgrade image to the device and perform
    sysupgrade
10. Wait ~200 seconds to complete flashing and rebooting.
    If the device is booted with stock firmware, login to bootmenu and
    call "[B]: Boot with backup firmware and set as default." to set the
    first OS image as default and boot it.

Notes:

- Both colors of Bi-color LEDs on the front panel cannot be turned on at
  the same time.

- "PWR" and "Logo" LEDs are connected to power source directly.

- The following partitions are added for OpenWrt.
  These partitions are contained in "uboot" partition (0x0-0x1fffff) on
  stock firmware.

  - "firmware-info"
  - "dtb"
  - "u-boot-env"
  - "board-info"

Image header for bootmenu tftp:

  0x0 - 0xf  : ?
 0x10 - 0x2f : Image Name
 0x30 - 0x17f: ?
0x180 - 0x183: Kernel Offset*
0x184 - 0x187: Kernel Length*
0x188 - 0x18b: RootFS Offset (ext2)*
0x18c - 0x18f: RootFS Length (ext2)*
0x190 - 0x193: DTB Offset
0x194 - 0x197: DTB Length
0x198 - 0x19b: Data Offset (jffs2)
0x19c - 0x19f: Data Length (jffs2)
0x1a0 - 0x1ff: ?

*: required for initramfs image

MAC addresses:

(eth0): 90:6C:AC:xx:xx:98 (board-info (OpenWrt), 0xd880 (hex))
WAN 1 : 90:6C:AC:xx:xx:99
WAN 2 : 90:6C:AC:xx:xx:9A
LAN 1 : 90:6C:AC:xx:xx:9B
LAN 2 : 90:6C:AC:xx:xx:9C
LAN 3 : 90:6C:AC:xx:xx:9D
LAN 4 : 90:6C:AC:xx:xx:9E
LAN 5 : 90:6C:AC:xx:xx:9F

Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
2024-05-25 20:03:00 +02:00
INAGAKI Hiroshi
d406498e1b mvebu: add support for Fortinet FortiGate 51E
Fortinet FortiGate 51E (FG-51E) is a UTM, based on Armada 385 (88F6820).

Specification:

- SoC          : Marvell Armada 385 88F6820
- RAM          : DDR3 2 GiB (4x Micron MT41K512M8DA-107, "D9SGQ")
- Flash        : SPI-NOR 128 MiB (Macronix MX66L1G45GMI-10G)
- SSD          : mSATA SSD 32 GB (A-DATA XM21E (AXM21ES3-32GM-B))
  - mode       : SATA III 6Gbps
  - power      : 3.3 VDC, 3.1 W (Max.)
- Ethernet     : 7x 10/100/1000 Mbps
  - LAN 1-5    : Marvell 88E6176
  - WAN 1, 2   : Marvell 88E1512 (2x)
- LEDs/Keys    : 18x/1x
- UART         : "CONSOLE" port (RJ-45, RS-232C level)
  - port       : ttyS0
  - settings   : 9600bps 8n1
  - assignment : 1:NC , 2:NC , 3:TXD, 4:GND,
                 5:GND, 6:RXD, 7:NC , 8:NC
  - note       : compatible with Cisco console cable
- HW Monitoring: nuvoTon NCT7802Y
- Power        : 12 VDC, 2.5 A
  - plug       : Molex 5557-02R

Flash instruction using initramfs image:

 1. Power on FG-51E and interrupt to show bootmenu
 2. Call "[I]: System information." -> "[S]: Set serial port baudrate."
    and set baudrate to 9600 bps
 3. Call "[R]: Review TFTP parameters.", check TFTP parameters and
    connect computer to "Image download port" in the parameters
 4. Prepare TFTP server with the parameters obtained above
 5. Rename OpenWrt initramfs image to "image.out" and put to TFTP
    directory
 6. Call "[T]: Initiate TFTP firmware transfer." to download initramfs
    image from TFTP server
 7. Type "R" key when the following message is showed, to boot initramfs
    image without flashing to spi-nor flash

    "Save as Default firmware/Backup firmware/Run image without saving:[D/B/R]?"

 8. On initramfs image, backup mtd if needed

    minimum:

    - "firmware-info"
    - "kernel"
    - "rootfs"

 9. On initramfs image, upload sysupgrade image to the device and perform
    sysupgrade
10. Wait ~200 seconds to complete flashing and rebooting.
    If the device is booted with stock firmware, login to bootmenu and
    call "[B]: Boot with backup firmware and set as default." to set the
    first OS image as default and boot it.

Notes:

- Both colors of Bi-color LEDs on the front panel cannot be turned on at
  the same time.

- "PWR" and "Logo" LEDs are connected to power source directly.

- The following partitions are added for OpenWrt.
  These partitions are contained in "uboot" partition (0x0-0x1fffff) on
  stock firmware.

  - "firmware-info"
  - "dtb"
  - "u-boot-env"
  - "board-info"

Image header for bootmenu tftp:

  0x0 - 0xf  : ?
 0x10 - 0x2f : Image Name
 0x30 - 0x17f: ?
0x180 - 0x183: Kernel Offset*
0x184 - 0x187: Kernel Length*
0x188 - 0x18b: RootFS Offset (ext2)*
0x18c - 0x18f: RootFS Length (ext2)*
0x190 - 0x193: DTB Offset
0x194 - 0x197: DTB Length
0x198 - 0x19b: Data Offset (jffs2)
0x19c - 0x19f: Data Length (jffs2)
0x1a0 - 0x1ff: ?

*: required for initramfs image

MAC addresses:

(eth0): 70:4C:A5:xx:xx:98 (board-info (OpenWrt), 0xd880 (hex))
WAN 1 : 70:4C:A5:xx:xx:99
WAN 2 : 70:4C:A5:xx:xx:9A
LAN 1 : 70:4C:A5:xx:xx:9B
LAN 2 : 70:4C:A5:xx:xx:9C
LAN 3 : 70:4C:A5:xx:xx:9D
LAN 4 : 70:4C:A5:xx:xx:9E
LAN 5 : 70:4C:A5:xx:xx:9F

Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Tested-by: Raylynn Knight <rayknight@me.com>
2024-05-25 20:03:00 +02:00
INAGAKI Hiroshi
f69d96a8e5 mvebu: separate common parts to new dtsi for FortiGate/FortiWiFi 5xE
Add a new dtsi which contains the common parts of Fortinet
FortiGate/FortiWiFi 5xE series devices.

Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
2024-05-25 20:03:00 +02:00
INAGAKI Hiroshi
77663df754 mvebu: separate common parts to new dtsi for FortiGate/FortiWiFi 3xE
Add a new dtsi which contains the common parts of Fortinet
FortiGate/FortiWiFi 3xE series devices.

Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
2024-05-25 20:03:00 +02:00
INAGAKI Hiroshi
73be4b9e48 mvebu: rename common dtsi of FortiGate 30E/50E
Rename the common dtsi of Fortinet FortiGate 30E/50E for the preparation
of adding support for the other FortiGate/FortiWiFi 3xE/5xE devices.

Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
2024-05-25 20:03:00 +02:00
INAGAKI Hiroshi
0618eae506 mvebu: add common image definition for FortiGate devices
Add a common definition of Fortinet FortiGate devices to
image/cortexa9.mk for a preparation of adding support for
other FortiGate 3xE/5xE devices.

Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
2024-05-25 20:02:59 +02:00