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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
- 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>
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>
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>
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>
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>
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>
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>
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>
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>
Update default kernel version to 6.6 and drop configs and patches for
kernel 6.1. We can also omit the conditional to include DTS dir.
Signed-off-by: Stefan Kalscheuer <stefan@stklcode.de>
Link: https://github.com/openwrt/openwrt/pull/15449
Signed-off-by: Robert Marko <robimarko@gmail.com>
On IIJ SA-W2, some multiple LEDs have no "function" property and only
"color" property is available for the newer binding of LED on Linux
Kernel.
9d93b6d091 ("mvebu: drop redundant label with new LED color/function
format") removes "label" property from LEDs, then, multiple "<color>:"
(ex.: "green:"/"red:") will be appeared and renamed to "<color>:_<num>"
(ex.: "green:_1", "green:_2", ...) by kernel.
log:
[ 1.911118] leds-gpio leds: Led green: renamed to green:_1 due to name collision
[ 1.918600] leds-gpio leds: Led red: renamed to red:_1 due to name collision
[ 1.925727] leds-gpio leds: Led green: renamed to green:_2 due to name collision
[ 1.933202] leds-gpio leds: Led red: renamed to red:_2 due to name collision
[ 1.940321] leds-gpio leds: Led green: renamed to green:_3 due to name collision
[ 1.947797] leds-gpio leds: Led red: renamed to red:_3 due to name collision
[ 1.954939] leds-gpio leds: Led green: renamed to green:_4 due to name collision
[ 1.962456] leds-gpio leds: Led green: renamed to green:_5 due to name collision
/sys/class/leds:
root@OpenWrt:/# ls /sys/class/leds/
green: green:_3 green:status red:_2
green:_1 green:_4 red: red:_3
green:_2 green:_5 red:_1 red:status
Fix this issue by adding missing "function" (and "function-enumerator")
property to those LEDs on IIJ SA-W2.
Fixes: 9d93b6d091 ("mvebu: drop redundant label with new LED color/function format")
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
On Fortinet FortiGate 30E/50E, some multiple LEDs have no "function"
property and only "color" property is available for the new binding of
LED on Linux Kernel.
9d93b6d091 ("mvebu: drop redundant label with new LED color/function
format") removes "label" property from LEDs, then, multiple "<color>:"
(ex.: "green:"/"red:"/"amber:") will be appeared as LED names and
renamed to "<color>:_<num>" (ex.: "green:_1", "green:_2", ...) by
kernel.
log:
[ 12.425170] leds-gpio gpio-leds: Led green: renamed to green:_1 due to name collision
[ 12.520390] leds-gpio gpio-leds: Led amber: renamed to amber:_1 due to name collision
[ 12.614931] leds-gpio gpio-leds: Led green: renamed to green:_2 due to name collision
[ 12.709895] leds-gpio gpio-leds: Led green: renamed to green:_3 due to name collision
[ 12.804439] leds-gpio gpio-leds: Led amber: renamed to amber:_2 due to name collision
[ 12.898969] leds-gpio gpio-leds: Led green: renamed to green:_4 due to name collision
[ 12.993504] leds-gpio gpio-leds: Led amber: renamed to amber:_3 due to name collision
[ 13.088033] leds-gpio gpio-leds: Led green: renamed to green:_5 due to name collision
[ 13.182570] leds-gpio gpio-leds: Led green: renamed to green:_6 due to name collision
[ 13.277103] leds-gpio gpio-leds: Led amber: renamed to amber:_4 due to name collision
[ 13.371636] leds-gpio gpio-leds: Led green: renamed to green:_7 due to name collision
/sys/class/leds:
root@OpenWrt:/# ls /sys/class/leds/
amber: amber:_4 green:_2 green:_6 red:alarm
amber:_1 amber:alarm green:_3 green:_7 red:status
amber:_2 green: green:_4 green:status
amber:_3 green:_1 green:_5 red:
Fix this issue by adding missing "function" (and "function-enumerator")
property those to LEDs on Fortinet FortiGate devices.
Note: there is no appropriate function for "ha" LEDs in
dt-bindings/leds/common.h, so use the hardcoded string for them instead.
Fixes: 9d93b6d091 ("mvebu: drop redundant label with new LED color/function format")
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
The sysupgrade formware of the Puzzle series is a slightly strange
dual-boot approach while remaining compatible with Marvell's SDK
firmware upgrade binary format -- which happens to be a full-disk
image with GPT partition table. Hence that /lib/upgrade/emmc-puzzle.sh
script is like an exotic disease which results from those decisions,
and as we also want to somehow stay compatible with the IEI-World
stock firmware we got to use it in that same way (we are not
compatible with the QNAP-branded identical hardware device anyway).
Currently, on sysupgrade the result is that one ends up with the old
content of rootfs_data (a GPT partition on those devices) as nothing
ever wipes or in any way re-creates the filesystem there. As a simple
work-around, let's kill the filesystem on rootfs_data so fstools
re-formats it on the next boot.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
With 6.6, all DTSes were moved to their vendor subdirectories. ARM64
DTSes already used this scheme, but 32 bit Cortex A9 did not, prior
to 6.6. Introduce a kernel version check to keep backward compatibility
with 6.1.
Suggested-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Stijn Segers <foss@volatilesystems.org>
As of 6.6, all upstream DTSes are moved to their respective vendor subdir.
OpenWrt already followed this practice for ARM64, but not yet for 32 bit
ARM (Armada 37x/38x).
Signed-off-by: Stijn Segers <foss@volatilesystems.org>
DTS paths for 32 bit ARM devices changed with 6.6, move files/ to
files-6.1 to prep for kernel 6.6 introduction.
Signed-off-by: Stijn Segers <foss@volatilesystems.org>
* have more defined PWM steps similar to the vendor's shell script doing
the same thing
* replace PWM values with experiencal values provided by forum users
* increase hyteresis to prevent changing fan speed every second
(just because it's annoying to listen to)
* add 'hot' trip point at 75 deg. to warn users that shutdown is imminent
Tested on Puzzle M902 only for now, PWM values for Puzzle M901 might be
slightly different but should quite certainly also be rised.
Suggested-by: Martin Gierschner <martin_gierschner@gmx.de>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
