aboutsummaryrefslogtreecommitdiffstats
path: root/package/boot
Commit message (Collapse)AuthorAgeFilesLines
* arm-trusted-firmware-mediatek: prune now uneeded declarationsDaniel Golle2021-03-061-7/+0
| | | | | | | Remove unneeded delcarations form package Makefile now that everything comes from github.com/mtk-openwrt upstream. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* arm-trusted-firmware-mediatek: don't select DDR3_FLYBY for 1ddrDaniel Golle2021-03-051-10/+6
| | | | | | | DDR3_FLYBY has accidentally been set also for the 1-chip variant which lead to broken, unbootable images. Fix that. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* uboot-mediatek: improve BPi-R64 supportDaniel Golle2021-03-052-6/+14
| | | | | | | | * allow MAC address from U-Boot env to be inhertied * allow eMMC installation to succeed also without recovery present on the SD Card. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* arm-trusted-firmware-mediatek: update to ATF 2.4 (2021-02-25)Daniel Golle2021-03-053-61/+30
| | | | | | | | | | | | | | | | | | | | All necessary blobs are now contained in the upstream repository, no more wild replacing of blobs needed. This new version also contains new storage drivers for (SPI-)NAND which already comes with support for FM35Q1GA, so that patch can be dropped as well. Tested on: * Bananapi BPi-R64 - sdmmc-2ddr - emmc-2ddr * Linksys E8450 - snand-1ddr All works fine (booting Bananapi BPi-R64 from SD Card does NOT require a signed image, so patch arm-trusted-firmware-mediatek to allow doing that). Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* arm-trusted-firmware-mediatek: don't try to install absent filesDaniel Golle2021-03-041-6/+0
| | | | | | | | Don't try to install files which no longer exist Since {e,sd}mmc are now produced by ptgen they have been removed. Fixes: 5a3562cd1d ("arm-trusted-firmware-mediatek: remove {e,sd}mmc headers") Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* arm-trusted-firmware-mediatek: remove {e,sd}mmc headersDaniel Golle2021-03-031-20/+0
| | | | | | | | Turned out those are simply MBR with active boot partition. And not needed at all on emmc. Remove them as ptgen can now generate hybrid MBR sufficient to boot MT7622 from SD Card. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* uboot-mediatek: bpi-r64: make sure eMMC installation runs only onceDaniel Golle2021-03-021-3/+3
| | | | Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* uboot-mediatek: bpi-r64: fix eMMC installation menu labelDaniel Golle2021-03-011-1/+1
| | | | | | Change boot menu label for eMMC installation to tell what it does now. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* mediatek: mt7622: bpi-r64: simplify eMMC install procedureDaniel Golle2021-03-011-6/+10
| | | | | | | | Write everything needed for eMMC install into the gaps between partitions on SD card. In that way, installation to eMMC only needs the SD card, no additional files need to be loaded via TFTP any more. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* uboot-sunxi: add missing type __u64Georgi Valkov2021-03-011-0/+10
| | | | | | | | | | | | | | | Non Linux systems e.g. macOS lack the __u64 type and produce build errors: In file included from tools/aisimage.c:9: In file included from include/image.h:19: In file included from ./arch/arm/include/asm/byteorder.h:29: In file included from include/linux/byteorder/little_endian.h:13: include/linux/types.h:146:9: error: unknown type name '__u64'; did you mean '__s64'? typedef __u64 __bitwise __le64; Resolved by declaring __u64 in include/linux/types.h Build tested on macOS and Ubuntu. Signed-off-by: Georgi Valkov <gvalkov@abv.bg>
* uboot-envtools: adjust compile patch to version v2021.01Ronny Kotzschmar2021-03-011-2/+2
| | | | | | | with u-boot v2020.07 some variables have been renamed so this patch needs to be adjusted otherwise at least with macOS as build system there are build errors Signed-off-by: Ronny Kotzschmar <ro.ok@me.com>
* uboot-envtools: add defaults for Bananapi BPi-R64Daniel Golle2021-02-281-0/+7
| | | | Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* mt7623n-preloader: remove mt7622-preloaderDaniel Golle2021-02-281-14/+0
| | | | | | mt7622-preloader has been superseeded by arm-trusted-firmware-mediatek. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* uboot-mediatek: rework support for Bananapi BPi-R64 boardDaniel Golle2021-02-284-3/+608
| | | | | | | | | | | | | | Provide U-Boot variants for SD-card as well as eMMC boot, so we can generate whole-disk images for the device. While at it, rename 'mt7622' to 'mt7622-rfb1' to make it less confusing now that more boards are being added. Thanks to Frank Wunderlich (@frank-w) for making that nice SVG image explaining the MMC boot process[1] and for providing the necessary binary header blobs. [1]: https://github.com/frank-w/BPI-R64-ATF Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* uboot-envtools: add defaults for linksys-e8450-ubiDaniel Golle2021-02-281-0/+25
| | | | | | | | Add U-Boot environment configuration for the Linksys E8450 (UBI) to allow access to the bootloader environment from OpenWrt via 'fw_printenv' and 'fw_setenv'. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* uboot-mediatek: add support for Linksys E8450Daniel Golle2021-02-2813-160/+713
| | | | | | | | | | | | | | | | | | | | | Build U-Boot for the Linksys E8450 in order to have support for UBI. The loader has a default environment with scripts handling the reset button as well as fall-back to recovery firmware. If the loader comes up without a valid environment found in UBI, it will automatically make sure UBI is formatted and create a new environment and proceed to load recovery firmware (either from UBI or via TFTP if recovery is corrupted or unavailable). If the button is held down during power-on, the yellow status LED turns on and the bootloader environment is reset to factory defaults. If the button is released at this point, the recovery firmware (if existing) is loaded from UBI and booted. If the button is continously held down even beyond the point that the yellow LED turned on, the loader will try to load the recovery firmware via TFTP from server 192.168.1.254, write it to UBI and boot. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* arm-trusted-firmware-mediatek: add patch for Fidelix SPI NANDDaniel Golle2021-02-281-0/+24
| | | | | | | | The Linksys E8450 aka. Belkin RT3200 comes with a rather fresh brand of SPI NAND storage. Add support for it to the nandx driver in arm-trusted-firmware-mediatek, so we can boot from that chip. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* ramips: add support for ZTE MF283+Lech Perczak2021-02-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* arm-trusted-firmware-mediatek: correct location of PKG_LICENSEDaniel Golle2021-02-241-1/+2
| | | | | | | | | As PKG_LICENSE is originally set by include/trusted-firmware-a.mk it can only be appended after that. Hence move that line below the include to actually make sense. (cosmetical change, already slipped into openwrt-21.02 branch) Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* imx-bootlets: refresh patchesAdrian Schmutzler2021-02-243-32/+25
| | | | | | Tidy this up a little. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* uboot-envtools: add support for ZyXEL GS-1900-8HP v1 and v2Stijn Segers2021-02-231-0/+2
| | | | | | This adds the necessary nuts and bolts for the uboot settings for both the ZyXEL GS1900-8HP v1 and v2. Signed-off-by: Stijn Segers <foss@volatilesystems.org>
* arm-trusted-firmware-mediatek: use @OPENWRT mirror for blobsDaniel Golle2021-02-231-1/+1
| | | | | | | Now that mirrors have picked it up, switch to using the @OPENWRT mirror instead of hosting those files on Github. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* arm-trusted-firmware-mediatek: bring back packageDaniel Golle2021-02-231-47/+98
| | | | | | | | * use binary provided by MediaTek to work-around 'bromimage' issue * refactor Makefile * add mt7622 1c variants (using binaries provided by MTK) Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* tfa-layerscape: build fiptool againAdrian Schmutzler2021-02-211-2/+7
| | | | | | | | | | | | | | | | | The ls-ddr-phy package needs fiptool options that are not available via the version from arm-trusted-firmware-tools. This breaks build for layerscape with the recently added LX2160a: create: unrecognized option '--ddr-immem-udimm-1d' Use the tfa-layerscape variant again for now, but rename it to fiptool-layerscape to indicate that it's a specific variant. This reverts 84bc7d31e0a8 ("tfa-layerscape: don't build fiptool"). Fixes: f59d7aab2a37 ("layerscape: add ddr-phy package") Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* layerscape: add LX2160ARDB (Rev2.0 silicon) board supportYangbo Lu2021-02-194-1/+47
| | | | | | | | | | | | | | | | | | | | | | The QorIQ LX2160A reference design board provides a comprehensive platform that enables design and evaluation of the LX2160A processor. - Enables network intelligence with the next generation Datapath (DPPA2) which provides differentiated offload and a rich set of IO, including 10GE, 25GE, 40GE, and PCIe Gen4 - Delivers unprecedented efficiency and new virtualized networks - Supports designs in 5G packet processing, network function virtualization, storage controller, white box switching, network interface cards, and mobile edge computing - Supports all three LX2 family members (16-core LX2160A; 12-core LX2120A; and 8-core LX2080A) Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> [use AUTORELEASE, add dtb to firmware part] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* layerscape: add FRWY-LS1046A board supportYangbo Lu2021-02-194-2/+46
| | | | | | | | | | | | | | | | | | | The LS1046A Freeway board (FRWY) is a high-performance computing, evaluation, and development platform that supports the QorIQ LS1046A architecture processor capable of support more than 32,000 CoreMark performance. The FRWY-LS1046A board supports the QorIQ LS1046A processor, onboard DDR4 memory, multiple Gigabit Ethernet, USB3.0 and M2_Type_E interfaces for Wi-Fi. The FRWY-LS1046A-TP includes the Coral Tensor Flow Processing Unit that offloads AI/ML inferencing from the CPU to provide significant boost for AI/ML applications. The FRWY-LS1046A-TP includes one M.2 TPU module and more modules can easily be added including USB versions of the module to scale the AI/ML performance. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> [rebase, use AUTORELEASE, fix sorting, add dtb to firmware part] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* Revert "uboot-imx6: bump to 2021.01 release"Petr Štetiar2021-02-143-11/+24
| | | | | | | | This reverts commit 50a5a8993d15fe090fdbf10fc25aba3f78c47d40 as the bump to 2021.01 unveiled issue with missing swig host tool needed for mx6cuboxi's SPL. Signed-off-by: Petr Štetiar <ynezz@true.cz>
* uboot-imx6: bump to 2021.01 releasePetr Štetiar2021-02-143-24/+11
| | | | | | | | | | | | | | | Refreshed all patches, removed 110-mx6cuboxi-mmc-fallback.patch as it seems, that upstream has probably added similar funcionality in commit 6c3fbf3e456c ("mx6cuboxi: customize board_boot_order to access eMMC") and it needs to be re-verified by device owner. Run tested on apalis. Cc: Felix Fietkau <nbd@nbd.name> Cc: Vladimir Vid <vladimir.vid@sartura.hr> Cc: Tim Harvey <tharvey@gateworks.com> Cc: Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by: Petr Štetiar <ynezz@true.cz>
* arm-trusted-firmware-tools: add patch to pass LDFLAGSDaniel Golle2021-02-101-0/+11
| | | | | | This should hopefully fix builds on the buildbot. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* arm-trusted-firmware-mediatek: mark @BROKEN until bromimage gets fixedDaniel Golle2021-02-101-1/+3
| | | | | | | | | | The 'bromimage' tool which is used to wrap bl2 with a MediaTek-specific header is distributed in binary form only and unfortunately tries to dynamically link against libopenssl, which fails on the buildbots. Wait for MTK to provide a at least static executable instead, in the meantime, mark the package as broken. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* arm-trusted-firmware-tools: fix passing of CFLAGSDaniel Golle2021-02-101-3/+2
| | | | | | | | HOST_CFLAGS were ignored as they were passed on incorrectly which lead to build failure if OpenSSL wasn't present on the build host. Fix that by properly passing HOST_CFLAGS when building each tool. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* arm-trusted-firmware-tools: remove tools which require libopensslDaniel Golle2021-02-091-12/+0
| | | | | | They are anyway not used for now, so only build fiptool and sptool. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* uboot-envtools: Update to version 2021.01Hauke Mehrtens2021-02-081-2/+2
| | | | Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* treewide: unify OpenWrt hosted source via @OPENWRTPaul Spooren2021-02-051-1/+1
| | | | | | | | | | | Multiple sources are hosted on OpenWrts source server only. The source URLs to point to the server vary based on different epochs in OpenWrts history. Replace all by @OPENWRT which is an "empty" mirror, therefore using the fallback servers sources.cdn.openwrt.org and sources.openwrt.org. Signed-off-by: Paul Spooren <mail@aparcar.org>
* arm-trusted-firmware-mediatek: make use of trusted-firmware-a.mkDaniel Golle2021-02-031-10/+6
| | | | Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* tfa-layerscape: don't build fiptoolDaniel Golle2021-02-031-8/+3
| | | | | | tfa-fiptool is now provided by an extra package. Use that instead. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* arm-trusted-firmware-tools: add packageDaniel Golle2021-02-031-0/+70
| | | | | | | Package ARM Trusted Firmware host tools separately. (instead of building tfa-fiptool as part of tfa-layerscape) Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* arm-trusted-firmware-mediatek: add ATF builds for MT7622Daniel Golle2021-02-021-0/+111
| | | | | | | | | | | | | | ATF bl2 comes in 4 variants for MT7622 depending on the boot media: * nor * snand * emmc * sdmmc Additional binary headers needed for emmc and sdmmc are downloaded as well and provided along with bl2*.bin and bl31.bin to allow building images including ATF for MT7622. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* uboot-rockchip: fix RockPro64 boot from eMMCMarty Jones2021-02-011-0/+27
| | | | | | | | | | | With upstream commit f81f9f0ebac5 ("rockchip: rockpro64: initialize USB in preboot") CONFIG_USE_PREBOOT was enabled on the RockPro64, which is causing boot issues when a eMMC is used, as a workaround will temporarily disable this option. Signed-off-by: Marty Jones <mj8263788@gmail.com> [Improve patch description] Signed-off-by: David Bauer <mail@david-bauer.net>
* arm-trusted-firmware-mvebu: pass commit ids to a3700-utils/mv-ddr-marvellAndre Heider2021-01-303-0/+29
| | | | | | | | | The two required tools fail to identify their version when not compiling from a git clone, patch that in and pass on the used commit hashes. Upon boot it now prints "WTMI-devel-18.12.1-5598e150". Signed-off-by: Andre Heider <a.heider@gmail.com>
* arm-trusted-firmware-mvebu: bump espressobin boards to CPU_1000_DDR_800Andre Heider2021-01-301-6/+6
| | | | | | | | | | | | | The cpufreq issue has been identified and a fix is in the process of beeing upstreamed [0]. Bump the boards to the default 1000MHz so they can run at that frequency once the fix is merged. Until then the boards are stuck at 800MHz (just claiming to run 1000Hz, which is a lie). [0] https://lore.kernel.org/linux-arm-kernel/20210114124032.12765-1-pali@kernel.org/ Signed-off-by: Andre Heider <a.heider@gmail.com>
* arm-trusted-firmware-mvebu: update to v2.4Andre Heider2021-01-302-12/+12
| | | | Signed-off-by: Andre Heider <a.heider@gmail.com>
* uboot-mvebu: update to v2021.01Andre Heider2021-01-304-533/+2
| | | | | | | u-boot now detects emmc variants at runtime, we don't need to build seperate binaries anymore. Signed-off-by: Andre Heider <a.heider@gmail.com>
* arm-trusted-firmware-mvebu: don't build emmc variantsAndre Heider2021-01-301-55/+0
| | | | | | | Starting with u-boot v2021.01 a single binary will be used for non-emmc and emmc variants. Signed-off-by: Andre Heider <a.heider@gmail.com>
* sunxi: add support for linksprite pcDuino3 nano boardJiang Yongquan2021-01-271-0/+7
| | | | | | | | | | | | | | | | | | Specifications: - SoC: Allwinner A20 @ 1Ghz - DRAM: 1GiB DDR3 @ 408MHz (K4B4G1646Q-HYK0) - NAND: 4GB MLC NAND (H27UBG8T2BTR-BC) - Ethernet: 10/100/1000Mbps Ethernet (Realtek RTL8211E) Flash instructions: dd if=openwrt-sunxi-cortexa7-linksprite_pcduino3-nano-ext4-sdcard.img of=/dev/sdX Signed-off-by: Jiang Yongquan <woxwchc@foxmail.com> [Remove CONFIG_REALTEK_PHY from sunxi/cortexa53 config] Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* ath79: add support for Senao Engenius EAP1200HMichael Pratt2021-01-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FCC ID: A8J-EAP1200H Engenius EAP1200H is an indoor wireless access point with 1 Gb ethernet port, dual-band wireless, internal antenna plates, and 802.3at PoE+ **Specification:** - QCA9557 SOC - QCA9882 WLAN PCI card, 5 GHz, 2x2, 26dBm - AR8035-A PHY RGMII GbE with PoE+ IN - 40 MHz clock - 16 MB FLASH MX25L12845EMI-10G - 2x 64 MB RAM NT5TU32M16FG - UART at J10 populated - 4 internal antenna plates (5 dbi, omni-directional) - 5 LEDs, 1 button (power, eth0, 2G, 5G, WPS) (reset) **MAC addresses:** MAC addresses are labeled as ETH, 2.4G, and 5GHz Only one Vendor MAC address in flash eth0 ETH *:a2 art 0x0 phy1 2.4G *:a3 --- phy0 5GHz *:a4 --- **Serial Access:** the RX line on the board for UART is shorted to ground by resistor R176 therefore it must be removed to use the console but it is not necessary to remove to view boot log optionally, R175 can be replaced with a solder bridge short the resistors R175 and R176 are next to the UART RX pin at J10 **Installation:** 2 ways to flash factory.bin from OEM: Method 1: Firmware upgrade page: OEM webpage at 192.168.1.1 username and password "admin" Navigate to "Firmware Upgrade" page from left pane Click Browse and select the factory.bin image Upload and verify checksum Click Continue to confirm and wait 3 minutes Method 2: Serial to load Failsafe webpage: After connecting to serial console and rebooting... Interrupt uboot with any key pressed rapidly execute `run failsafe_boot` OR `bootm 0x9fd70000` wait a minute connect to ethernet and navigate to "192.168.1.1/index.htm" Select the factory.bin image and upload wait about 3 minutes **Return to OEM:** If you have a serial cable, see Serial Failsafe instructions otherwise, uboot-env can be used to make uboot load the failsafe image *DISCLAIMER* The Failsafe image is unique to Engenius boards. If the failsafe image is missing or damaged this will brick the device DO NOT downgrade to ar71xx this way, it can cause kernel loop or halt ssh into openwrt and run `fw_setenv rootfs_checksum 0` reboot, wait 3 minutes connect to ethernet and navigate to 192.168.1.1/index.htm select OEM firmware image from Engenius and click upgrade **TFTP recovery:** Requires serial console, reset button does nothing rename initramfs to 'vmlinux-art-ramdisk' make available on TFTP server at 192.168.1.101 power board, interrupt boot execute tftpboot and bootm 0x81000000 NOTE: TFTP is not reliable due to bugged bootloader set MTU to 600 and try many times **Format of OEM firmware image:** The OEM software of EAP1200H is a heavily modified version of Openwrt Kamikaze. One of the many modifications is to the sysupgrade program. Image verification is performed simply by the successful ungzip and untar of the supplied file and name check and header verification of the resulting contents. To form a factory.bin that is accepted by OEM Openwrt build, the kernel and rootfs must have specific names... openwrt-ar71xx-generic-eap1200h-uImage-lzma.bin openwrt-ar71xx-generic-eap1200h-root.squashfs and begin with the respective headers (uImage, squashfs). Then the files must be tarballed and gzipped. The resulting binary is actually a tar.gz file in disguise. This can be verified by using binwalk on the OEM firmware images, ungzipping then untaring. Newer EnGenius software requires more checks but their script includes a way to skip them, otherwise the tar must include a text file with the version and md5sums in a deprecated format. The OEM upgrade script is at /etc/fwupgrade.sh. OKLI kernel loader is required because the OEM software expects the kernel to be no greater than 1536k and the factory.bin upgrade procedure would otherwise overwrite part of the kernel when writing rootfs. Note on PLL-data cells: The default PLL register values will not work because of the external AR8035 switch between the SOC and the ethernet port. For QCA955x series, the PLL registers for eth0 and eth1 can be see in the DTSI as 0x28 and 0x48 respectively. Therefore the PLL registers can be read from uboot for each link speed after attempting tftpboot or another network action using that link speed with `md 0x18050028 1` and `md 0x18050048 1`. The clock delay required for RGMII can be applied at the PHY side, using the at803x driver `phy-mode`. Therefore the PLL registers for GMAC0 do not need the bits for delay on the MAC side. This is possible due to fixes in at803x driver since Linux 5.1 and 5.3 Signed-off-by: Michael Pratt <mcpratt@pm.me>
* uboot-envtools: use $(AUTORELEASE) for PKG_RELEASEPaul Spooren2021-01-221-1/+1
| | | | | | | Use `$(AUTORELEASE)` variable rather than setting a PKG_RELEASE on every commit manually. Signed-off-by: Paul Spooren <mail@aparcar.org>
* ramips: mt7621: add support for Xiaomi Mi Router 4Dmytro Oz2021-01-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Xiaomi Mi Router 4 is the same as Xiaomi Mi Router 3G, except for the RAM (256Mib→128Mib), LEDs and gpio (MiNet button). Specifications: Power: 12 VDC, 1 A Connector type: barrel CPU1: MediaTek MT7621A (880 MHz, 4 cores) FLA1: 128 MiB (ESMT F59L1G81MA) RAM1: 128 MiB (ESMT M15T1G1664A) WI1 chip1: MediaTek MT7603EN WI1 802dot11 protocols: bgn WI1 MIMO config: 2x2:2 WI1 antenna connector: U.FL WI2 chip1: MediaTek MT7612EN WI2 802dot11 protocols: an+ac WI2 MIMO config: 2x2:2 WI2 antenna connector: U.FL ETH chip1: MediaTek MT7621A Switch: MediaTek MT7621A UART Serial [o] TX [o] GND [o] RX [ ] VCC - Do not connect it MAC addresses as verified by OEM firmware: use address source LAN *:c2 factory 0xe000 (label) WAN *:c3 factory 0xe006 2g *:c4 factory 0x0000 5g *:c5 factory 0x8000 Flashing instructions: 1.Create a simple http server (nginx etc) 2.set uart enable To enable writing to the console, you must reset to factory settings Then you see uboot boot, press the keyboard 4 button (enter uboot command line) If it is not successful, repeat the above operation of restoring the factory settings. After entering the uboot command line, type: setenv uart_en 1 saveenv boot 3.use shell in uart cd /tmp wget http://"your_computer_ip:80"/openwrt-ramips-mt7621-xiaomi_mir4-squashfs-kernel1.bin wget http://"your_computer_ip:80"/openwrt-ramips-mt7621-xiaomi_mir4-squashfs-rootfs0.bin mtd write openwrt-ramips-mt7621-xiaomi_mir4-squashfs-kernel1.bin kernel1 mtd write openwrt-ramips-mt7621-xiaomi_mir4-squashfs-rootfs0.bin rootfs0 nvram set flag_try_sys1_failed=1 nvram commit reboot 4.login to the router http://192.168.1.1/ Installation via Software exploit Find the instructions in the https://github.com/acecilia/OpenWRTInvasion Signed-off-by: Dmytro Oz <sequentiality@gmail.com> [commit message facelift, rebase onto shared DTSI/common device definition, bump uboot-envtools] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ath79: Add support for OpenMesh MR1750 v2Sven Eckelmann2021-01-192-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Device specifications: ====================== * Qualcomm/Atheros QCA9558 ver 1 rev 0 * 720/600/240 MHz (CPU/DDR/AHB) * 128 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 3T3R 2.4 GHz Wi-Fi (11n) * 3T3R 5 GHz Wi-Fi (11ac) * 6x GPIO-LEDs (2x wifi, 2x status, 1x lan, 1x power) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default)) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * 1x ethernet - AR8035 ethernet PHY (RGMII) - 10/100/1000 Mbps Ethernet - 802.3af POE - used as LAN interface * 12-24V 1A DC * internal antennas Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Signed-off-by: Sven Eckelmann <sven@narfation.org> [rebase, add LED migration] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* ath79: Add support for OpenMesh MR1750 v1Sven Eckelmann2021-01-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Device specifications: ====================== * Qualcomm/Atheros QCA9558 ver 1 rev 0 * 720/600/240 MHz (CPU/DDR/AHB) * 128 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 3T3R 2.4 GHz Wi-Fi (11n) * 3T3R 5 GHz Wi-Fi (11ac) * 6x GPIO-LEDs (2x wifi, 2x status, 1x lan, 1x power) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default)) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * 1x ethernet - AR8035 ethernet PHY (RGMII) - 10/100/1000 Mbps Ethernet - 802.3af POE - used as LAN interface * 12-24V 1A DC * internal antennas Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Signed-off-by: Sven Eckelmann <sven@narfation.org> [rebase, apply shared DTSI/device node, add LED migration] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-15 20:12:27 +0000