aboutsummaryrefslogtreecommitdiffstats
path: root/package/boot
Commit message (Collapse)AuthorAgeFilesLines
* kexec-tools: update to 2.0.21Rosen Penev2021-03-192-53/+3
| | | | | | | | | | | | | kdump was removed in 7acd257ae67b4ca94f8c23cb8bda0ee0709b9216 gdb can be used as an alternative. Remove autoreconf. It's not needed as the configure files are already generated. Remove upstreamed patch. Signed-off-by: Rosen Penev <rosenp@gmail.com>
* uboot-mediatek: don't rely in 'lzma' cmdlineDaniel Golle2021-03-182-5/+11
| | | | | | | Use 'xz --format=lzma' instead. Fixes build for mt7629. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* mediatek: Fix writing U-Boot env on Buffalo WSR-2533DHP2Hauke Mehrtens2021-03-171-1/+1
| | | | | | | This fixes writing to the U-Boot environment by making the partition writable and setting the correct flash sector size of 128K. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* uboot-mediatek: fix default environment of bpi-r64 emmcDaniel Golle2021-03-171-1/+1
| | | | | | | The emmc variant used the default environment of the sdmmc variant. Fix that. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* uboot-mediatek: bpi-r64: make use of FIT configuration selectionDaniel Golle2021-03-171-10/+16
| | | | | | | | | | | | | Allow selecting either SATA or PCIE functionality using uImage.FIT configurations and device-tree overlays. By default, PCIE1 is selected (as it has been before this change). To select SATA instead, you can do this now: fw_setenv bootconf config-mt7622-bananapi-bpi-r64-sata and reboot. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* mediatek: add support for Buffalo WSR-2533DHP2INAGAKI Hiroshi2021-03-151-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for the Buffalo WSR-2533DHP2. The device uses the Broadcom TRX image format with a special magic. To be able to boot the images or load them they have to be wrapped with different headers depending how it is loaded. There are multiple ways to install OpenWrt on this device. Boot ramdisk from U-Boot ---------------------------- This will load the image and not write it into the flash. 1. Stop boot menu with "space" key 2. Select "System Load Linux to SDRAM via TFTP." 3. Load this image: openwrt-mediatek-mt7622-buffalo_wsr-2533dhp2-initramfs-kernel.bin 4. The system boots the image Write to flash from U-Boot ----------------------------- This will load the image over tftp and directly write it into the flash. 1. Stop boot menu with "space" key 2. Select "System Load Linux Kernel then write to Flash via TFTP." 3. Load this image: openwrt-mediatek-mt7622-buffalo_wsr-2533dhp2-squashfs-factory-uboot.bin 4. The system writes this image into the flash and boots into it. Write to flash from Web UI ----------------------------- This will load the image over over the Web UI and write it into the flash 1. Open the Web UI 2. Go to "管理" -> "ファームウェア更新" 3. Select "ローカルファイル指定" and click "更新実行" 4. Load this image: openwrt-mediatek-mt7622-buffalo_wsr-2533dhp2-squashfs-factory.bin 5. The system writes this image into the flash and boots into it. Specifications ------------------- * SoC: MT7622 (4x4 2.4 GHz Wifi) * Wifi: MT7615 (4x4 5 GHz Wifi) * Flash: Winbond W29N01HZ 128MB SLC NAND * RAM 256MB * Ethernet: Realtek RTL8367S (5 x 1GBit/s, SoC via 2.5GBit/s) Co-Developed-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* uboot-mediatek: also install production image to eMMCDaniel Golle2021-03-141-2/+5
| | | | | | | Make installation to eMMC more convenient on the BPi-R64 by also copying the production image (if valid) from SD Card to eMMC. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* uboot-mediatek: select matching U-Boot for boardDaniel Golle2021-03-141-9/+15
| | | | | | | Instead of building all U-Boot variants by default, build only those needed by the selected board(s). Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* realtek: Add ZyXEL GS1900-8Hauke Mehrtens2021-03-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ZyXEL GS1900-8 is a 8 port switch without any PoE functionality or SFP ports, but otherwise similar to the other GS1900 switches. Specifications -------------- * Device: ZyXEL GS1900-8 v1.2 * SoC: Realtek RTL8380M 500 MHz MIPS 4KEc * Flash: Macronix MX25L12835F 16 MiB * RAM: Nanya NT5TU128M8GE-AC 128 MiB DDR2 SDRAM * Ethernet: 8x 10/100/1000 Mbit * LEDs: 1 PWR LED (green, not configurable) 1 SYS LED (green, configurable) 8 ethernet port status LEDs (green, SoC controlled) * Buttons: 1 on-off glide switch at the back (not configurable) 1 reset button at the right side, behind the air-vent (not configurable) 1 reset button on front panel (configurable) * Power 12V 1A barrel connector * UART: 1 serial header (JP2) with populated standard pin connector on the left side of the PCB, towards the back. Pins are labelled: + VCC (3.3V) + TX (really RX) + RX (really TX) + GND the labelling is done from the usb2serial connector's point of view, so RX/ TX are mixed up. Serial connection parameters for both devices: 115200 8N1. Installation ------------ Instructions are identical to those for the GS1900-10HP and GS1900-8HP. * Configure your client with a static 192.168.1.x IP (e.g. 192.168.1.10). * Set up a TFTP server on your client and make it serve the initramfs image. * Connect serial, power up the switch, interrupt U-boot by hitting the space bar, and enable the network: > rtk network on * Since the GS1900-10HP is a dual-partition device, you want to keep the OEM firmware on the backup partition for the time being. OpenWrt can only boot off the first partition anyway (hardcoded in the DTS). To make sure we are manipulating the first partition, issue the following commands: > setsys bootpartition 0 > savesys * Download the image onto the device and boot from it: > tftpboot 0x84f00000 192.168.1.10:openwrt-realtek-generic-zyxel_gs1900-8-initramfs-kernel.bin > bootm * Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it: > sysupgrade /tmp/openwrt-realtek-generic-zyxel_gs1900-8-squashfs-sysupgrade.bin Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* uboot-mediatek: import fix for AHCI and enable SATADaniel Golle2021-03-132-2/+26
| | | | | | | | Import patch form Frank Wunderlich <frank-w@public-files.de> to fix build of MediaTek AHCI SATA driver. Enable that driver on Bananapi BPi-R64. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* uboot-mediatek: fix build on Mac OS XDaniel Golle2021-03-131-0/+10
| | | | | | | Copy patch added to uboot-sunxi by commit 3cc57ba462 ("uboot-sunxi: add missing type __u64") also to uboot-mediatek. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* uboot-mediatek: update configs for MT7622 deviesDaniel Golle2021-03-122-4/+48
| | | | | | | * make sure USB 2.0 works (useful for UEFI-booting eg. memtest86) * include more useful U-Boot config options on BPi-R64. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* uboot-mediatek: update to 2021.04-rc3 with MediaTek's patchesDaniel Golle2021-03-1139-8847/+5711
| | | | | | | | | | | | | | MediaTek published their current U-Boot patchset on github: https://github.com/mtk-openwrt/u-boot/commits/mtksoc Import the platform patches from there (`00-mtk-*.patch`), arrange, them nicely, drop no longer needed local patches and rebase on top of U-Boot 2021.04-rc3. Tested and works well on Linksys E8450 (snand-1ddr) as well as Bananapi BPi-R64 (sdmmc-2ddr, emmc-2ddr). Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* arm-trusted-firmware-mediatek: update to 2021-03-10Daniel Golle2021-03-111-4/+8
| | | | | | | | Most prominently this adds changes which allow replacing the binary- only 'bromimage' tool by U-Boot's 'mkimage' (see previous commit). This fixes build on non-Linux and/or non-x86 platforms. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* tools: mkimage: add patches for 64-bit MediaTek BootROMDaniel Golle2021-03-111-17/+0
| | | | | | | Add patches for mkimage to allow using it instead of the binary-only 'bromimage' tool to generate bl2 for MT7622. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* arm-trusted-firmware-mediatek: fix typo SPI-SNAND -> SPI-NANDDaniel Golle2021-03-081-1/+1
| | | | Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* 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>