While the latest version of 19.07 release is usable,
the current master is unbootable on the device in a normal way.
"Normal way" installations includes:
- sysupgrade (e.g. from 19.07)
- RESET button recovery with Ron Curry's (Wingspinner) UBoot image
(10.10.10.3 + "Kernal.bin")
- RESET button recovery with original U-Boot
(10.10.10.254 + "kernel")
One could flash and boot the latest master sysupgrade image successfully
with serial access to the device. But a sysupgrade from this state still
breaks the U-Boot and soft-bricks the device.
Signed-off-by: Szabolcs Hubai <szab.hu@gmail.com>
shellcheck recommends || and && over "-a" and "-o" because the
latter are not well defined.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The hardware random number generator driver for bcm63xx was merged with
the one used by the Raspberry Pi. Now this driver is lost.
Reenable the HW_RANDOM kernel config with the new driver.
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
[refresh kernel config]
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
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>
Instead of taking the input of one temperature sensor (temp1), the
script takes into account three temperature sensors to control the
PWM of the cooling fan.
temp1 -> placed on main board
temp2 -> placed on main board
temp3 -> placed on or close to chipset
All three temperatures give valid input for the PWM of the fan on
NSA310 and are actually changing.
Tested on two NSA310.
Signed-off-by: Thomas Beckler <thomas.beckler@hotmail.com>
Reviewed-by: Alberto Bursi <bobafetthotmail@gmail.com>
[commit title/message facelift, code cleanup]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Although provided in separate zip archives, the firmwares for EU
and RU version are byte-identical. This adds the missing ID compared
to the support-list in the vendor firmware.
Note (since I checked it anyway):
Partitions and support list are unchanged for all three existing
firmware versions:
* 20200721-rel40773
* 20201029-rel43238
* 20201120-rel50399
Signed-off-by: Alexey Kunitskiy <alexey.kv@gmail.com>
[rewrite commit message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
FRITZ!Box 7412 loads the firmware for fast ethernet PHY and mii is
more accurate in this case.
Gmii is used by Gigabit ethernet PHYs.
Signed-off-by: Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
Reviewed-by: Mathias Kresin <dev@kresin.me>
[minor commit title/message adjustments]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This replaces a full-text BSD clause by the corresponding SPDX
identifier.
This should make it easier to identify the license both by humans
and machines.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This replaces several full-text and abbreviated licenses found in
DTS files by the corresponding SPDX identifiers.
This should make it easier to identify the license both by humans
and machines.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
UniElec U7621-01 is a router platform board, the smaller model of
the U7621-06.
The device has the following specifications:
- MT7621AT (880 MHz)
- 256 of RAM (DDR3)
- 16 MB of FLASH (SPI NOR)
- 5x 1 Gbps Ethernet (MT7621 built-in switch)
- 1x 2.4Ghz MT7603E
- 1x 5Ghz MT7612
- 1x miniPCIe slots (PCIe bus only)
- 1x miniSIM slot
- 1x USB 2.0 (uses the usb 3.0 driver)
- 8x LEDs (1x GPIO-controlled)
- 1x reset button
- 1x UART header (4-pins)
- 1x GPIO header (30-pins)
- 1x DC jack for main power (12 V)
The following has been tested and is working:
- Ethernet switch
- 1x 2.4Ghz MT7603E (wifi)
- 1x 5Ghz MT7612 (wifi)
- miniPCIe slots (tested with Wi-Fi cards and LTE modem cards)
- miniSIM slot (works with normal size simcard)
- sysupgrade
- reset button
Installation:
This board has no locked down bootloader. The seller can be asked to
install openwrt v18.06, so upgrades are standard sysupgrade method.
Recovery:
This board contains a Chinese, closed-source bootloader called Breed
(Boot and Recovery Environment for Embedded Devices). Breed supports web
recovery and to enter it, you keep the reset button pressed for around
5 seconds during boot. Your machine will be assigned an IP through DHCP
and the router will use IP address 192.168.1.1. The recovery website is
in Chinese, but is easy to use. Click on the second item in the list to
access the recovery page, then the second item on the next page is where
you select the firmware. In order to start the recovery, you click the
button at the bottom.
LEDs list (left to right):
- ESW_P0_LED_0
- ESW_P1_LED_0
- ESW_P2_LED_0
- ESW_P3_LED_0
- ESW_P4_LED_0
- CTS2_N (GPIO10, configured as "status" LED)
- LED_WLAN# (connected with pin 44 in wifi1 slot)
Signed-off-by: David Bentham <db260179@gmail.com>
[add DEVICE_VARIANT, fix DEVICE_PACKAGES, remove &gpio]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Port device support for Meraki MR12 from the ar71xx target to ath79.
Specifications:
- SoC: AR7242-AH1A CPU
- RAM: 64MiB (NANYA NT5DS32M16DS-5T)
- NOR Flash: 16MiB (MXIC MX25L12845EMI-10G)
- Ethernet: 1 x PoE Gigabit Ethernet Port (SoC MAC + AR8021-BL1E PHY)
- Ethernet: 1 x 100Mbit port (SoC MAC+PHY)
- Wi-Fi: Atheros AR9283-AL1A (2T2R, 11n)
Installation:
1. Requires TFTP server at 192.168.1.101, w/ initramfs & sysupgrade .bins
2. Open shell case
3. Connect a USB->TTL cable to headers furthest from the RF shield
4. Power on the router; connect to U-boot over 115200-baud connection
5. Interrupt U-boot process to boot Openwrt by running:
setenv bootcmd bootm 0xbf0a0000; saveenv;
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin;
bootm 0c00000;
6. Copy sysupgrade image to /tmp on MR12
7. sysupgrade /tmp/<filename-of-sysupgrade>.bin
Notes:
- kmod-owl-loader is still required to load the ART partition into the
driver.
- The manner of storing MAC addresses is updated from ar71xx; it is
at 0x66 of the 'config' partition, where it was discovered that the
OEM firmware stores it. This is set as read-only. If you are
migrating from ar71xx and used the method mentioned above to
upgrade, use kmod-mtd-rw or UCI to add the MAC back in. One more
method for doing this is described below.
- Migrating directly from ar71xx has not been thoroughly tested, but
one method has been used a couple of times with good success,
migrating 18.06.2 to a full image produced as of this commit. Please
note that these instructions are only for experienced users, and/or
those still able to open their device up to flash it via the serial
headers should anything go wrong.
1) Install kmod-mtd-rw and uboot-envtools
2) Run `insmod mtd-rw.ko i_want_a_brick=1`
3) Modify /etc/fw_env.config to point to the u-boot-env partition.
The file /etc/fw_env.config should contain:
# MTD device env offset env size sector size
/dev/mtd1 0x00000 0x10000 0x10000
See https://openwrt.org/docs/techref/bootloader/uboot.config
for more details.
4) Run `fw_printenv` to verify everything is correct, as per the
link above.
5) Run `fw_setenv bootcmd bootm 0xbf0a0000` to set a new boot address.
6) Manually modify /lib/upgrade/common.sh's get_image function:
Change ...
cat "$from" 2>/dev/null | $cmd
... into ...
(
dd if=/dev/zero bs=1 count=$((0x66)) ; # Pad the first 102 bytes
echo -ne '\x00\x18\x0a\x12\x34\x56' ; # Add in MAC address
dd if=/dev/zero bs=1 count=$((0x20000-0x66-0x6)) ; # Pad the rest
cat "$from" 2>/dev/null
) | $cmd
... which, during the upgrade process, will pad the image by
128K of zeroes-plus-MAC-address, in order for the ar71xx's
firmware partition -- which starts at 0xbf080000 -- to be
instead aligned with the ath79 firmware partition, which
starts 128K later at 0xbf0a0000.
7) Copy the sysupgrade image into /tmp, as above
8) Run `sysupgrade -F /tmp/<sysupgrade>.bin`, then wait
Again, this may BRICK YOUR DEVICE, so make *sure* to have your
serial cable handy.
Signed-off-by: Martin Kennedy <hurricos@gmail.com>
[add LED migration and extend compat message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Specifications:
- SoC: MediaTek MT7688AN
- RAM: 128 MB
- Flash: 32 MB
- Ethernet: 5x 10/100 (1x WAN, 4x LAN)
- Wireless: built in 2.4GHz (bgn)
- USB: 1x USB 2.0 port
- Buttons: 1x Reset
- LEDs: 1x (WiFi)
Flash instructions:
- Configure TFTP server with IP address 10.10.10.3
- Name the firmware file as firmware.bin
- Connect any Ethernet port to the TFTP server's LAN
- Choose option 2 in U-Boot
- Alternatively choose option 7 to upload firmware to the built-in
web server
MAC addresses as verified by OEM firmware:
use address source
2g *:XX factory 0x4
LAN *:XX+1 factory 0x28
WAN *:XX+1 factory 0x2e
Notes:
This board is ostensibly a module containing the MediaTek MT7688AN SoC,
128 MB DDR2 SDRAM and 32 MB flash storage. The SoC can be operated in
IoT Gateway Mode or IoT Device Mode.
From some vendors the U-Boot that comes installed operates on UART 2
which is inaccessible in gateway mode and operates unreliably in the
Linux kernel when using more than 64 MB of RAM. For those, updating
U-Boot is recommended.
Signed-off-by: Ewan Parker <ewan@ewan.cc>
[add WLAN to 01_leds]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The license folder is a core part of OpenWrt and all GPL-2.0 licensed.
Use SPDX license tags to allow machines to check licenses.
Signed-off-by: Paul Spooren <mail@aparcar.org>
[rebase, keep some Copyright lines, sharpen commit message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Ran update_kernel.sh in a fresh clone without any existing toolchains.
Removed upstreamed patches:
imx6: 303-ARM-dts-imx6qdl-gw52xx-fix-duplicate-regulator-namin.patch
Build system: x86_64
Build-tested: ipq806x/R7800, bcm27xx/bcm2711
Run-tested: ipq806x/R7800
No dmesg regressions, everything functional
Signed-off-by: John Audia <graysky@archlinux.us>
Commit 7c8c4f1be6 ("hostapd: fix P2P group information processing
vulnerability") was missing the actual patch for the vulnerability.
Fixes: 7c8c4f1be6 ("hostapd: fix P2P group information processing vulnerability")
Signed-off-by: Petr Štetiar <ynezz@true.cz>
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>
The PCI device ID detected by the wifi drivers on devices using a fallback
SPROM is wrong. Currently the chipnum is used for this parameter.
Most SSB based Broadcom wifi chips are 2.4 and 5GHz capable. But on
devices without a physical SPROM, the only one way to detect if the device
suports both bands or only the 5GHz band, is by reading the device ID from
the fallback SPROM.
In some devices, this may lead to a non working wifi on a 5GHz-only card,
or in the best case a working 2.4GHz-only in a dual band wifi card.
The offset for the deviceid in SSB SPROMs is 0x0008, whereas in BCMA is
0x0060. This is true for any SPROM version.
Override the PCI device ID with the one defined at the fallback SPROM, to
detect the correct wifi card model and allow using the 5GHz band if
supported.
The patch has been tested with the following wifi radios:
BCM43222: b43: both 2.4/5GHz working
brcm-wl: both 2.4/5GHz working
BCM43225: b43: 2.4GHz, working
brcmsmac: working
brcm-wl: it lacks support
BCM43217: b43: 2.4GHz, working
brcmsmac: it lacks support
brcm-wl: it lacks support
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
[amend commit description, rework patch to avoid using a new global variable
and keep ssb sprom extraction code as close to ssb/pci.c as possible]
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
New upstream changes extract more SPROM values and fix the antenna gain.
These changes can be found in linux drivers/ssb/pci.c.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
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>
All modification made by update_kernel.sh in a fresh clone without
existing toolchains.
Build-tested: bcm27xx/bcm2711, ipq806x/R7800,
Run-tested: ipq806x/R7800
No dmesg regressions, everything functional
Signed-off-by: John Audia <graysky@archlinux.us>
If the driver uses .sta_add, station entries are only uploaded after the sta
is in assoc state. Fix early station rate table updates by deferring them
until the sta has been uploaded
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Add statistics to ethtool. The statistics can be useful to
debug network issues.
The code is backported from mainline ag71xx.c driver.
Signed-off-by: Leon Leijssen <leon.git@leijssen.info>
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>
Hardware
--------
Atheros AR7241
16M SPI-NOR
64M DDR2
Atheros AR9283 2T2R b/g/n
2x Fast Ethernet (built-in)
Installation
------------
Transfer the Firmware update to the device using SCP.
Install using fwupdate.real -m <openwrt.bin> -d
Signed-off-by: David Bauer <mail@david-bauer.net>
Enable support for the Ubiquiti UniFi Outdoor+ RF filter via
device-tree. The old way of using platform data is not required anymore,
as it was only used on the now removed ar71xx target.
Signed-off-by: David Bauer <mail@david-bauer.net>
Replace with sed as done elsewhere.
Fixes error with at least btrfs-progs:
Package '@LIBSELINUX@', required by 'mount', not found
Package '@LIBCRYPTSETUP@', required by 'mount', not foun
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Currently it's not possible to boot the device with just initramfs image
without additional effort as the initramfs image doesn't contain device
tree. Fix it by producing FIT based image which could be booted with
following commands:
setenv bootargs earlyprintk console=ttyS0,115200
tftpboot ${kernel_addr_r} openwrt-mvebu-cortexa9-cznic_turris-omnia-initramfs-kernel.bin
bootm ${kernel_addr_r}
Acked-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Reviewed-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Switch to the normal tarball instead of the codeload generated one. The
latter has the potential to change hashes based on changes in the repo.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Packages that are in-tree only often lack a PKG_VERSION and only use the
PKG_RELEASE to mark changes. Using COMMITCOUNT/AUTORELEASE variables
causes an issue as both variables are empty during the metadata DUMP
phase.
Instead of leaving these variables empty and causing an error message
like below, set the variables to 0 during dumping. On actual building
the variable is evaluated causing in a value above 0.
ERROR: please fix package/utils/px5g-wolfssl/Makefile - \
see logs/package/utils/px5g-wolfssl/dump.txt for details
Makefile:48: *** Package/px5g-wolfssl is missing the VERSION field. Stop.
Reported-by: Daniel Golle <daniel@makrotopia.org>
Reported-by: Stijn Segers <foss@volatilesystems.org>
Reported-by: Stijn Tintel <stijn@linux-ipv6.be>
Signed-off-by: Paul Spooren <mail@aparcar.org>
Upon boot it now prints:
NOTICE: BL1: v2.4(release):OpenWRT v2.4-1 (espressobin-v3-v5-1gb-2cs) (Marvell-devel-18.12.0)
Signed-off-by: Andre Heider <a.heider@gmail.com>
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>
