aboutsummaryrefslogtreecommitdiff
path: root/target/linux/mvebu/cortexa9
Commit message (Collapse)AuthorAge
* mvebu: 6.6: copy files, patches & configs from 6.1Stijn Segers2024-04-03
| | | | | | Copy all mvebu 6.1 specific files, patches and configs to 6.1. Signed-off-by: Stijn Segers <foss@volatilesystems.org>
* mvebu: drop kernel 5.15 config and patchesStefan Kalscheuer2024-02-18
| | | | | | With default now being at 6.1 we can remove all 5.15 components. Signed-off-by: Stefan Kalscheuer <stefan@stklcode.de>
* mvebu: add support for Synology DS213jDaniel Golle2023-11-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Synology DS213j is a rather dated dual-bay SATA NAS based on on the Marvell Armada-370 SoC. It has long been supported in vanilla Linux, however, flash partitioning there didn't match with reality (ie. the bootloaders expectations) and nobody cared to wrap up OpenWrt support for the device. CPU: Marvell Armada-370 ARMv7 SoC @ 1200 MHz RAM: 512 MB DDR3 Flash: 8 MB (Micron Technology N25Q064) Network: 1x 1000M/100M/10M Ethernet (Marvell 88E1510) SATA: 2x 3.0Gbps USB: 2x USB 2.0 As OS options are becoming limited on that still quite useful hardware, patch the flash partitions to be able to get the most out of it when using OpenWrt. The vendor firmware loads kernel and initrd from fixed addresses in the flash, not making use of a modifyable environment stored in flash which is stored at a location right in the middle of the vendor's zImage partition (at 0x100000). Stock firmware flash layout: 0x000000 ~ 0x0c0000 : "RedBoot" (actually U-Boot) 0x0c0000 ~ 0x390000 : "zImage" 0x390000 ~ 0x7d0000 : "rd.gz" 0x7d0000 ~ 0x7e0000 : "vendor" (contains MAC address, serial no) 0x7e0000 ~ 0x7f0000 : "RedBoot Config" (unused? legacy left-over) 0x7f0000 ~ 0x800000 : "FIS directory" (unused? legacy left-over) OpenWrt flash layout: 0x000000 ~ 0x0c0000 : "u-boot" 0x0c0000 ~ 0x100000 : "gap" 0x100000 ~ 0x110000 : "u-boot-env" 0x110000 ~ 0x7d0000 : "kernel" 0x7d0000 ~ 0x7e0000 : "vendor" (contains MAC address, serial no) 0x7e0000 ~ 0x800000 : "gap2" "kernel", "gap" and "gap2" are concatenated using the mtd-concat virtual MTD driver, resulting in a partition "firmware" used by OpenWrt for kernel, rootfs and rootfs-overlay, 0x720000 (7296kiB) in total. Installation: 1. Connect to internal serial console port and Ethernet port, providing a TFTP server at a static IPv4 address, e.g. 192.168.1.254/24. 2. Interrupt bootloader using CTRL+C 3. Configure bootloader to load OpenWrt on future boot: setenv bootcmd "bootm f4110000" saveenv 4. Load and boot initramfs image via TFTP: setenv ipaddr 192.168.1.1 setenv serverip 192.168.1.254 tftpboot openwrt-mvebu-cortexa9-synology_ds213j-initramfs-kernel.bin bootm 5. Use sysupgrade to load final image. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* mvebu: add support for IIJ SA-W2INAGAKI Hiroshi2023-10-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Internet Initiative Japan Inc. (IIJ) SA-W2 is a network appliance with 11ac (Wi-Fi 5) wlan, based on 88F6810. Specification: - SoC : Marvell Armada 380 88F6810 - RAM : DDR3 256 MiB (Micron MT41K64M16TW-107:J x2) - Flash : SPI-NOR 32 MiB (Winbond W25Q256JVFIQ) - WLAN : 2.4/5 GHz, Mini PCI-E - 2.4 GHz : Silex SX-PCEGN (Atheros AR9287 (2T2R)) - 5 GHz : Silex SX-PCEAC (Qualcomm Atheros QCA9880 (3T3R)) - Ethernet : 10/100/1000 Mbps x5 - Switch : Marvell 88E6172 - LEDs/Keys : 12x/1x - UART : "CONSOLE" port (RJ-45, RS-232C) - settings : 115200n8 - assignment: 1:NC, 2:NC, 3:TXD, 4:GND, 5:GND, 6:RXD, 7:NC, 8:NC - note : compatible with Cisco console cable - Power : DC Input or PoE - DC Input : 12 VDC, 3 A - PoE : 802.3af - module : Silvertel Ag9712-2BR - note : USB ports shouldn't be used when powered by PoE - Bootloader : PMON2000 based - Stock : NetBSD based Flash instruction using sysupgrade image: 1. Prepare TFTP server with IP address 192.168.0.10 and put sysupgrade image to TFTP directory 2. Connect PC to "GE0/PoE" port on SA-W2 3. Power on SA-W2, interrupt count-down by Esc and enter to bootloader CLI 4. Set IP address of the device address 192.168.0.1 5. Download sysupgrade image and flash to storage tftpload 192.168.0.10 <image name> firmwrite example: #tftpload 192.168.0.10 openwrt-mvebu-cortexa9-iij_sa-w2-squashfs-sysupgrade.bin Loading openwrt-mvebu-cortexa9-iij_sa-w2-squashfs-sysupgrade.bin loaded 8127268 byte(s) #firmwrite Erasing FLASH block 32 Done 0x00200000. Erasing FLASH block 33 Done 0x00210000. ... Erasing FLASH block 155 Done 0x009b0000. Erasing FLASH block 156 Done 0x009c0000. Programming FLASH. Done. Verifying FLASH. No Errors found. 6. Check the flashed firmware firmcheck example: #firmcheck [Normal firmware] ident: 'SEIL2015' copyright: 'ARM OpenWrt Linux-5.15.93' version format: 1 version major: 9 version minor: 99 version release: 'r22060+36-5163bb5e54' body size: 3578524 checksum: 0x8a083cb8 [Rescue firmware] ident: 'SEIL2015' copyright: 'Copyright (c) 2017 Internet Initiative Japan Inc. All rights reserved.' version format: 1 version major: 3 version minor: 70 version release: 'Release' body size: 10152458 checksum: 0x8f9518c2 7. Boot with the flashed firmware boot Note: - The bootloader on this device is not U-Boot and it's environment space ("bootloader-env") has no compatibility with U-Boot tools. - eth1 is connected to port6 of 88E6172 switch, but multi-cpu port can't be handled on Linux Kernel and not defined. - Powering by PoE hasn't been tested yet. - This device has 2x OS images on flash and they can be switched by setting "BOOTDEV" variable on bootloader CLI. That variable supports the following values: - "flash" : primary image on flash ("firmware") - "rescue": secondary image on flash ("rescue") - "usb" : usb storage (broken?) - "lan0/1": network command to set: set BOOTDEV=<dev> example: set BOOTDEV=rescue This commit also supports booting from secondary partition. - To execute initramfs image on bootloader CLI, use "go" command. ("go" command is not listed on the output of "help", but available) example (download and execute): address 192.168.0.1 tftpload 192.168.0.10 openwrt-mvebu-cortexa9-iij_sa-w2-initramfs-kernel.bin go MAC addresses: LAN : 00:E0:4D:xx:xx:19 (none) WAN : 00:E0:4D:xx:xx:18 (board_info, 0x6 (hex)) 2.4 GHz: 84:25:3F:xx:xx:xx (Mini PCI-E card) 5 GHz : 84:25:3F:xx:xx:xx (Mini PCI-E card) Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
* mvebu: cortexa9: enable seil-fw mtdsplit driverINAGAKI Hiroshi2023-10-31
| | | | | | Enable seil-fw driver on mvebu/cortexa9 to use it on IIJ SA-W2. Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
* mvebu: add support for Fortinet FortiGate 30EINAGAKI Hiroshi2023-10-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fortinet FortiGate 30E (FG-30E) is a UTM, based on Armada 385 (88F6820). Specification: - SoC : Marvell Armada 385 88F6820 - RAM : DDR3 1 GiB (4x Micron MT41K256M8DA-125, "D9PSH") - Flash : SPI-NOR 128 MiB (Macronix MX66L1G45GMI-10G) - Ethernet : 5x 10/100/1000 Mbps - Switch : Marvell 88E6176 - LEDs/Keys : 16x/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 : Modex 5557-02R Flash instruction using initramfs image: 1. Power on FG-30E 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:CE (board-info, 0xd880 (hex)) WAN : 70:4C:A5:xx:xx:CF LAN 1 : 70:4C:A5:xx:xx:D0 LAN 2 : 70:4C:A5:xx:xx:D1 LAN 3 : 70:4C:A5:xx:xx:D2 LAN 4 : 70:4C:A5:xx:xx:D3 Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
* mvebu: refresh 6.1 configsTomasz Maciej Nowak2023-09-08
| | | | | | | This should be a part of kernel major bump. Fortunately it didn't stall compilation, so no fixes tag. Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
* mvebu: copy 5.15 kconfigs to 6.1Stefan Kalscheuer2023-08-02
| | | | | | Start 6.1 migration with a full copy of the current stable config. Signed-off-by: Stefan Kalscheuer <stefan@stklcode.de>
* mvebu: remove hack for Turris Omnia legacy U-BootKlaus Kudielka2023-06-01
| | | | | | | | | | The omnia-medkit (only useful for installation with U-Boot 2015.10-rc2) is not being built anymore. Now we can be reasonably sure, that there won't be first-time OpenWrt boots with that U-Boot version, and can get rid of a rather ugly hack. Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
* mvebu: use PHY LED trigger for speed LEDs on FortiGate 50EINAGAKI Hiroshi2023-05-18
| | | | | | | | | | | | | Use <mdio>:<addr>:<speed> trigger instead of netdev(link) trigger for Fortinet FortiGate 50E, to indicate link speed on the each phys. 1000 Mbps: Green 100 Mbps : Amber 10 Mbps : (turn off) Fixes: 102dc5a62506 ("mvebu: add support for Fortinet FortiGate 50E") Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
* mvebu: cortexa9: enable Ethernet PHY LED triggerINAGAKI Hiroshi2023-05-18
| | | | | | | To use <mdio>:<addr>:<speed> trigger for LEDs, enable PHY LED trigger (CONFIG_LED_TRIGGER_PHY). Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
* treewide: remove files for building 5.10 kernelNick Hainke2023-05-12
| | | | | | | | | | | All targets are bumped to 5.15. Remove the old 5.10 patches, configs and files using: find target/linux -iname '*-5.10' -exec rm -r {} \; Further, remove the 5.10 include. Signed-off-by: Nick Hainke <vincent@systemli.org>
* mvebu: cortexa9: fix Linksys upgrade, restore config stepMichael Trinidad2023-04-11
| | | | | | | | | | | | It appears that the refactor of the upgrade process for NAND devices resulted in the nand_do_upgrade_success step not being called for devices using the linksys.sh script. As a result, configuration was not preserved over sysupgrade steps. This restores the preservation of configs for mvebu/cortexa9 devices using the linksys.sh script. Fixes: e25e6d8e5407 ("base-files: fix and clean up nand sysupgrade code") Signed-off-by: Michael Trinidad <trinidude4@hotmail.com>
* mvebu: add support for Fortinet FortiGate 50EINAGAKI Hiroshi2023-03-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fortinet FortiGate 50E (FG-50E) 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) - 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 A - plug : Molex 5557-02R Flash instruction using initramfs image: 1. Power on FG-50E and interrupt to show bootmenu 2. Call "[R]: Review TFTP parameters.", check TFTP parameters and connect computer to "Image download port" in the parameters 3. Prepare TFTP server with the parameters obtained above 4. Rename OpenWrt initramfs image to "image.out" and put to TFTP directory 5. Call "[T]: Initiate TFTP firmware transfer." to download initramfs image from TFTP server 6. 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]?" 7. On initramfs image, backup mtd if needed minimum: - "firmware-info" - "kernel" - "rootfs" 7. On initramfs image, upload sysupgrade image to the device and perform sysupgrade 8. 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: - All "SPEED" LEDs(Green/Amber) of LAN and 1000M "SPEED" LEDs(Green) of WAN1/2 are connected to GPIO expander. There is no way to indicate link speed of networking device on Linux Kernel/OpenWrt, so those LEDs cannot be handled like stock firmware. On OpenWrt, use netdev(link) trigger instead. - 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:7C (board-info, 0xd880 (hex)) WAN 1 : 70:4C:A5:xx:xx:7D WAN 2 : 70:4C:A5:xx:xx:7E LAN 1 : 70:4C:A5:xx:xx:7F LAN 2 : 70:4C:A5:xx:xx:80 LAN 3 : 70:4C:A5:xx:xx:81 LAN 4 : 70:4C:A5:xx:xx:82 LAN 5 : 70:4C:A5:xx:xx:83 Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
* mvebu: add support for Buffalo LinkStation LS220DEDaniel González Cabanelas2023-02-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Buffalo LinkStation LS220DE is a dual bay NAS, based on Marvell Armada 370 Hardware: SoC: Marvell Armada 88F6707 CPU: Cortex-A9 800 MHz, 1 core Flash 1: SPI-NOR 1 MiB (U-Boot) Flash 2: NAND 512 MiB (OS) RAM: DDR3 256 MiB Ethernet: 1x 1GbE USB: 1x 2.0 SATA: 2x 3Gb/s LEDs/Input: 5x / 2x (1x button, 1x slide-switch) Fan: 1x casing Flash instructions, from hard drive: 1. Get access to the "boot" partition at the hard drive where the stock firmware is installed. It can be done with acp-commander or by plugging the hard drive to a computer. 2. Backup the stock uImage: mv /boot/uImage.buffalo /boot/uImage.buffalo.bak 3. Move and rename the Openwrt initramfs image to the boot partition: mv openwrt-initramfs-kernel.bin /boot/uImage.buffalo 4. Power on the Linkstation with the hardrive inside. Now Openwrt will boot, but still not installed. 5. Connect via ssh to OpenWrt: ssh root@192.168.1.1 6. Rename boot files inside boot partition mount -t ext3 /dev/sda1 /mnt mv /mnt/uImage.buffalo /mnt/uImage.buffalo.openwrt.bak mv /mnt/initrd.buffalo /mnt/initrd.buffalo.bak 7. Format ubi partitions at the NAND flash ("kernel_ubi" and "ubi"): ubiformat /dev/mtd0 -y ubidetach -p /dev/mtd1 ubiformat /dev/mtd1 -y 8. Flash the sysupgrade image: sysupgrade -n openwrt-squashfs-sysupgrade.bin 9. Wait until it finish, the device will reboot with OpenWrt installed on the NAND flash. Restore the stock firmware: 1. Take the hard drive used for the installation and restore boot backup files to their original names: mount -t ext3 /dev/sda1 /mnt mv /mnt/uImage.buffalo.bak /mnt/uImage.buffalo mv /mnt/initrd.buffalo.bak /mnt/initrd.buffalo 2. Boot from the hard drive and perform a stock firmware update using the Buffalo utility. The NAND will be restored to the original state. Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
* treewide: replace /sys/devices/virtual/ubi by /sys/class/ubiDaniel Golle2023-02-15
| | | | | | | | | | Starting from Linux Kernel version 6.3 UBI devices will no longer be considered virtual, but rather have an MTD device parent. Hence they will no longer be listed under /sys/devices/virtual/ubi which is used in multiple places in OpenWrt. Prepare for future kernels by using /sys/class/ubi instead of /sys/devuces/virtual/ubi. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* mvebu: copy 5.10 kconfigs to 5.15Rui Salvaterra2022-08-16
| | | | | | Will be refreshed/updated later. Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
* generic: enable CRYPTO_LIB_BLAKE2S[_X86|_ARM]Tomasz Maciej Nowak2022-06-24
| | | | | | | | | | | | This is now built-in, enable so it won't propagate on target configs. Link: https://lkml.org/lkml/2022/1/3/168 Fixes: 79e7a2552e89 ("kernel: bump 5.15 to 5.15.44") Fixes: 0ca93670693b ("kernel: bump 5.10 to 5.10.119") Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com> (Link to Kernel's commit taht made it built-in, CRYPTO_LIB_BLAKE2S[_ARM|_X86] as it's selectable, 5.10 backport) Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* target/linux: replace egrep with grep -ERosen Penev2022-02-07
| | | | | | | egrep is deprecated and replaced by grep -E. The latter is used throughout the tree. Signed-off-by: Rosen Penev <rosenp@gmail.com>
* mvebu: add support for ipTIME NAS1dualSungbo Eo2022-01-29
| | | | | | | | | | | | | | | | | | | | | | | | ipTIME NAS1dual is a 1-bay NAS, based on Marvell Armada 385 SoC. Specifications: * SoC: 88F6820 * RAM: 2 GiB * Flash: SPI NOR 64 MiB * SATA: 1x 3Gb/s * Ethernet: 2x 1GbE * USB: 1x 3.0 * Fan: 2 speed level * UART: J11 (115200 8N1) * Pinout: [3V3] (TXD) (RXD) (GND) Installation via web interface: 1. Flash **initramfs** image through the stock web interface. 2. Boot into OpenWrt and perform sysupgrade with sysupgrade image. Revert to stock firmware: 1. Perform sysupgrade with stock image. Signed-off-by: Sungbo Eo <mans0n@gorani.run>
* mvebu: cortexa9: Fix board.d/01_ledsKlaus Kudielka2022-01-18
| | | | | | | Fix syntax error in the case statement Fixes: 9149ed4f05f8 ("mvebu: cortexa9: Add support for Ctera C200-V2") Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
* mvebu: Move cortexa9 specific config options from global configMarek Behún2022-01-15
| | | | | | | | | | | Move config options CONFIG_PHY_MVEBU_A38X_COMPHY CONFIG_RTC_DRV_MV to cortexa9/config-5.10. These are not needed for arm64 targets. Signed-off-by: Marek Behún <kabel@kernel.org>
* mvebu: cortexa9: Add support for Ctera C200-V2Pawel Dembicki2022-01-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2-Bay NAS - maximum two 3.5" Harddisks Hardware: - SoC: Marvell 88F6707-A1 ARMv7 Processor 1,2GHz (ARMADA 370 SoC) - Ram: 1GB (2x Nanya NT5CC512M8DN-D1) - NAND Flash: 256MB (ESMT F59L2G81A-25T) - Lan: 1x GBE (Marvell 88E1318-NNB2) - Storage: 2x SATA HDD 3.5" Slot - USB: 2x USB 3.0 port (Renesas uPD720202) - Console: Internal J3 connector (1: Vcc, 2: Rx, 3: Tx, 4: GND) - LEDs: 13x GPIO controlled - Buttons: 2x GPIO controlled Known issues: - Buzzer is unused due lack of proper driver - USB1/2 usbport ledtrigger won't work (through DT) - Renesas uPD720202 requires firmware file. It's possible to find non-free binary. Please look for 'UPDATE.mem' file and put in into '/lib/firmware/renesas_usb_fw.mem' file. Installation: - Apply factory initramfs image via stock web-gui. - Do sysupgrade to make installation complete. Back to stock: - OpenWrt rootfs partition use unused space after stock firmware. - Full revert is possible. - Login via ssh and run: ## ctera_c200-v2_back_to_factory start ## . /lib/functions.sh part=$(find_mtd_part "active_bank") active_bank=$(strings "$part" | grep bank) if [ "$active_bank" = "bank1" ]; then echo "bank2" > /tmp/change_bank else echo "bank1" > /tmp/change_bank fi mtd write /tmp/change_bank active_bank reboot ## ctera_c200-v2_back_to_factory end ## Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com> (put back-to-stock script into commit message, removed dup. SUBPAGESIZE var, added 01_leds for non-working dt-usb-port trigger) Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
* mvebu: sysupgrade: drop unnecessary UBI to UBI logicBjørn Mork2021-12-03
| | | | | | | | | | | | | | | | | | The recent changes to the maximum kernel size for Mamba and Venom highlighted the fact that the old Mamba kernel size has been hardcoded in linksys_get_root_magic() even for devices with a different kernel/rootfs split. The purpose of this code seems to be to avoid issues caused by partially overwriting an existing UBI partition, where some of the erase counters would be reset but not the unmodified ones. This problem has been solved in a more generic way by the UBI EOF marker. This ensures that any old PEBs after the marker are properly initialized. It is therefore unnecessary to erase the whole partition before flashing a new OpenWrt factory image. Signed-off-by: Bjørn Mork <bjorn@mork.no>
* base-files: rename 'sdcard' to 'legacy-sdcard'Daniel Golle2021-08-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While an image layout based on MBR and 'bootfs' partition may be easy to understand for users who are very used to the IBM PC and always have the option to access the SD card outside of the device (and hence don't really depend on other recovery methods or dual-boot), in my opinion it's a dead end for many desirable features on embedded systems, especially when managed remotely (and hence without an easy option to access the SD card using another device in case things go wrong, for example). Let me explain: * using a MSDOS/VFAT filesystem to store kernel(s) is problematic, as a single corruption of the bootfs can render the system into a state that it no longer boots at all. This makes dual-boot useless, or at least very tedious to setup with then 2 independent boot partitions to avoid the single point of failure on a "hot" block (the FAT index of the boot partition, written every time a file is changed in bootfs). And well: most targets even store the bootloader environment in a file in that very same FAT filesystem, hence it cannot be used to script a reliable dual-boot method (as loading the environment itself will already fail if the filesystem is corrupted). * loading the kernel uImage from bootfs and using rootfs inside an additional partition means the bootloader can only validate the kernel -- if rootfs is broken or corrupted, this can lead to a reboot loop, which is often a quite costly thing to happen in terms of hardware lifetime. * imitating MBR-boot behavior with a FAT-formatted bootfs partition (like IBM PC in the 80s and 90s) is just one of many choices on embedded targets. There are much better options with modern U-Boot (which is what we use and build from source for all targets booting off SD cards), see examples in mediatek/mt7622 and mediatek/mt7623. Hence rename the 'sdcard' feature to 'legacy-sdcard', and prefix functions with 'legacy_sdcard_' instead of 'sdcard_'. Tested-by: Stijn Tintel <stijn@linux-ipv6.be> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* mvebu: switch to generic sdcard upgrade methodStijn Tintel2021-08-07
| | | | | | | Now that we have a generic sdcard upgrade method, which was copied from the mvebu platform method, we can switch mvebu to the generic method. Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
* treewide: remove "+" sign for increment with macaddr_addAdrian Schmutzler2021-06-05
| | | | | | | | | | | | Many people appear to use an unneeded "+" prefix for the increment when calculating a MAC address with macaddr_add. Since this is not required and used inconsistently [*], just remove it. [*] As a funny side-fact, copy-pasting has led to almost all hotplug.d files using the "+", while nearly all of the 02_network files are not using it. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: venom resize kernel to 6MBTad Davanzo2021-03-19
| | | | | | | | | | | | | | | | | | | | | | | venom has a 3MB kernel partition as specified by the DTS. 3MB is not sufficient for building with many kernel modules or newer kernel versions. venom uboot however as set from factory will load up to 6MB. This can be observed by looking a uboot log: NAND read: device 0 offset 0x900000, size 0x600000 6291456 bytes read: OK and from uboot environment variables: $ fw_printenv | grep "priKernSize"; priKernSize=0x0600000 Resize the root partitions from 120MB to 117MB to let kernel expand into it another 3MB. And set kernel target size to 6MB. Lastly set the kernel-size-migration compatibility version on venom to prevent sysupgrading without first reinstalling from a factory image. Signed-off-by: Tad Davanzo <tad@spotco.us>
* mvebu: mamba resize kernel to 4MBTad Davanzo2021-03-19
| | | | | | | | | | | | | | | | | | | | | | | | mamba has a 3MB kernel partition as specified by the DTS. 3MB is not sufficient for building with many kernel modules or newer kernel versions. mamba uboot however as set from factory will load up to 4MB. This can be observed by looking a uboot log: NAND read: device 0 offset 0xa00000, size 0x400000 4194304 bytes read: OK and from uboot environment variables: $ fw_printenv | grep "pri_kern_size"; pri_kern_size=0x400000 Resize the root partitions from 37MB to 36MB to let kernel expand into it another 1MB. And set kernel target size to 4MB. Lastly add a compatibility version message: kernel-size-migration. And set it on mamba to prevent sysupgrading without first reinstalling from a factory image. Signed-off-by: Tad Davanzo <tad@spotco.us>
* treewide: remove execute bit and shebang from board.d filesAdrian Schmutzler2021-03-06
| | | | | | | | | | | | | | | | So far, board.d files were having execute bit set and contained a shebang. However, they are just sourced in board_detect, with an apparantly unnecessary check for execute permission beforehand. Replace this check by one for existance and make the board.d files "normal" files, as would be expected in /etc anyway. Note: This removes an apparantly unused '#!/bin/sh /etc/rc.common' in target/linux/bcm47xx/base-files/etc/board.d/01_network Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* target: use SPDX license identifiers on MakefilesAdrian Schmutzler2021-02-10
| | | | | | Use SPDX license tags to allow machines to check licenses. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: sysupgrade: use v function for writing logsTomasz Maciej Nowak2020-12-01
| | | | | | Sync with x86 target changes. Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
* mvebu: fixup Turris Omnia U-Boot environmentKlaus Kudielka2020-11-27
| | | | | | | | | | | | | | 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>
* mvebu: base-files: move additional files to subtargetsTomasz Maciej Nowak2020-11-25
| | | | | | | Both of these scripts are only relevant to cortexa9, therefore move them there. Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
* mvebu: Correct regulatory country of WRT3200ACMKabuli Chana2020-10-11
| | | | | | | | | | correct oversight on setting regulatory country and mac address of wireless configuration change method of retrieving mac address The MAC address for eth0 is rad out of the devinfo partition in some other initial configuration script already. Signed-off-by: Kabuli Chana <newtownBuild@gmail.com>
* mvebu: add wrt3200acm to 03_wireless CCKabuli Chana2020-10-11
| | | | | | | | | correct device CC oversight Set the initial wifi configuration like for the other similar Linksys devices. Signed-off-by: Kabuli Chana <newtownBuild@gmail.com>
* treewide: revert sysupgrade adjustments for early DSA-adoptersAdrian Schmutzler2020-09-08
| | | | | | | | | | | | | | | | | The uci-default mechanism to update the compat-version was only meant for early DSA-adopters, which should have updated by now. Remove this workaround again in order to prevent the intended experiences for all the other people. This reverts: a9703db72030 ("mvebu: fix sysupgrade experience for early DSA-adopters") 86c89bf5e8f5 ("kirkwood: fix sysupgrade experience for early DSA-adopters") Partially reverted: 1eac573b5304 ("ramips: mt7621: implement compatibility version for DSA migration") Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: fix sysupgrade experience for early DSA-adoptersAdrian Schmutzler2020-08-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* mvebu: fix alphabetic sorting in 02_networkAdrian Schmutzler2020-07-31
| | | | | | This has been overlooked when removing solidrun,clearfog-a1 entry. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: increase compat version for SolidRun ClearFog BaseAdrian Schmutzler2020-07-31
| | | | | | | | | | | | | When changing the Pro variant to DSA, the ethernet interface rename script was dropped by all devices to keep them in sync: be309bfd7445 ("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>
* mvebu: implement compatibility version for DSA migrationAdrian Schmutzler2020-07-31
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* mvebu: add Kobol Helios 4 deviceAlberto Bursi2020-07-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* mvebu: remove non-existant board name solidrun,clearfog-a1Adrian Schmutzler2020-06-28
| | | | | | | | | | | | | | 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: 12795ec9f16b ("mvebu: split interface configuration for clearfog pro and base") Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: fix default EU regdomain for Linksys WRT AC devicesJose Olivera2020-06-23
| | | | | | | | | | | | | | | | | | | | | 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: https://github.com/kaloz/mwlwifi/commit/0a550312ddb5a9e00e8d602d5571598f25a78158 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>
* treewide: drop shebang from non-executable target filesAdrian Schmutzler2020-06-16
| | | | | | | | | | | | | | 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>
* mvebu: rename Linksys devices based on their common namesPaul Spooren2020-06-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* mvebu: drop 06_set_iface_mac preinit scriptDENG Qingfang2020-06-03
| | | | | | | | 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>
* mvebu: use ucidef to set up MAC addressDENG Qingfang2020-06-03
| | | | | | Use ucidef to set up MAC address instead of preinit script Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
* mvebu: update default config for DSADENG Qingfang2020-06-03
| | | | | | | | 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>
* mvebu: add support for Buffalo LinkStation LS421DEDaniel González Cabanelas2020-04-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>