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 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>
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>
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>
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>
Calling netdev_reset_queue() from _stop() functions is causing sporadic kernel
panics on bcm63xx, which happen mainly on BCM6318 and BCM6328.
This reverts to the previous behaviour, which called netdev_reset_queue() from
_open() functions.
Tested on Comtrend AR-5315u (BCM6318).
Fixes: 1d6f422e34 ("bcm63xx: sync ethernet driver with net-next")
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Abort the dhcp-check based on the interface instead of the carrier
state. In cases where the interface is up but the carrier is down,
netifd won't cause a dnsmasq reload, thus dhcp won't become active
on this interface.
Signed-off-by: David Bauer <mail@david-bauer.net>
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>
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>
Signed-off-by: Tianling Shen <cnsztl@gmail.com>
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>
Signed-off-by: Tianling Shen <cnsztl@gmail.com>
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>
Signed-off-by: Tianling Shen <cnsztl@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>
