When building GRUB with binutils 2.35.2 or later, an error occurs due to
a section .note.gnu.property that is placed at an offset such that
objcopy needs to pad the img file with zeros. This in turn causes the
following error: "error: Decompressor is too big.".
The fix accepted by upstream patches a python script that isn't executed
at all when building GRUB with OpenWrt buildroot. There's another patch
that patches the files generated by that python script directly, but by
including it we would deviate further from upstream. Instead of doing
that, simply bump to the latest release candidate.
As one of the fixes for the CVEs causes grub to crash on some x86
hardware using legacy BIOS when compiled with -O2, filter -O2 and
-O3 out of TARGET_CFLAGS.
Fixes the following CVEs:
- CVE-2020-14372
- CVE-2020-25632
- CVE-2020-25647
- CVE-2020-27749
- CVE-2020-27779
- CVE-2021-3418
- CVE-2021-20225
- CVE-2021-20233
Runtime-tested on x86/64.
Fixes: FS#3790
Suggested-by: Dirk Neukirchen <plntyk.lede@plntyk.name>
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Acked-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
The ZyXEL NR7101 is an 802.3at PoE powered 5G outdoor (IP68) CPE
with integrated directional 5G/LTE antennas.
Specifications:
- SoC: MediaTek MT7621AT
- RAM: 256 MB
- Flash: 128 MB MB NAND (MX30LF1G18AC)
- WiFi: MediaTek MT7603E
- Switch: 1 LAN port (Gigabiti)
- 5G/LTE: Quectel RG502Q-EA connected by USB3 to SoC
- SIM: 2 micro-SIM slots under transparent cover
- Buttons: Reset, WLAN under same cover
- LEDs: Multicolour green/red/yellow under same cover (visible)
- Power: 802.3at PoE via LAN port
The device is built as an outdoor ethernet to 5G/LTE bridge or
router. The Wifi interface is intended for installation and/or
temporary management purposes only.
UART Serial:
57600N1
Located on populated 5 pin header J5:
[o] GND
[ ] key - no pin
[o] RX
[o] TX
[o] 3.3V Vcc
Remove the SIM/button/LED cover, the WLAN button and 12 screws
holding the back plate and antenna cover together. The GPS antenna
is fixed to the cover, so be careful with the cable. Remove 4
screws fixing the antenna board to the main board, again being
careful with the cables.
A bluetooth TTL adapter is recommended for permanent console
access, to keep the router water and dustproof. The 3.3V pin is
able to power such an adapter.
MAC addresses:
OpenWrt OEM Address Found as
lan eth2 08:26:97:*:*:BC Factory 0xe000 (hex), label
wlan0 ra0 08:26:97:*:*:BD Factory 0x4 (hex)
wwan0 usb0 random
WARNING!!
ISP managed firmware might at any time update itself to a version
where all known workarounds have been disabled. Never boot an ISP
managed firmware with a SIM in any of the slots if you intend to use
the router with OpenWrt. The bootloader lock can only be disabled with
root access to running firmware. The flash chip is physically
inaccessible without soldering.
Installation from OEM web GUI:
- Log in as "supervisor" on https://172.17.1.1/
- Upload OpenWrt initramfs-recovery.bin image on the
Maintenance -> Firmware page
- Wait for OpenWrt to boot and ssh to root@192.168.1.1
- (optional) Copy OpenWrt to the recovery partition. See below
- Sysupgrade to the OpenWrt sysupgrade image and reboot
Installation from OEM ssh:
- Log in as "root" on 172.17.1.1 port 22022
- scp OpenWrt initramfs-recovery.bin image to 172.17.1.1:/tmp
- Prepare bootloader config by running:
nvram setro uboot DebugFlag 0x1
nvram setro uboot CheckBypass 0
nvram commit
- Run "mtd_write -w write initramfs-recovery.bin Kernel" and reboot
- Wait for OpenWrt to boot and ssh to root@192.168.1.1
- (optional) Copy OpenWrt to the recovery partition. See below
- Sysupgrade to the OpenWrt sysupgrade image and reboot
Copying OpenWrt to the recovery partition:
- Verify that you are running a working OpenWrt recovery image
from flash
- ssh to root@192.168.1.1 and run:
fw_setenv CheckBypass 0
mtd -r erase Kernel2
- Wait while the bootloader mirrors Image1 to Image2
NOTE: This should only be done after successfully booting the OpenWrt
recovery image from the primary partition during installation. Do
not do this after having sysupgraded OpenWrt! Reinstalling the
recovery image on normal upgrades is not required or recommended.
Installation from Z-Loader:
- Halt boot by pressing Escape on console
- Set up a tftp server to serve the OpenWrt initramfs-recovery.bin
image at 10.10.10.3
- Type "ATNR 1,initramfs-recovery.bin" at the "ZLB>" prompt
- Wait for OpenWrt to boot and ssh to root@192.168.1.1
- Sysupgrade to the OpenWrt sysupgrade image
NOTE: ATNR will write the recovery image to both primary and recovery
partitions in one go.
Booting from RAM:
- Halt boot by pressing Escape on console
- Type "ATGU" at the "ZLB>" prompt to enter the U-Boot menu
- Press "4" to select "4: Entr boot command line interface."
- Set up a tftp server to serve the OpenWrt initramfs-recovery.bin
image at 10.10.10.3
- Load it using "tftpboot 0x88000000 initramfs-recovery.bin"
- Boot with "bootm 0x8800017C" to skip the 380 (0x17C) bytes ZyXEL
header
This method can also be used to RAM boot OEM firmware. The warning
regarding OEM applies! Never boot an unknown OEM firmware, or any OEM
firmware with a SIM in any slot.
NOTE: U-Boot configuration is incomplete (on some devices?). You may
have to configure a working mac address before running tftp using
"setenv eth0addr <mac>"
Unlocking the bootloader:
If you are unebale to halt boot, then the bootloader is locked.
The OEM firmware locks the bootloader on every boot by setting
DebugFlag to 0. Setting it to 1 is therefore only temporary
when OEM firmware is installed.
- Run "nvram setro uboot DebugFlag 0x1; nvram commit" in OEM firmware
- Run "fw_setenv DebugFlag 0x1" in OpenWrt
NOTE:
OpenWrt does this automatically on first boot if necessary
NOTE2:
Setting the flag to 0x1 avoids the reset to 0 in known OEM
versions, but this might change.
WARNING:
Writing anything to flash while the bootloader is locked is
considered extremely risky. Errors might cause a permanent
brick!
Enabling management access from LAN:
Temporary workaround to allow installing OpenWrt if OEM firmware
has disabled LAN management:
- Connect to console
- Log in as "root"
- Run "iptables -I INPUT -i br0 -j ACCEPT"
Notes on the OEM/bootloader dual partition scheme
The dual partition scheme on this device uses Image2 as a recovery
image only. The device will always boot from Image1, but the
bootloader might copy Image2 to Image1 under specific conditions. This
scheme prevents repurposing of the space occupied by Image2 in any
useful way.
Validation of primary and recovery images is controlled by the
variables CheckBypass, Image1Stable, and Image1Try.
The bootloader sets CheckBypass to 0 and reboots if Image1 fails
validation.
If CheckBypass is 0 and Image1 is invalid then Image2 is copied to
Image1.
If CheckBypass is 0 and Image2 is invalid, then Image1 is copied to
Image2.
If CheckBypass is 1 then all tests are skipped and Image1 is booted
unconditionally. CheckBypass is set to 1 after each successful
validation of Image1.
Image1Try is incremented if Image1Stable is 0, and Image2 is copied to
Image1 if Image1Try is 3 or larger. But the bootloader only tests
Image1Try if CheckBypass is 0, which is impossible unless the booted
image sets it to 0 before failing.
The system is therefore not resilient against runtime errors like
failure to mount the rootfs, unless the kernel image sets CheckBypass
to 0 before failing. This is not yet implemented in OpenWrt.
Setting Image1Stable to 1 prevents the bootloader from updating
Image1Try on every boot, saving unnecessary writes to the environment
partition.
Keeping an OpenWrt initramfs recovery as Image2 is recommended
primarily to avoid unwanted OEM firmware boots on failure. Ref the
warning above. It enables console-less recovery in case of some
failures to boot from Image1.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Add support for pstore/ramoops now that DRAM content is preserved
over reboot on MT7622. On each boot, check pstore and boot to recovery
image in case there are records stored in it.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Most notably this enabled use of pstore/ramoops on MT7622 as DRAM
content is now preserved over reboot.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The previous commit increased the U-Boot environment size of the
UniFi 6 LR to 0x4000. Also change it uboot-envtools accordingly.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
mtd erase needs to be aligned with erase blocks. Use padded image size
for erasing the production volume.
As the environment grew above the current size of 0x1000 bytes by
introducing the new padding function, increase the env size to 0x4000.
While at it, clean up reset button function to work to more reliable on
that board.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Erase firmware ereas before writing to recovery or production partition
when updating them via the bootloader menu.
Signed-off-by: Chen Minqiang <ptpt52@gmail.com>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The Ubiquiti Networks UniFi 6 LR access point comes with a total of
512 MB RAM provided by 2x 8-bit DDR3 SDRAM. This combination lead to
problems with the DDR calibration on boot resulting in occasional hang
on boot. Use updated calibration binary provided by MediaTek to make
boot on that device more reliable.
The binary has also been tested on the BananaPi BPi-R64 board and that
also works just fine with the new binary.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Update the uboot-rockchip to the latest upstream release.
Remove upstreamed patches.
Tested-on: FriendlyElec NanoPi R2S
Signed-off-by: David Bauer <mail@david-bauer.net>
The Buffalo Linkstation LS421DE NAS lacks an uboot env config file.
Create it via scripts.
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
CPU: Allwinner V40 quad-core Cortex A7 @ 1.2GHz
Memory: 1GB DDR3
Storage: SDcard, native SATA
Network: 10/100/1000M ethernet, Ampak AP6212 wifi + BT
USB: 4x USB 2.0
Installation:
Use the standard sunxi installation to an SD-card.
While the board is very similar to the M2 Ultra board
(the V40 is the automotive version of the R40), as both
the u-boot and kernel supports them separately, and some
pins are different, let's add a separate device spec.
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
* check image checksums before writing to flash
* only bootmenu_0...9 are working, remove bootmenu_a entry
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
In preparation for H6 support (which requires a separate ATF blob), add
an envvar to the A64 boards specifying which ATF blob to use.
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
Default to U-Boot env in UBI if root device is not mmc block device.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Oskari Lemmela <oskari@lemmela.net>
Some of bpi-r64 boards have serial NAND attached to SPI bus.
Build U-Boot for booting from SPI-NAND.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Oskari Lemmela <oskari@lemmela.net>
Use generic functions to get env partition.
Fixes: 7043e4334f ("mediatek: mt7622: improve sysupgrade on MMC")
Signed-off-by: Oskari Lemmela <oskari@lemmela.net>
Without 'BUILD_DEVICES' defined, the U-Boot related package won't be
automatically selected when building for Toradex Apalis device.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
These devices never got officially supported in the tree thus it doesn't
make much sense to waste our infrastructure resources and keep building
dedicated U-Boot images for them.
CC: Petr Štetiar <ynezz@true.cz>
CC: Luka Perkov <luka.perkov@sartura.hr>
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
Acked-by: Petr Štetiar <ynezz@true.cz>
Add settings for fw_printenv/fw_setenv for the Ubiquiti UniFi 6 LR
when running OpenWrt's version of U-Boot. The settings should work
equally with the unmodified version, but that has not yet been
tested.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Add U-Boot build for the Ubiquiti Networks UniFi 6 LR access point.
This allows updating the bootchain to modern ARM Trusted Firmware 2.4
and U-Boot 2021.04 while keeping as much of the existing flash layout
as possible (u-boot-env, factory and eeprom partitions are retained),
gaining robust recovery vs. production dual-boot mechanism.
Add info for the Winbond W25Q512JV SPI NOR flash used in the device
and wait for GPIOs to settle after reset before checking for reset
button.
I2C connected LED controller is not supported yet.
Writing large amounts of data to SPI flash currently doesn't work due
to watchdog timeout causing reset before data write completes.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Use bl3 size of 0xa0000 instead of 0x80000 in NOR flash.
This results in bl3 ending at 0xc0000 which is where the legacy
bootchain typically puts U-Boot environment.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Now that we can create an alternate configuration file, add two
wrapper scripts for simple access to it using the alternate
alternate application names `fw_printsys' and `fw_setsys'.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Most (all?) of the realtek devices have two u-boot config partitions
with a different set of variables in each. The U-Boot shell provides
two sets of apps to manipulate these:
printenv- print environment variables
printsys- printsys - print system information variables
saveenv - save environment variables to persistent storage
savesys - savesys - save system information variables to persistent storage
setenv - set environment variables
setsys - setsys - set system information variables
Add support for multiple ubootenv configuration types, allowing
more than one configuration file.
Section names are not suitable for naming the different
configurations since each file can be the result of multiple sections
in case of backup partitions.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Now that sdcard.gz image contains everything needed to boot straight
into production image, no longer force booting into recovery image on
first boot by removing the logic which implemented that.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
* 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>
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>
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>
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>
Remove unneeded delcarations form package Makefile now that everything
comes from github.com/mtk-openwrt upstream.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
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>
* 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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 84bc7d31e0 ("tfa-layerscape: don't build fiptool").
Fixes: f59d7aab2a ("layerscape: add ddr-phy package")
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
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>
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>
This reverts commit 50a5a8993d 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
