aboutsummaryrefslogtreecommitdiffstats
path: root/target
Commit message (Collapse)AuthorAgeFilesLines
* x86: add support for AWS T3 instancesAlberto Bursi2021-03-013-2/+20
| | | | | | | | | | | | | | | | | Amazon AWS T3 cloud instances require kernel support for the Elastic Fabric Adapter to access storage and for Elastic Network Adapter to use network interfaces. Since the Fabric Adapter is needed to access root filesystem, enable in x86_64 kernel. Elastic Network Adapter goes in a module, and add this module to default list in x86_64. The module is set to AutoLoad because AutoProbe does not seem to load it. Signed-off-by: Alberto Bursi <bobafetthotmail@gmail.com>
* ramips: fix partition layout of hiwifi hc5x61Shiji Yang2021-03-011-5/+5
| | | | | | | | | | | | | | | | | | | | Changes: * Increase "oem" partition size from 0x10000 to 0x20000 * Correct partition lables, synchronize with official firmware Evidence: It should be the same as hiwifi hc5x61a and the fact indeed the case. Here is part of dmesg boot log read from official firmware: [ 1.470000] Creating 7 MTD partitions on "raspi": [ 1.470000] 0x000000000000-0x000000030000 : "u-boot" [ 1.480000] 0x000000030000-0x000000040000 : "hw_panic" [ 1.490000] 0x000000040000-0x000000050000 : "Factory" [ 1.490000] 0x000000fc0000-0x000000fe0000 : "oem" [ 1.500000] 0x000000fe0000-0x000000ff0000 : "bdinfo" [ 1.510000] 0x000000ff0000-0x000001000000 : "backup" [ 1.510000] 0x000000050000-0x000000fc0000 : "firmware" Signed-off-by: Shiji Yang <yangshiji66@qq.com>
* mvebu/omnia: fix the device treeRui Salvaterra2021-03-013-0/+165
| | | | | | | | | | | Backport [1] and fix [2] hardware buffer management. Also fix the IRQ storm caused by a misconfiguration of the PCA9538 interrupt pin [3]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/armada-385-turris-omnia.dts?id=018b88eee1a2efda26ed2f09aab33ccdc40ef18f [2] https://lore.kernel.org/linux-arm-kernel/20210217153038.1068170-1-rsalvaterra@gmail.com/ [3] https://lore.kernel.org/linux-arm-kernel/20210220231144.32325-1-kabel@kernel.org/ Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
* lantiq: vr9: set the usb led trigger via devicetreeMathias Kresin2021-03-016-26/+36
| | | | | | | | | | Assign the usbdev trigger via devicetree and drop the userspace handling of the usb leds. Drop the now unused userspace helper code as well. Signed-off-by: Mathias Kresin <dev@kresin.me> Acked-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* lantiq: set maximum kernel sizeMathias Kresin2021-03-012-0/+4
| | | | | | | | | | | These boards have a fixed size kernel partition but do not limit the kernel size during image building. Disable image building for both boards as well, since the kernel of the last release as well as master are to big to fit into the 2 MByte kernel partition. Signed-off-by: Mathias Kresin <dev@kresin.me>
* lantiq: ARV752DPW22: set the usb led trigger via devicetreeMathias Kresin2021-03-012-1/+34
| | | | | | | | | | Assign the usbdev trigger via devicetree and drop the userspace handling of the usb leds Add the PCI attached usb controller as trigger sources for the usb led as well. Signed-off-by: Mathias Kresin <dev@kresin.me>
* octeon: re-enable CONFIG_CAVIUM_CN63XXP1 and EdgeRouter imageAdrian Schmutzler2021-02-282-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The symbol CONFIG_CAVIUM_CN63XXP1 was disabled during the bump to 4.19 (see Fixes:) with the following reason: No supported hardware uses CN63XXP1 and it causes "slight decrease in performance" However, it later turned out that the edgerouter image needed it, which led to having the device disabled in [1]. Still, dropping support of a device seems a harsh action for just removing a "slight" decrease in performance from the other devices. Thus, this enables CONFIG_CAVIUM_CN63XXP1 again, and essentially restores the situation present until (including) kernel 4.14 on this target. For OpenWrt as a platform, it seems more desirable to support all devices (and have them tested regularly via the snapshots) in this case. Users interested in maximum performance might still just remove the symbol again in their local build. [1] 3824fa26d256 ("octeon: disable edgerouter image") Fixes: 6c22545225cd ("target/octeon: Add Linux 4.19 support") Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* octeon: refresh config for kernel 5.4Adrian Schmutzler2021-02-281-57/+11
| | | | | | Simple run of 'make kernel_oldconfig' Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mediatek: add missing 5.10 patchesDavid Bauer2021-02-282-0/+57
| | | | | | | | These patches are required for the Ubiquiti UniFi 6 LR to work. They were already present for kernel 5.4 but got lost when adding 5.10 support. Signed-off-by: David Bauer <mail@david-bauer.net>
* mediatek: rework support for BananaPi BPi-R64Daniel Golle2021-02-2810-72/+182
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | **What's new** * Bring support for the Bananapi BPi-R64 to the level desirable for a nice hackable routerboard. * Use ARM Trusted Firmware A from source. (goodbye binary preloader) * Use Das U-Boot from source. (see previous commit) * Assemble SD-card image using OpenWrt image-commands. (no gen_sd_cruz_foo.sh added, this is not Raspbian) * Updated kernel options to support root filesystem. * Updated DTS to match OpenWrt LAN ports, known LEDs, buttons, ... * Detect root device, handle sysupgrade, config restore, ... * Wire up (known) LEDs and buttons in OpenWrt-fashion. * Build one set of images from SD-card and eMMC. * Hopefully provide a good example of how things can be done right from scratch. **Installation and images** * Have an empty SD-card at hand * Write stuff to the card, as root (card device is /dev/mmcblkX) - write header, gpt, bl2, atf, u-boot and recovery kernel: `cat *bpi-r64-boot-sdcard.img *bpi-r64-initramfs-recovery.fit > /dev/mmcblkX` - rescan partitions: `blockdev --rereadpt /dev/mmcblkX` - write main system to production partition: `cat *bpi-r64-squashfs-sysupgrade.fit > /dev/mmcblkXp5` * Installation to eMMC works using SD-card bootloader via TFTP When running OpenWrt of SD-card, issue this to trigger installation to eMMC: `fw_setenv bootcmd run emmc_init` Be prepared to serve the content of bin/targets/mediatek/mt7622 on TFTP server address 192.168.1.254. **What's missing** * The red LED is always on, probably a hardware bug. * AHCI (probably needs DTS changes) * Ship SD-card image ready with every needed for eMMC install. * The eMMC has a second, currently unused boot partition. This would be ideal to store the WiFi EEPROM and Ethernet MAC address(es). @sinovoip ideas? Thanks to Thomas Hühn @thuehn for providing the hardware! Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* mediatek: add alternative UBI NAND layout for Linksys E8450Daniel Golle2021-02-288-455/+576
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The vendor flash layout of the Linksys E8450 is problematic as it uses the SPI-NAND chip without any wear-leveling while at the same time wasting a lot of space for padding. Use an all-UBI layout instead, storing the kernel+dtb+squashfs in uImage.FIT standard format in UBI volume 'fit', the read-write overlay in UBI volume 'rootfs_data' as well as reduntant U-Boot environments 'ubootenv' and 'ubootenv2', and a 'recovery' kernel+dtb+initramfs uImage.FIT for dual-boot. ** WARNING ** THIS PROCEDURE CAN EASILY BRICK YOUR DEVICE PERMANENTLY IF NOT CARRIED OUT VERY CAREFULLY AND EXACTLY AS DESCRIBED! Step 0 * Configure your PC to have the static IPv4 address 192.168.1.254/24 * Provide bin/targets/mediatek/mt7622 via TFTP Now continue EITHER with step 1A or 1B, depending on your preference (and on having serial console wired up or not). Step 1A (Using the vendor web interface (or non-UBI OpenWrt install)) In order to update to the new bootloader and UBI-based firmware, use the web browser of your choice to open the routers web-interface accessible on http://192.168.1.1 * Navigate to 'Configuration' -> 'Administration' -> 'Firmware Upgrade' * Upload the file openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb and proceed with the upgrade. * Once OpenWrt comes up, use SCP to upload the new bootloader files to /tmp on the router: *-mt7622-linksys_e8450-ubi-preloader.bin *-mt7622-linksys_e8450-ubi-bl31-uboot.fip * Connect via SSH as you will now need to replace the bootloader in the Flash. ssh root@192.168.1.1 (the usual warnings) * First of all, backup all the flash now: for mtd in /dev/mtdblock*; do dd if=$mtd of=/tmp/$(basename $mtd); done * Then use SCP to copy /tmp/mtdblock* from the router and keep them safe. You will need them should you ever want to return to the factory firmware! * Now flow the uploaded files: mtd -e /dev/mtd0 write /tmp/*linksys_e8450-ubi-preloader.bin /dev/mtd0 mtd -e /dev/mtd1 write /tmp/*linksys_e8450-ubi-bl31-uboot.fip /dev/mtd1 If and only if both writes look like the completed successfully reboot the router. Now continue with step 2. Step 1B (Using the vendor bootloader serial console) * Use the serial to backup all /dev/mtd* devices before using the stock firmware (you got root shell when connected to serial). * Then reboot and select 'U-Boot Console' in the boot menu. * Copy the following lines, one by one: tftpboot 0x40080000 openwrt-mediatek-mt7622-linksys_e8450-ubi-preloader.bin tftpboot 0x40100000 openwrt-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip nand erase 0x0 0x180000 nand write 0x40080000 0x0 0x180000 reset Now continue with step 2 Step 2 Once the new bootchain comes up, the loader will initialize UBI and the ubootenv volumes. It will then of course fail to find any bootable volume and hence resort to load kernel via TFTP from server 192.168.1.254 while giving itself the address 192.168.1.1 The requested file is called openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb and your TFTP server should provide exactly that :) It will be written to UBI as recovery image and booted. You can then continue and flash the production OS image, either by using sysupgrade in the booted initramfs recovery OS, or by using the bootloader menu and TFTP. That's it. Go ahead and mess around with a bootchain built almost completely from source (only DRAM calibration blobs are fitted in bl2, and the irreplacable on-chip ROM loader remains, of course). And enjoy U-Boot built with many great features out-of-the-box. You can access the bootloader environment from within OpenWrt using the 'fw_printenv' and 'fw_setenv' commands. Don't be afraid, once you got the new bootchain installed the device should be fairly unbrickable (holding reset button before and during power-on resets things and allows reflashing recovery image via TFTP) Special thanks to @dvn0 (Devan Carpenter) for providing amazingly fast infra for test-builds, allowing for `make clean ; make -j$(nproc)` in less than two minutes :) Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* mediatek: add Linksys E8450 supportJohn Crispin2021-02-287-3/+667
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Linksys E8450, also known as Belkin RT3200, is a dual-band IEEE 802.11bgn/ac/ax router based on MediaTek MT7622BV and MediaTek MT7915AN chips. FCC: K7S-03571 and K7S-03572 Hardware highlights: - CPU: MediaTek MT7622BV (2x ARM Cortex-A53 @ 1350 MHz max.) - RAM: 512MB DDR3 - Flash: 128MB SPI-NAND (2k+64) - Ethernet: MT7531BE switch with 5 1000Base-T ports CPU port connected with 2500Base-X - WiFi 2.4 GHz: 802.11bgn 4T4R built-in antennas MT7622VB built-in - WiFi 5 GHz: 802.11ac/ax 4T4R built-in antennas MT7915AN chip on-board via PCIe MT7975AN front-end - Buttons: Reset and WPS - LEDS: 3 user controllable LEDs, 4 wired to switch - USB: USB2.0, single port - no Bluetooth (supported by SoC, not wired on board) - Serial: JST PH 2.0MM 6 Pin connector inside device ----_____________---- [ GND RX - TX - - ] --------------------- - JTAG: unpopulated ARM JTAG 20-pin connector (works) This commit adds support for the device in a way that is compatible with the vendor firmware's bootloader and dual-boot flash layout, the resulting image can directly be flashed using the vendor firmware. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: John Crispin <john@phrozen.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
* kernel: add support for enabling fit firmware partition parser via cmdlineFelix Fietkau2021-02-281-0/+6
| | | | | | | | | This is useful for dual-boot setups where the loader sets variables depending on the flash boot partition. For example the Linksys E8450 sets mtdparts=master for the first partition and mtdparts=slave for the second one. Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mediatek: add support for configuring BMT table size via device treeFelix Fietkau2021-02-282-24/+37
| | | | Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mediatek: mt7622: add Linux 5.10 supportFelix Fietkau2021-02-28169-171/+102212
| | | | | | | Switch mt7622 subtarget to Linux 5.10, it has been tested by many of us on several devices for a couple of weeks already. Signed-off-by: Felix Fietkau <nbd@nbd.name>
* mediatek: implement bad-block management table supportFelix Fietkau2021-02-285-0/+842
| | | | Signed-off-by: Felix Fietkau <nbd@nbd.name>
* image: extend FIT partition parser for use on eMMC/SDcardDaniel Golle2021-02-283-19/+245
| | | | | | | | | | Introduce a magic GUID_PARTITION_LINUX_FIT_GUID to designate a GPT partition to be interpreted by the FIT partition parser. In that way, sub-partitions for (external-data) uImage.FIT stored directly in a partition can be split, similar like we do for devices with raw flash storage. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* kernel: backport pending fix to select CPU_MIPS64Jason A. Donenfeld2021-02-272-0/+73
| | | | | | | | | | | | | | | | | | | | | The CPU_MIPS64 and CPU_MIPS32 variables are supposed to be able to distinguish broadly between 64-bit and 32-bit MIPS CPUs. However, they weren't selected by the specialty CPUs, Octeon and Loongson, which meant it was possible to hit a weird state of: MIPS=y, CONFIG_64BIT=y, CPU_MIPS64=n This commit rectifies the issue by having CPU_MIPS64 be selected when the missing Octeon or Loongson models are selected. In particular, this affects our octeonplus target. It has been posted to LKML here: https://lore.kernel.org/linux-mips/20210227122605.2680138-1-Jason@zx2c4.com/ Cc: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com> Cc: David Bauer <mail@david-bauer.net> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* kernel: bump 5.4 to 5.4.101John Audia2021-02-272-2/+2
| | | | | | | | | | | | Ran update_kernel.sh in a fresh clone without any existing toolchains. Build system: x86_64 Build-tested: ipq806x/R7800 Run-tested: ipq806x/R7800 No dmesg regressions, everything functional. Signed-off-by: John Audia <graysky@archlinux.us>
* kernel: move some new symbols available on 5.10 to genericAleksander Jan Bajkowski2021-02-273-7/+7
| | | | | | Move some disabled config options found in sunxi target to generic. Signed-off-by: Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
* kernel: b53: update the BCM5365 UIDDaniel González Cabanelas2021-02-261-2/+2
| | | | | | | | | | | | | | BCM63XX internal PHYs and BCM5365 SoC internal switch are both using the same phy_driver->phy_id, causing conflicts and unnecessary probes. E.g the BCM63XX phy internal IRQ is lost on the first probe. The full BCM5365 UID is 0x00406370. Use an additional byte to mask the BCM5365 UID to avoid duplicate driver phy_id's. This will fix the IRQ issue in internal BCM63XX PHYs and avoid more conflicts in the future. Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
* kernel: 5.4: generic: add missing symbolsIlya Lipnitskiy2021-02-261-0/+13
| | | | Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
* kernel: 5.4: fix patches after wireguard backportIlya Lipnitskiy2021-02-263-25/+7
| | | | | | No major problems, just a minor Kconfig fix and a refresh. Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
* kernel: 5.4: import wireguard backportJason A. Donenfeld2021-02-26124-0/+63670
| | | | | | | | | | | | | | | | | | Rather than using the clunky, old, slower wireguard-linux-compat out of tree module, this commit does a patch-by-patch backport of upstream's wireguard to 5.4. This specific backport is in widespread use, being part of SUSE's enterprise kernel, Oracle's enterprise kernel, Google's Android kernel, Gentoo's distro kernel, and probably more I've forgotten about. It's definately the "more proper" way of adding wireguard to a kernel than the ugly compat.h hell of the wireguard-linux-compat repo. And most importantly for OpenWRT, it allows using the same module configuration code for 5.10 as for 5.4, with no need for bifurcation. These patches are from the backport tree which is maintained in the open here: https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y I'll be sending PRs to update this as needed. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* kernel: 5.10: wireguard: backport 5.12-rc1 changes in net.gitJason A. Donenfeld2021-02-265-0/+1016
| | | | | | | | | | | | | | These will eventually make their way to 5.10, but it could be a while. https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=ee576c47db60432c37e54b1e2b43a8ca6d3a8dca https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=5a0598695634a6bb4126818902dd9140cd9df8b6 https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=99fff5264e7ab06f45b0ad60243475be0a8d0559 https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=8b5553ace83cced775eefd0f3f18b5c6214ccf7a https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=bce2473927af8de12ad131a743f55d69d358c0b9 Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> [Rename 082-wireguard-kconfig... to 083-wireguard-kconfig...] Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
* zynq: Enable CONFIG_KERNEL_MODE_NEONIlya Lipnitskiy2021-02-261-1/+0
| | | | | | | | This flag is set on all other platforms. And Zynq 7000 SoC does have NEON support: https://www.xilinx.com/support/documentation/application_notes/xapp1206-boost-sw-performance-zynq7soc-w-neon.pdf Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
* mpc85xx: remove fdt.bin imageDavid Bauer2021-02-261-1/+1
| | | | | | | | | When converting the fdt binary to be created as an artifact, the image receipt was dropped but the entry in the target images list was not. Fixes commit 1e41de2f48e2 ("mpc85xx: convert TL-WDR4900 v1 to simpleImage") Signed-off-by: David Bauer <mail@david-bauer.net>
* ramips: add support for ZTE MF283+Lech Perczak2021-02-268-0/+415
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ZTE MF283+ is a dual-antenna LTE category 4 router, based on Ralink RT3352 SoC, and built-in ZTE P685M PCIe MiniCard LTE modem. Hardware highlighs: - CPU: MIPS24KEc at 400MHz, - RAM: 64MB DDR2, - Flash: 16MB SPI, - Ethernet: 4 10/100M port switch with VLAN support, - Wireless: Dual-stream 802.11n (RT2860), with two internal antennas, - WWAN: Built-in ZTE P685M modem, with two internal antennas and two switching SMA connectors for external antennas, - FXS: Single ATA, with two connectors marked PHONE1 and PHONE2, internally wired in parallel by 0-Ohm resistors, handled entirely by internal WWAN modem. - USB: internal miniPCIe slot for modem, unpopulated USB A connector on PCB. - SIM slot for the WWAN modem. - UART connector for the console (unpopulated) at 3.3V, pinout: 1: VCC, 2: TXD, 3: RXD, 4: GND, settings: 57600-8-N-1. - LEDs: Power (fixed), WLAN, WWAN (RGB), phone (bicolor, controlled by modem), Signal, 4 link/act LEDs for LAN1-4. - Buttons: WPS, reset. Installation: As the modem is, for most of the time, provided by carriers, there is no possibility to flash through web interface, only built-in FOTA update and TFTP recovery are supported. There are two installation methods: (1) Using serial console and initramfs-kernel - recommended, as it allows you to back up original firmware, or (2) Using TFTP recovery - does not require disassembly. (1) Using serial console: To install OpenWrt, one needs to disassemble the router and flash it via TFTP by using serial console: - Locate unpopulated 4-pin header on the top of the board, near buttons. - Connect UART adapter to the connector. Use 3.3V voltage level only, omit VCC connection. Pin 1 (VCC) is marked by square pad. - Put your initramfs-kernel image in TFTP server directory. - Power-up the device. - Press "1" to load initramfs image to RAM. - Enter IP address chosen for the device (defaults to 192.168.0.1). - Enter TFTP server IP address (defaults to 192.168.0.22). - Enter image filename as put inside TFTP server - something short, like firmware.bin is recommended. - Hit enter to load the image. U-boot will store above values in persistent environment for next installation. - If you ever might want to return to vendor firmware, BACK UP CONTENTS OF YOUR FLASH NOW. For this router, commonly used by mobile networks, plain vendor images are not officially available. To do so, copy contents of each /dev/mtd[0-3], "firmware" - mtd3 being the most important, and copy them over network to your PC. But in case anything goes wrong, PLEASE do back up ALL OF THEM. - From under OpenWrt just booted, load the sysupgrade image to tmpfs, and execute sysupgrade. (2) Using TFTP recovery - Set your host IP to 192.168.0.22 - for example using: sudo ip addr add 192.168.0.22/24 dev <interface> - Set up a TFTP server on your machine - Put the sysupgrade image in TFTP server root named as 'root_uImage' (no quotes), for example using tftpd: cp openwrt-ramips-rt305x-zte_mf283plus-squashfs-sysupgrade.bin /srv/tftp/root_uImage - Power on the router holding BOTH Reset and WPS buttons held for around 5 seconds, until after WWAN and Signal LEDs blink. - Wait for OpenWrt to start booting up, this should take around a minute. Return to original firmware: Here, again there are two possibilities are possible, just like for installation: (1) Using initramfs-kernel image and serial console (2) Using TFTP recovery (1) Using initramfs-kernel image and serial console - Boot OpenWrt initramfs-kernel image via TFTP the same as for installation. - Copy over the backed up "firmware.bin" image of "mtd3" to /tmp/ - Use "mtd write /tmp/firmware.bin /dev/mtd3", where firmware.bin is your backup taken before OpenWrt installation, and /dev/mtd3 is the "firmware" partition. (2) Using TFTP recovery - Follow the same steps as for installation, but replacing 'root_uImage' with firmware backup you took during installation, or by vendor firmware obtained elsewhere. A few quirks of the device, noted from my instance: - Wired and wireless MAC addresses written in flash are the same, despite being in separate locations. - Power LED is hardwired to 3.3V, so there is no status LED per se, and WLAN LED is controlled by WLAN driver, so I had to hijack 3G/4G LED for status - original firmware also does this in bootup. - FXS subsystem and its LED is controlled by the modem, so it work independently of OpenWrt. Tested to work even before OpenWrt booted. I managed to open up modem's shell via ADB, and found from its kernel logs, that FXS and its LED is indeed controlled by modem. - While finding LEDs, I had no GPL source drop from ZTE, so I had to probe for each and every one of them manually, so this might not be complete - it looks like bicolor LED is used for FXS, possibly to support dual-ported variant in other device sharing the PCB. - Flash performance is very low, despite enabling 50MHz clock and fast read command, due to using 4k sectors throughout the target. I decided to keep it at the moment, to avoid breaking existing devices - I identified one potentially affected, should this be limited to under 4MB of Flash. The difference between sysupgrade durations is whopping 3min vs 8min, so this is worth pursuing. In vendor firmware, WWAN LED behaviour is as follows, citing the manual: - red - no registration, - green - 3G, - blue - 4G. Blinking indicates activity, so netdev trigger mapped from wwan0 to blue:wwan looks reasonable at the moment, for full replacement, a script similar to "rssileds" would need to be developed. Behaviour of "Signal LED" in vendor firmware is as follows: - Off - no signal, - Blinking - poor coverage - Solid - good coverage. A few more details on the built-in LTE modem: Modem is not fully supported upstream in Linux - only two CDC ports (DIAG and one for QMI) probe. I sent patches upstream to add required device IDs for full support. The mapping of USB functions is as follows: - CDC (QCDM) - dedicated to comunicating with proprietary Qualcomm tools. - CDC (PCUI) - not supported by upstream 'option' driver yet. Patch submitted upstream. - CDC (Modem) - Exactly the same as above - QMI - A patch is sent upstream to add device ID, with that in place, uqmi did connect successfully, once I selected correct PDP context type for my SIM (IPv4-only, not default IPv4v6). - ADB - self-explanatory, one can access the ADB shell with a device ID added to 51-android.rules like so: SUBSYSTEM!="usb", GOTO="android_usb_rules_end" LABEL="android_usb_rules_begin" SUBSYSTEM=="usb", ATTR{idVendor}=="19d2", ATTR{idProduct}=="1275", ENV{adb_user}="yes" ENV{adb_user}=="yes", MODE="0660", GROUP="plugdev", TAG+="uaccess" LABEL="android_usb_rules_end" While not really needed in OpenWrt, it might come useful if one decides to move the modem to their PC to hack it further, insides seem to be pretty interesting. ADB also works well from within OpenWrt without that. O course it isn't needed for normal operation, so I left it out of DEVICE_PACKAGES. Signed-off-by: Lech Perczak <lech.perczak@gmail.com> [remove kmod-usb-ledtrig-usbport, take merged upstream patches] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mvebu: add LED support for GL.iNet GL-MV1000Jeff Collins2021-02-262-1/+46
| | | | | | | | This patch enables LED support for the GL.iNet GL-MV1000 Signed-off-by: Jeff Collins <jeffcollins9292@gmail.com> [add SPDX identifier on new file, add aliases, minor cosmetic issues] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ath79: fix USB power on TP-Link TL-WR810N v1Tom Stöveken2021-02-261-0/+1
| | | | | | | | | | | Before: Kernel reported "usb_vbus: disabling" and the USB was not providing power After: USB power is switched on, peripheral is powered from the device Signed-off-by: Tom Stöveken <tom@naaa.de> [squash and tidy up] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* bcm53xx: backport more upstream dts stuff from kernel 5.11Rafał Miłecki2021-02-257-0/+507
| | | | Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
* bcm53xx: backport Linksys Panamera (EA9500) patchesVivek Unune2021-02-255-2/+230
| | | | | | | | | | | | | | | | These patches have been already accepted. 302-ARM-dts-BCM5301X-Update-Northstar-pinctrl-binding.patch had to be updated. [rmilecki: use actual upstream accepted patches replace v5.10 with v5.11 to match actual upstream kernel recover dropped part of the pinctrl compatible patch update filenames refresh patches] Signed-off-by: Vivek Unune <npcomplete13@gmail.com> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
* bcm53xx: group dts backports by upstream kernel versionRafał Miłecki2021-02-254-1/+6
| | | | | | It's a simple renaming thing. Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
* bmips: dts: fix syscon-reboot nodesÁlvaro Fernández Rojas2021-02-256-42/+36
| | | | | | Using regmap with phandles is deprecated. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
* bmips: add BCM63268 timer clock and reset supportÁlvaro Fernández Rojas2021-02-256-4/+413
| | | | | | We need this to fix USB support on BCM63268. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
* bmips: rewrite pin controllersÁlvaro Fernández Rojas2021-02-2526-2188/+3517
| | | | | | This is needed in order to upstream them. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
* treewide: rename IMAGE_PREFIX/IMAGE_NAME to DEVICE_IMG_*Adrian Schmutzler2021-02-259-13/+13
| | | | | | | | | | | | | | We so far had two variables IMG_PREFIX and IMAGE_PREFIX with different content. Since these names are obviously quite confusing, this patch renames the latter to DEVICE_IMG_PREFIX, as it's a device-dependent variable, while IMG_PREFIX is only (sub)target-dependent. For consistency, also rename IMAGE_NAME to DEVICE_IMG_NAME, as that's a device-dependent variable as well. Cc: Paul Spooren <mail@aparcar.org> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mediatek: switch to use seperate ramdisk for initramfs imagesDaniel Golle2021-02-252-2/+2
| | | | | | | | | | | | | | | | | | MediaTek targets always use U-Boot's modern uImage.FIT format which allows bundling several blobs into a single file including hashes, descriptions and more. In fact, we are already using that to bundle the Flattened Device Tree blob with the kernel on this and many other targets. In the same fashion, we can now make use of the newly introduced support for building seperate ramdisk to uImage.FIT with a dedicated initrd blob checked and loaded by U-Boot instead of embedding the cpio archive into the kernel itself. This allows for having larger ramdisks, choosing ramdisk compression independently of kernel compression (while only kernel is decompressed by the bootloader) and for more easily replacing or modifying the filesystem contained in an initramfs image. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* oxnas: add experimental support for Linux 5.10Daniel Golle2021-02-2513-0/+1365
| | | | | | | PCIe still reports link-down for some reason, RAID fails to assemble despite SATA looking good (maybe a generic problem with RAID?) Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* ath79: enable UART node for GL-USB150Adrian Schmutzler2021-02-251-4/+0
| | | | | | | | | | This was overlooked when adding support for this device. (It has recently been discovered that this was the only device in ath79 having &uart disabled.) Fixes: acc62630132c ("ath79: add support for GL.iNet GL-USB150") Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* kernel: bump 5.4 to 5.4.100John Audia2021-02-252-3/+3
| | | | | | | | | | | | | | Ran update_kernel.sh in a fresh clone without any existing toolchains. Build system: x86_64 Build-tested: ipq806x/R7800 Run-tested: ipq806x/R7800 No dmesg regressions, everything functional Signed-off-by: John Audia <graysky@archlinux.us> [refresh again] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* mediatek: mt7622-bananapi-bpi-r64-rootdisk rebase to upstream dtsOskari Lemmela2021-02-241-573/+1
| | | | | | | simplify maintaining mt7622-bananapi-bpi-r64-rootdisk.dts by storing only differences between upstream dts Signed-off-by: Oskari Lemmela <oskari@lemmela.net>
* mediatek: mt7622: fix bpi-r64 emmc f2fs overlayOskari Lemmela2021-02-241-1/+2
| | | | | | | | f2fs tools are needed for generating f2fs overlay. vfat modules are used for recovery mounting. Fixes: f72a2b004c3 ("mediatek: add bpi-r64 emmc support") Signed-off-by: Oskari Lemmela <oskari@lemmela.net>
* mediatek: mt7622: enable support for f2fs overlayOskari Lemmela2021-02-241-0/+2
| | | | | | | f2fs filesystem and loop device support are needed for f2fs overlay over squashfs. Signed-off-by: Oskari Lemmela <oskari@lemmela.net>
* mediatek: mt7622: add missing CONFIG_MMC_BLKOskari Lemmela2021-02-241-0/+1
| | | | | | CONFIG_MMC_BLK enables block devices for SD/eMMC Signed-off-by: Oskari Lemmela <oskari@lemmela.net>
* kernel: bump version 5.10 to 5.10.18Kabuli Chana2021-02-2422-86/+86
| | | | | | | | update kernel version, refresh current patchset Signed-off-by: Kabuli Chana <newtownBuild@gmail.com> [rebase/refresh] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* bmips: add SPI accepted PM patchesÁlvaro Fernández Rojas2021-02-244-20/+93
| | | | | | These patches have been accepted upstream. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
* ath79: create common DTSI for Senao qca955x APsAdrian Schmutzler2021-02-243-170/+101
| | | | | | | | | | | | | | This creates a shared DTSI for qca955x Senao/Engenius APs with concatenated firmware partition/okli loader: - EAP1200H - EnstationAC v1 To make this usable for future boards with 32 MB flash as well, split the partitions node already. Suggested-by: Michael Pratt <mcpratt@pm.me> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ath79: rename 'engenius' Makefile definitions to 'senao'Michael Pratt2021-02-243-25/+33
| | | | | | | | | | | | | | | | These recipes and definitions can apply to devices from other vendors with PCB boards or SDK produced by Senao not only the brand Engenius possible examples: Extreme Networks, WatchGuard, OpenMesh, Fortinet, ALLNET, OCEDO, Plasma Cloud, devolo, etc. so rename all of these items and move DEVICE_VENDOR from common to generic/tiny.mk Signed-off-by: Michael Pratt <mcpratt@pm.me>
* ath79: create common DTSI for Senao ar934x APsAdrian Schmutzler2021-02-244-273/+98
| | | | | | | | | | | | | | | This creates a shared DTSI for ar934x Senao/Engenius APs: - EAP300 v2 - ENS202EXT v1 - EAP600 - ECB600 Since ar9341/ar9344 have different configuration, this new file mostly contains the partitioning. Suggested-by: Michael Pratt <mcpratt@pm.me> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-12 21:50:31 +0000