2021-01-19 17:48:48 +00:00
|
|
|
#include "mt7621_xiaomi_nand_128m.dtsi"
|
2017-08-12 14:56:11 +00:00
|
|
|
|
|
|
|
|
/ {
|
2020-12-08 14:05:47 +00:00
|
|
|
compatible = "xiaomi,mi-router-3g", "mediatek,mt7621-soc";
|
2017-08-12 14:56:11 +00:00
|
|
|
model = "Xiaomi Mi Router 3G";
|
|
|
|
|
|
2018-07-16 08:27:22 +00:00
|
|
|
aliases {
|
2019-03-19 07:04:27 +00:00
|
|
|
led-boot = &led_status_yellow;
|
|
|
|
|
led-failsafe = &led_status_red;
|
2018-08-28 04:54:27 +00:00
|
|
|
led-running = &led_status_blue;
|
2019-03-19 07:04:27 +00:00
|
|
|
led-upgrade = &led_status_yellow;
|
2020-03-18 15:38:58 +00:00
|
|
|
label-mac-device = &gmac0;
|
2018-07-16 08:27:22 +00:00
|
|
|
};
|
|
|
|
|
|
2018-12-30 11:42:53 +00:00
|
|
|
leds {
|
2017-08-12 14:56:11 +00:00
|
|
|
compatible = "gpio-leds";
|
|
|
|
|
|
2019-03-19 07:04:27 +00:00
|
|
|
led_status_red: status_red {
|
2020-09-27 17:40:51 +00:00
|
|
|
label = "red:status";
|
2020-03-03 21:22:24 +00:00
|
|
|
gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
|
2017-08-12 14:56:11 +00:00
|
|
|
};
|
|
|
|
|
|
2018-07-16 08:27:22 +00:00
|
|
|
led_status_blue: status_blue {
|
2020-09-27 17:40:51 +00:00
|
|
|
label = "blue:status";
|
2020-03-03 21:22:24 +00:00
|
|
|
gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
|
2017-08-12 14:56:11 +00:00
|
|
|
};
|
|
|
|
|
|
2019-03-19 07:04:27 +00:00
|
|
|
led_status_yellow: status_yellow {
|
2020-09-27 17:40:51 +00:00
|
|
|
label = "yellow:status";
|
2020-03-03 21:22:24 +00:00
|
|
|
gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
|
2017-08-12 14:56:11 +00:00
|
|
|
};
|
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
|
|
|
|
|
|
|
|
wan_amber {
|
2020-09-27 17:40:51 +00:00
|
|
|
label = "amber:wan";
|
2020-03-03 21:22:24 +00:00
|
|
|
gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
|
2020-03-18 15:38:58 +00:00
|
|
|
linux,default-trigger = "dsa-0.0:01:1Gbps";
|
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
|
|
|
};
|
|
|
|
|
|
|
|
|
|
lan1_amber {
|
2020-09-27 17:40:51 +00:00
|
|
|
label = "amber:lan1";
|
2020-03-03 21:22:24 +00:00
|
|
|
gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
|
2020-03-18 15:38:58 +00:00
|
|
|
linux,default-trigger = "dsa-0.0:03:1Gbps";
|
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
|
|
|
};
|
|
|
|
|
|
|
|
|
|
lan2_amber {
|
2020-09-27 17:40:51 +00:00
|
|
|
label = "amber:lan2";
|
2020-03-03 21:22:24 +00:00
|
|
|
gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
|
2020-03-18 15:38:58 +00:00
|
|
|
linux,default-trigger = "dsa-0.0:02:1Gbps";
|
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
|
|
|
};
|
2017-08-12 14:56:11 +00:00
|
|
|
};
|
|
|
|
|
|
2019-03-19 07:04:27 +00:00
|
|
|
reg_usb_vbus: regulator {
|
2018-06-07 16:33:57 +00:00
|
|
|
compatible = "regulator-fixed";
|
|
|
|
|
regulator-name = "usb_vbus";
|
|
|
|
|
regulator-min-microvolt = <5000000>;
|
|
|
|
|
regulator-max-microvolt = <5000000>;
|
2020-03-03 21:22:24 +00:00
|
|
|
gpio = <&gpio 12 GPIO_ACTIVE_HIGH>;
|
2018-06-07 16:33:57 +00:00
|
|
|
enable-active-high;
|
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
|
|
|
};
|
2018-06-07 16:33:57 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
&xhci {
|
|
|
|
|
vbus-supply = <®_usb_vbus>;
|
2017-08-12 14:56:11 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
&pcie {
|
|
|
|
|
status = "okay";
|
2018-07-21 14:19:46 +00:00
|
|
|
};
|
2017-08-12 14:56:11 +00:00
|
|
|
|
2018-07-21 14:19:46 +00:00
|
|
|
&pcie0 {
|
|
|
|
|
wifi@0,0 {
|
|
|
|
|
compatible = "pci14c3,7603";
|
|
|
|
|
reg = <0x0000 0 0 0 0>;
|
|
|
|
|
mediatek,mtd-eeprom = <&factory 0x0000>;
|
|
|
|
|
ieee80211-freq-limit = <2400000 2500000>;
|
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
|
|
|
};
|
2018-07-21 14:19:46 +00:00
|
|
|
};
|
2017-08-12 14:56:11 +00:00
|
|
|
|
2018-07-21 14:19:46 +00:00
|
|
|
&pcie1 {
|
|
|
|
|
wifi@0,0 {
|
|
|
|
|
compatible = "pci14c3,7662";
|
|
|
|
|
reg = <0x0000 0 0 0 0>;
|
|
|
|
|
mediatek,mtd-eeprom = <&factory 0x8000>;
|
|
|
|
|
ieee80211-freq-limit = <5000000 6000000>;
|
2017-08-12 14:56:11 +00:00
|
|
|
};
|
|
|
|
|
};
|
|
|
|
|
|
2020-03-18 15:38:58 +00:00
|
|
|
&gmac0 {
|
|
|
|
|
mtd-mac-address = <&factory 0xe006>;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
&switch0 {
|
|
|
|
|
ports {
|
|
|
|
|
port@1 {
|
|
|
|
|
status = "okay";
|
|
|
|
|
label = "wan";
|
|
|
|
|
mtd-mac-address = <&factory 0xe000>;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
port@2 {
|
|
|
|
|
status = "okay";
|
|
|
|
|
label = "lan2";
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
port@3 {
|
|
|
|
|
status = "okay";
|
|
|
|
|
label = "lan1";
|
|
|
|
|
};
|
|
|
|
|
};
|
2017-08-12 14:56:11 +00:00
|
|
|
};
|
|
|
|
|
|
2019-12-22 20:26:01 +00:00
|
|
|
&state_default {
|
|
|
|
|
gpio {
|
2020-03-13 13:27:03 +00:00
|
|
|
groups = "jtag", "uart2", "uart3", "wdt";
|
|
|
|
|
function = "gpio";
|
2017-08-12 14:56:11 +00:00
|
|
|
};
|
|
|
|
|
};
|
