2012-08-29 10:37:32 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
#
|
|
|
|
|
# Copyright (C) 2011-2012 OpenWrt.org
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
[ -e /etc/config/ubootenv ] && exit 0
|
|
|
|
|
|
|
|
|
|
touch /etc/config/ubootenv
|
|
|
|
|
|
|
|
|
|
. /lib/uboot-envtools.sh
|
|
|
|
|
. /lib/functions.sh
|
|
|
|
|
|
2017-05-12 20:36:07 +00:00
|
|
|
board=$(board_name)
|
2012-08-29 10:37:32 +00:00
|
|
|
|
|
|
|
|
case "$board" in
|
2018-02-26 22:00:07 +00:00
|
|
|
alfa-network,ac1200rm|\
|
2019-03-10 00:28:33 +00:00
|
|
|
alfa-network,awusfree1|\
|
2019-11-03 11:17:52 +00:00
|
|
|
alfa-network,quad-e4g|\
|
2019-10-30 20:48:09 +00:00
|
|
|
alfa-network,r36m-e4g|\
|
2019-03-10 00:28:33 +00:00
|
|
|
alfa-network,tube-e4g)
|
2018-02-26 21:24:26 +00:00
|
|
|
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x1000"
|
|
|
|
|
;;
|
2019-07-03 21:22:42 +00:00
|
|
|
allnet,all0256n-4m|\
|
|
|
|
|
allnet,all0256n-8m|\
|
|
|
|
|
allnet,all5002)
|
2018-02-26 21:24:26 +00:00
|
|
|
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x10000" "0x10000"
|
|
|
|
|
;;
|
2019-07-03 21:22:42 +00:00
|
|
|
buffalo,wsr-1166dhp|\
|
|
|
|
|
buffalo,wsr-600dhp|\
|
|
|
|
|
mediatek,linkit-smart-7688|\
|
|
|
|
|
samknows,whitebox-v8|\
|
|
|
|
|
xiaomi,miwifi-nano|\
|
|
|
|
|
zbtlink,zbt-wg2626)
|
2013-02-02 17:01:52 +00:00
|
|
|
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x10000"
|
|
|
|
|
;;
|
ramips: add support for Linksys EA7500 v2
The Linksys EA7500 v2 is advertised as AC1900, but its internal
hardware is AC2600 capable.
Hardware
--------
SoC: Mediatek MT7621AT (880 MHz, 2 cores 4 threads)
RAM: 256M (Nanya NT5CC128M16IP-DI)
FLASH: 128MB NAND (Macronix MX30LF1G18AC-TI)
ETH: 5x 10/100/1000 Mbps Ethernet (MT7530)
WIFI:
- 2.4GHz: 1x MT7615N (4x4:4)
- 5GHz: 1x MT7615N (4x4:4)
- 4 antennas: 3 external detachable antennas and 1 internal
USB:
- 1x USB 3.0
- 1x USB 2.0
BTN:
- 1x Reset button
- 1x WPS button
LEDS:
- 1x White led (Power)
- 6x Green leds (link lan1-lan4, link wan, wps)
- 5x Orange leds (act lan1-lan4, act wan) (working but unmodifiable)
Everything works correctly.
Installation
------------
The “factory” openwrt image can be flashed directly from OEM stock
firmware. After the flash the router will reboot automatically.
However, due to the dual boot system, the first installation could fail
(if you want to know why, read the footnotes).
If the flash succeed and you can reach OpenWrt through the web
interface or ssh, you are done.
Otherwise the router will try to boot 3 times and then will
automatically boot the OEM firmware (don’t turn off the router.
Simply wait and try to reach the router through the web interface
every now and then, it will take few minutes).
After this, you should be back in the OEM firmware.
Now you have to flash the OEM Firmware over itself using the OEM web
interface (I tested it using the FW_EA7500v2_2.0.8.194281_prod.img
downloaded from the Linksys website).
When the router reboots flash the “factory” OpenWrt image and this
time it should work.
After the OpenWrt installation you have to use the sysupgrade image
for future updates.
Restore OEM Firmware
--------------------
After the OpenWrt flash, the OEM firmware is still stored in the
second partition thanks to the dual boot system.
You can switch from OpenWrt to OEM firmware and vice-versa failing
the boot 3 times in a row:
1) power on the router
2) wait 15 seconds
3) power off the router
4) repeat steps 1-2-3 twice more.
5) power on the router and you should be in the “other” firmware
If you want to completely remove OpenWrt from your router, switch to
the OEM firmware and then flash OEM firmware from the web interface
as a normal update.
This procedure will overwrite the OpenWrt partition.
Footnotes
---------
The Linksys EA7500-v2 has a dual boot system to avoid bricks.
This system works using 2 pair of partitions:
1) "kernel" and "rootfs"
2) "alt_kernel" and "alt_rootfs".
After 3 failed boot attempts, the bootloader tries to boot the other
pair of partitions and so on.
This system is managed by the bootloader, which writes a bootcount in
the s_env partition, and if successfully booted, the system add a
"zero-bootcount" after the previous value.
A system update performed from OEM firmware, writes the firmware on the
other pair of partitions and sets the bootloader to boot the new pair
of partitions editing the “boot_part” variable in the bootloader vars.
Effectively it's a quick and safe system to switch the selected boot
partition.
Another way to switch the boot partition is:
1) power on the router
2) wait 15 seconds
3) power off the router
4) repeat steps 1-2-3 twice more.
5) power on the router and you should be in the “other” firmware
In this OpenWrt port, this dual boot system is partially working
because the bootloader sets the right rootfs partition in the cmdline
but unfortunately OpenWrt for ramips platform overwrites the cmdline
so is not possible to detect the right rootfs partition.
Because all of this, I preferred to simply use the first pair of
partitions and set read-only the other pair.
However this solution is not optimal because is not possible to know
without opening the case which is the current booted partition.
Let’s take for example a router booting the OEM firmware from the first
pair of partitions. If we flash the OpenWrt image, it will be written
on the second pair. In this situation the router will bootloop 3 times
and then will automatically come back to the first pair of partitions
containg the OEM firmware.
In this situation, to flash OpenWrt correctly is necessary to switch
the booting partition, flashing again the OEM firmware over itself.
At this point the OEM firmware is on both pair of partitions but the
current booted pair is the second one.
Now, flashing the OpenWrt factory image will write the firmware on
the first pair and then will boot correctly.
If this limitation in the ramips platform about the cmdline will be
fixed, the dual boot system can also be implemented in OpenWrt with
almost no effort.
Signed-off-by: Davide Fioravanti <pantanastyle@gmail.com>
Co-Developed-by: Jackson Lim <jackcolentern@gmail.com>
Signed-off-by: Jackson Lim <jackcolentern@gmail.com>
2020-05-11 23:27:50 +00:00
|
|
|
linksys,ea7500-v2|\
|
2020-05-30 09:18:50 +00:00
|
|
|
xiaomi,mi-router-ac2100|\
|
ramips: add support for Xiaomi Mi Router 3 Pro
Hardware:
CPU: MediaTek MT7621AT (2x880MHz)
RAM: 512MB DDR3
FLASH: 256MB NAND
WiFi: 2.4GHz 4x4 MT7615 b/g/n (Needs driver, See Issues!)
WiFI: 5GHz 4x4 MT7615 a/n/ac (Needs driver, See Issues!)
USB: 1x 3.0
ETH: 1x WAN 10/100/1000 3x LAN 10/100/1000
LED: Power/Status
BTN: RESET
UART: 115200 8n1
Partition layout and boot:
Stock Xiaomi firmware has the MTD split into (among others)
- kernel0 (@0x200000)
- kernel1 (@0x600000)
- rootfs0
- rootfs1
- overlay (ubi)
Xiaomi uboot expects to find kernels at 0x200000 & 0x600000
referred to as system 1 & system 2 respectively.
a kernel is considered suitable for handing control over
if its linux magic number exists & uImage CRC are correct.
If either of those conditions fail, a matching sys'n'_fail flag
is set in uboot env & a restart performed in the hope that the
alternate kernel is okay.
If neither kernel checksums ok and both are marked failed, system 2
is booted anyway.
Note uboot's tftp flash install writes the transferred
image to both kernel partitions.
Installation:
Similar to the Xiaomi MIR3G, we keep stock Xiaomi firmware in
kernel0 for ease of recovery, and install OpenWRT into kernel1 and
after.
The installation file for OpenWRT is a *squashfs-factory.bin file that
contains the kernel and a ubi partition. This is flashed as follows:
nvram set flag_try_sys1_failed=1
nvram set flag_try_sys2_failed=0
nvram commit
dd if=factory.bin bs=1M count=4 | mtd write - kernel1
dd if=factory.bin bs=1M skip=4 | mtd write - rootfs0
reboot
Reverting to stock:
The part of stock firmware we've kept in kernel0 allows us to run stock
recovery, which will re-flash stock firmware from a *.bin file on a USB.
For this we do the following:
fw_setenv flag_try_sys1_failed 0
fw_setenv flag_try_sys2_failed 1
reboot
After reboot the LED status light will blink red, at which point pressing
the 'reset' button will cause stock firmware to be installed from USB.
Issues:
OpenWRT currently does not have support for the MT7615 wifi chips. There is
ongoing work to add mt7615 support to the open source mt76 driver. Until that
support is in place, there are closed-source kernel modules that can be used.
See: https://forum.openwrt.org/t/support-for-xiaomi-wifi-r3p-pro/20290/170
Signed-off-by: Ozgur Can Leonard <ozgurcan@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
[02_network remaps, Added link to notes]
2019-03-05 08:41:37 +00:00
|
|
|
xiaomi,mir3p|\
|
2020-04-23 02:50:21 +00:00
|
|
|
xiaomi,mir3g|\
|
|
|
|
|
xiaomi,redmi-router-ac2100)
|
ramips: improve Xiaomi Mi Router 3G support
This commit improves support for the Xiaomi Mi Router 3G originally
added in commit 6e283cdc0da25928f8148805ebef7f8f2b769ee8
Improvements:
- Remove software watchdog as hardware watchdog now working as per
commit 3fbf3ab44f5cebb22e30a4c8681b13341feed6a6 for all mt7621
devices.
- Reset button polarity corrected - length of press determines reboot
(short press) vs. reset to defaults (long press) behaviour.
- Enable GPIO amber switch port LEDs on board rear - lit indicates 1Gbit
link and blink on activity. Green LEDs driven directly by switch
indicating any link speed and tx activity.
- USB port power on/off GPIO exposed as 'usbpower'
- Add access to uboot environment settings for checking/setting uboot
boot order preference from user space.
Changes:
- Front LED indicator is physically made of independent Yellow/Amber,
Red & Blue LEDs combined via a plastic 'lightpipe' to a front panel
indicator, hence the colour behaviour is similar to an RGB LED. RGB
LEDs are not supported at this time because they produce colour results
that do not then match colour labels, e.g. enabling 'mir3g:red' and
'mir3g:blue' would result in a purple indicator and we have no such
label for purple.
The yellow, red & blue LEDs have been split out as individual yellow,
red & blue status LEDs, with yellow being the default status LED as
before and with red's WAN and blue's USB default associations removed.
- Swapped order of vlan interfaces (eth0.1 & eth0.2) to match stock vlan
layout. eth0.1 is LAN, eth0.2 is WAN
- Add 'lwlll' vlan layout to mt7530 switch driver to prevent packet
leakage between kernel switch init and uci swconfig
uboot behaviour & system 'recovery'
uboot expects to find bootable kernels at nand addresses 0x200000 &
0x600000 known by uboot as "system 1" and "system 2" respectively.
uboot chooses which system to hand control to based on 3 environment
variables: flag_last_success, flag_try_sys1_failed & flag_try_sys2_failed
last_success represents a preference for a particular system and is set
to 0 for system 1, set to 1 for system 2. last_success is considered *if*
and only if both try_sys'n'_failed flags are 0 (ie. unset) If *either*
failed flags are set then uboot will attempt to hand control to the
non failed system. If both failed flags are set then uboot will check
the uImage CRC of system 1 and hand control to it if ok. If the uImage
CRC of system is not ok, uboot will hand control to system 2
irrespective of system 2's uImage CRC.
NOTE: uboot only ever sets failed flags, it *never* clears them. uboot
sets a system's failed flag if that system's was selected for boot but
the uImage CRC is incorrect.
Fortunately with serial console access, uboot provides the ability to
boot an initramfs image transferred via tftp, similarly an image may
be flashed to nand however it will flash to *both* kernels so a backup
of stock kernel image is suggested. Note that the suggested install
procedure below set's system 1's failed flag (stock) thus uboot ignores
the last_success preference and boots LEDE located in system 2.
Considerable thought has gone into whether LEDE should replace both
kernels, only one (and which one) etc. LEDE kernels do not include a
minimal rootfs and thus unlike the stock kernel cannot include a
method of controlling uboot environment variables in the event of
rootfs mount failure. Similarly uboot fails to provide an external
mechanism for indicating boot system failure.
Installation - from stock.
Installation through telnet/ssh:
- copy lede-ramips-mt7621-mir3g-squashfs-kernel1.bin and
lede-ramips-mt7621-mir3g-squashfs-rootfs0.bin to usb disk or wget it
from LEDE download site to /tmp
- switch to /extdisks/sda1/ (if copied to USB drive) or to /tmp if
wgetted from LEDE download site
- run: mtd write lede-ramips-mt7621-mir3g-squashfs-kernel1.bin kernel1
- run: mtd write lede-ramips-mt7621-mir3g-squashfs-rootfs0.bin rootfs0
- run: nvram set flag_try_sys1_failed=1
- run: nvram commit
- run: reboot
Recovery - to stock.
Assuming you used the above installation instructions you will have a
stock kernel image in system 1. If it can be booted then it may be used
to perform a stock firmware recovery, thus erasing LEDE completely. From
a 'working' LEDE state (even failsafe)
Failsafe only:
- run: mount_root
- run: sh /etc/uci-defaults/30_uboot-envtools
Then do the steps for 'All'
All:
- run: fw_setenv flag_try_sys2_failed 1
- run: reboot
The board will reboot into system 1 (stock basic kernel) and wait with
system red light slowly blinking for a FAT formatted usb stick with a
recovery image to be inserted. Press and hold the reset button for
around 1 second. Status LED will turn yellow during recovery and blue
when recovery complete.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
2017-09-25 19:41:13 +00:00
|
|
|
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x20000"
|
|
|
|
|
;;
|
2013-02-02 17:01:52 +00:00
|
|
|
esac
|
|
|
|
|
|
2012-08-29 10:37:32 +00:00
|
|
|
config_load ubootenv
|
|
|
|
|
config_foreach ubootenv_add_app_config ubootenv
|
|
|
|
|
|
|
|
|
|
exit 0
|
