openwrt/package/boot/uboot-envtools/files/ramips

#!/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

board=$(board_name)

case "$board" in
alfa-network,ac1200rm|\
alfa-network,awusfree1|\
alfa-network,quad-e4g|\
alfa-network,r36m-e4g|\
alfa-network,tube-e4g)
	ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x1000"
	;;
all0256n-4M|\
all0256n-8M|\
all5002)
	ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x10000" "0x10000"
	;;
linkits7688|\
miwifi-nano|\
sk-wb8|\
wsr-1166|\
wsr-600|\
zbt-wg2626)
	ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x10000"
	;;
xiaomi,mir3p|\
xiaomi,mir3g)
	ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x20000"
	;;
esac

config_load ubootenv
config_foreach ubootenv_add_app_config ubootenv

exit 0
uboot-envtools: add configration for ramips devices uboot-env settings for ALL0239-3G, ALL0256N, ALL5002. Signed-off-by: Daniel Golle <dgolle@allnet.de> SVN-Revision: 33296 12 years ago			`#!/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`

treewide: use the generic board_name function Use the generic function instead ot the target specific ones. Signed-off-by: Mathias Kresin <dev@kresin.me> 7 years ago			`board=$(board_name)`
uboot-envtools: add configration for ramips devices uboot-env settings for ALL0239-3G, ALL0256N, ALL5002. Signed-off-by: Daniel Golle <dgolle@allnet.de> SVN-Revision: 33296 12 years ago
			`case "$board" in`
ramips: add U-Boot env support for ALFA Network AC1200RM Signed-off-by: Piotr Dymacz <pepe2k@gmail.com> 6 years ago			`alfa-network,ac1200rm\|\`
uboot-envtools: ramips: add support for ALFA Network Tube-E4G Signed-off-by: Piotr Dymacz <pepe2k@gmail.com> 5 years ago			`alfa-network,awusfree1\|\`
uboot-envtools: ramips: add support for ALFA Network Quad-E4G Signed-off-by: Piotr Dymacz <pepe2k@gmail.com> (cherry picked from commit 10bcf1eb40b728b3583c1a7693111f27a9801dc5) 5 years ago			`alfa-network,quad-e4g\|\`
uboot-envtools: ramips: add support for ALFA Network R36M-E4G Signed-off-by: Piotr Dymacz <pepe2k@gmail.com> (cherry picked from commit 3cfea3a32125a2c59dfaa9103804ad51609ebe9d) 5 years ago			`alfa-network,r36m-e4g\|\`
uboot-envtools: ramips: add support for ALFA Network Tube-E4G Signed-off-by: Piotr Dymacz <pepe2k@gmail.com> 5 years ago			`alfa-network,tube-e4g)`
uboot-envtools: fix ALFA Network AWUSFREE1 support Signed-off-by: Piotr Dymacz <pepe2k@gmail.com> 6 years ago			`ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x1000"`
			`;;`
			`all0256n-4M\|\`
			`all0256n-8M\|\`
			`all5002)`
			`ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x10000" "0x10000"`
			`;;`
uboot-envtools: fix code formatting style in uci-defaults files Few minor code formatting style fixes, including: - keep one board per line - always use "\|\" (for consistency) - remove redundant double quotes and empty lines Signed-off-by: Piotr Dymacz <pepe2k@gmail.com> 8 years ago			`linkits7688\|\`
			`miwifi-nano\|\`
			`sk-wb8\|\`
			`wsr-1166\|\`
			`wsr-600\|\`
uboot-envtools: add support for ZBT-WG2626 Signed-off-by: Daniel Golle <daniel@makrotopia.org> 8 years ago			`zbt-wg2626)`
uboot-envtools: add config for the Edimax BR-6425 board Signed-off-by: Yuval Adam <yuv.adm@gmail.com> Signed-off-by: Gabor Juhos <juhosg@openwrt.org> SVN-Revision: 35464 11 years ago			`ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x10000"`
			`;;`
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] 5 years ago			`xiaomi,mir3p\|\`
ramips: Xiaomi MIR3G: detect board name from DTS - Former "mir3g" board name becomes "xiaomi,mir3g". - Reorder some entries to maintain alphabetical order. - Change DTS so status LEDs (yellow/red/blue) mimic Xiaomi stock firmware: (Section Indicator) <http://files.xiaomi-mi.co.uk/files/router_pro/router%20PRO%20EN.pdf> <http://files.xiaomi-mi.co.uk/files/Mi_WiFi_router_3/MiWiFi_router3_EN.pdf> \|Yellow: Update (LED flickering), the launch of the system (steady light); \|Blue: during normal operation (steady light); \|Red: Safe mode (display flicker), system failure (steady light); Signed-off-by: Ozgur Can Leonard <ozgurcan@gmail.com> [Added link to similar Router 3 model] Signed-off-by: Christian Lamparter <chunkeey@gmail.com> 5 years ago			`xiaomi,mir3g)`
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> 7 years ago			`ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x20000"`
			`;;`
uboot-envtools: add config for the Edimax BR-6425 board Signed-off-by: Yuval Adam <yuv.adm@gmail.com> Signed-off-by: Gabor Juhos <juhosg@openwrt.org> SVN-Revision: 35464 11 years ago			`esac`

uboot-envtools: add configration for ramips devices uboot-env settings for ALL0239-3G, ALL0256N, ALL5002. Signed-off-by: Daniel Golle <dgolle@allnet.de> SVN-Revision: 33296 12 years ago			`config_load ubootenv`
			`config_foreach ubootenv_add_app_config ubootenv`

			`exit 0`