This is additional fix of c998ae7f0e.
The sysupgrade image of I-O DATA MT7621 devices manufactured by MSTC
(MitraStar Technology Corp.) faced to the booting issue. This was caused
by imcomplete extraction of large kernel image by U-Boot, and this issue
is occurred in initramfs image after fixing of sysupgrade image.
So, use lzma-loader for initramfs image to fix the issue.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Co-developed-by: Yanase Yuki <dev@zpc.sakura.ne.jp>
Signed-off-by: Yanase Yuki <dev@zpc.sakura.ne.jp>
Tested-by: Yanase Yuki <dev@zpc.sakura.ne.jp> [wn-ax2033gr]
The version inside the compat file determines, if a firmware supports
a specific device. I have not yet fully understood, how this is checked,
but it only seems to indicate which devices are supported by a specific
version of the combined vendor firmware. Devices assume that subsequent
versions, starting with the version that initially added support for a
specific device, are always compatible.
The first compat version that added support for the EP-R6 was '21001:7',
but OpenWrt did use '21001:6' before. This is why the factory image could
not be flashed using the vendor software, but only using TFTP.
The compat version has been bumped by the vendor a few times, but more
devices have been added since (e.g. ER-10X). Because OpenWrt currently
only supports the ER-X, ER-X-SFP and EP-R6, the compat version is
incremented to the version that first supported the EP-R6, which is
'21001:7'.
This allows the factory image to be flashed on EP-R6 without TFTP.
Signed-off-by: Fabian Bläse <fabian@blaese.de>
Three of the I-O DATA devices with NAND flash share a lot of
variables. Create a common definition for them to reduce duplicate
code.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The official sysupgrade images for I-O DATA devices manufactured by
MSTC (MitraStar Technology Corp.) cannot be booted normally and the
kernel panics after switching to kernel 5.4.
This commit fixes the issue by using lzma-loader.
Note:
These devices use Z-LOADER to read the kernel from NAND flash and boot
it. Z-LOADER cannot load and start plain lzma-loader, so additional
lzma-compression is needed.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Co-developed-by: Yanase Yuki <dev@zpc.sakura.ne.jp>
Signed-off-by: Yanase Yuki <dev@zpc.sakura.ne.jp>
Tested-by: Yanase Yuki <dev@zpc.sakura.ne.jp> [wn-ax2033gr]
In several Japanese routers with MT7621 SoC, the official sysupgrade
image cannot be booted properly after switching to kernel 5.4.
This commit fixes the issue by using lzma-loader.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
This device has trouble extracting big kernel from flash,
and supports LZMA compressed kernels only.
Using OpenWrt kernel loader saves us 64 KB compared to the dictionary
size limiting workaround.
Factory image sizes (commit: 5f126c541a) with "CONFIG_ALL_KMODS=y":
- original ("-d23", default): 4784188 bytes, LZMA ERROR 1
- with "-d19": 4915260, LZMA ERROR 1
- with "-d18": 4915260, diff to original: +128 KB
- with "-d17": 4980796, diff to original: +192 KB
- with this patch: 4849724, diff to original: +64 KB
To save some CPU cycle, use minimal compression ("-a0") for the LZMA
compressed uImage.
The most robust solution would use a different loader,
which reads the compressed kernel directly from the flash.
See the thread at [0] for more details!
[0] http://lists.infradead.org/pipermail/openwrt-devel/2020-April/022926.html
Signed-off-by: Szabolcs Hubai <szab.hu@gmail.com>
Tested-by: Stijn Segers <foss@volatilesystems.org>
[fixed identation]
Signed-off-by: David Bauer <mail@david-bauer.net>
ubnt er-x/xiaomi/netgear sercomm devices are known to have troble
extracting a big kernel from flash and has support for uncompressed
uimage
This commit uses uncompressed uimage with lzma-loader for these devices
to fix boot issue.
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
* ramips: increase HiWiFi HC5962 kernel partition to 4M
Increase kernel partition because 2M is insufficient for 4.19
Because the partition changes, previous version of OpenWrt cannot upgrade to this version
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
* ramips: use all reserved space for HiWiFi HC5962
Idea was from ad6c6361f9 ("ath79: enable all space on Netgear ar9344-based WNDR routers")
These stock partitons: "backup", "hw_panic", "overly", firmware_backup", "opt"
do not contain any device-specific data and can be used for /overlay, resulting in
121M space
Users should erase those partitions with command `mtd erase <partition name>` prior to
upgrading to this version
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
Co-authored-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
Increase kernel partition because 2M is insufficient for 4.19
Because the partition changes, previous version of OpenWrt cannot upgrade to this version
Signed-off-by: DENG Qingfang <dengqf6@mail2.sysu.edu.cn>
Specifications:
* SoC: MT7621AT
* RAM: 128MB
* Flash: 16MB NOR SPI flash
* WiFi: MT7615N (2.4GHz) and MT7615N (5Ghz)
* LAN: 5x1000M
* Firmware layout is Uboot with extra 96 bytes in header
* Base PCB is AP-MTKH7-0002
* LEDs Power Green,Power Orange,Internet Green,Internet Orange
* LEDs "2.4G" Green & "5G" Green connected directly to wifi module
* Buttons Reset,WPS,WIFI
Flash instruction:
Upload image via emergency recovery mode via Windows "not working with Linux"
Push and hold reset button (on the bottom of the device) until power led starts flashing (about 10 secs or so) while plugging in the power cable.
Give it ~30 seconds, to boot the recovery mode GUI
Connect your client computer to LAN1 of the device
Set your client IP address manually to 192.168.0.2 / 255.255.255.0.
Call the recovery page for the device at http://192.168.0.1
Use the provided emergency web GUI to upload and flash a new firmware to the device
MAC addresses:
lan factory 0xe000 *:55 (label)
wan factory 0xe006 *:58
2.4 GHz factory 0x0004 *:56
5.0 GHz factory 0x8004 *:57
Signed-off-by: Alan Luck <luckyhome2008@gmail.com>
This commit sync ramips source code from openwrt master.
1. ramips: gsw_mt7621: disable PORT 5 MAC RX/TX flow control by default
2. ramips: allow to set switchdev by board in ramips_set_preinit_iface
3. kernel: fix typos in KernelPackage description
* generic: support mtd-mac-address-ascii
It supports formats of both 001122334455 and 00:11:22:33:44:55
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
* ramips: add JDCloud
Co-authored-by: Yousong Zhou <yszhou4tech@gmail.com>
